71–80 of 132 posts
Well it turns out the latest release is v2.4.6 on Github already.
I wish there is a changlog / release note link on the homepage somewhere.
Basically I think they need to delete the whole V2 section. I find it quite confusing.
Tried Caddy before learning acme.sh. Even looked in the source code. Nice idea, but it's a new custom thing. Spent a very small learning time on NGINX, everything is googleable, multiple tutorials, Q&As, samples on every possible subject and usecase. E.g. homelab Guacamole was freezing, the first search result was the fix - not trivial, but just copy-paste several config lines. It's hard to beat the performance and simplicity of NGINX. It does not require to learn all possible tweaks from the start, but learn as you go from 5-lines config SSL reverse proxy and up to whatever complexity is required.
Earlier quoted context omitted.
> What are your performance requirements? If the requirements were such that web server performance didn’t matter, I wouldn’t care and wouldn’t be asking about it. But the problem is that it doesn’t make sense to hide the performance statistics and then debate each user’s performance requirements instead of just letting the performance be a known quantity so we can all decide for ourselves.
We aren't "hiding" any performance stats. They just don't exist. It's super hard to generate them in a way that applies perfectly to everyone's use case. I'm still waiting to hear your performance requirements btw.
> Caddy is both a flexible, efficient static file server and a powerful, scalable reverse proxy.
> LIGHTWEIGHT For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput.
> STATIC FILES By default, Caddy will serve static files in the current working directory. It's so brilliantly simple and works fast.
> Caddy's HTTP server has a wide array of modern features, high performance, and is easy to deploy.
Emphasis with the italics being mine. All of these seem to hint at performance comparaisons being done in specific domains agaisnt other web servers. For example:
- efficient static file server: I would assume that "efficient" here is compared to other file servers, though that could mean also that it doesn't use much resources
- For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput: That seem to imply that other servers with all these features are heavier and less efficient? Or that other servers just don't have those features? Relatively low memory footprint and high throughput? Relative to what?
- It's so brilliantly simple and works fast: What does fast mean here? Fast relative to what? Apache? The standard Go static file server? Python SimpleHTTPServer?
- high performance: High compared to what?
My goal here isn't to be confrontational. My point is that if there are all those claims on the main page of Caddy, then you must at some point have measured performance, resource usage and things like that against other servers. I think what people are asking is to substantiate those claims with data. You're right that it's hard to generate data in a way that applies perfectly to everyone use case. But then on what do you base all these claims? Why is Caddy called "the ultimate server"? At least that's why I'm wondering.
What makes Caddy setup of Lets Encrypt so much easier? I frequently hear that being a huge reason for Caddy use but looking at the documentation for NGINX [0] and Caddy [1], it doesn't seem to be much different. [0] https://www.nginx.com/blog/using-free-ssltls-certificates-fr... [1] https://caddyserver.com/docs/automatic-https
The automatic HTTPS feature of Caddy is a game changer. I enabled it once on a server five years ago and never had to take a second look. I am surprised that this is not a standard feature of all web servers. There is no way I am fighting with certbot (or whatever the recommended software is) anymore. That being said, the rest of the software is not as amazing. Please nginx, could you add automatic HTTPS so I can dit…
Nope, Caddy is one of a minority that put more than a token effort in, a few others have some optional functionality, that you could choose to use if you know what you're doing, most did nothing, relying on you to roll a Certbot script or whatever to manage the certificates.
I figured corporate products, maybe Microsoft tools, stuff like that, might prefer to provide SCEP or any of the half a dozen mechanisms for certificate issuance that pre-dated ACME (what Let's Encrypt does) but lack the actual proof-of-control mechanism. You can imagine Big Corp decides to have a central ACME service doing DNS proof-of-control and then it uses say SCEP internally to issue the certificates to its own servers. That didn't really happen either.
The situation outside web servers is even worse. SQL Servers, SMTP† and IMAP, IRC, and so on, can't do this as easily as Caddy does, but few of them even made a token effort. I don't have much faith in the "efficient market" hypothesis, but if you're a server admin and you believe in it this ought to really shake you. Apparently you value your own time at zero dollars.
† SMTP is a special case. In principle a CA could (but Let's Encrypt don't) allow you to do proof-of-control via SMTP because it uses one of the ports set aside for proof of control purpose in the Baseline Requirements. So you could imagine a CA offering a new ACME proof-of-control method say smtp-69 that meant suitable mail servers would just get themselves certificates, no extra software. But that is not a thing. Other services like IRC or indeed IMAP are not covered by the BRs and so you could not do this for those servers without a lengthy and political process to amend the BRs first.
Earlier quoted context omitted.
You're being unduly defensive. mholt is telling you that he can't provide meaningful general purpose performance numbers because the breadth of cases for Caddy vary too widely, so he's asking you for information about your specific use case so he can give you the very information you're complaining about not being able to access, but you're being cagey about sharing those requirements. You're certainly within your ri…
> mholt is telling you It's not what he's saying, but how he's saying it. "I'm still waiting to hear your performance requirements btw.", is a condescending, dismissive tone that would put more people off than not. Especially considering it was a reply within just a couple minutes of his initial question.
Earlier quoted context omitted.
I have not kept up with Caddy in a long while, so take with a grain of salt: - The weird license debacle. - The weird ads in headers debacle. - I had trouble with advanced usage that should have worked but were not flexible enough, like acting as a cache. - The marketing rubbed me the wrong way. It was pointing the deficiencies in other established FOSS web servers, basically treating them as relics while Caddy itsel…
In case you missed it: https://github.com/caddyserver/caddy/issues/2786 Those issues are a thing of the past. There's no use bringing it up again, tbh. > like acting as a cache That's fair, we have a WIP cache module here https://github.com/caddyserver/cache-handler , it should be ready soon!
>We already have a number of features to land in the upcoming 2.1 release: Well it turns out the latest release is v2.4.6 on Github already. I wish there is a changlog / release note link on the homepage somewhere. Basically I think they need to delete the whole V2 section. I find it quite confusing.
Earlier quoted context omitted.
> You misunderstood then, because what was said was essentially "official benchmarks for servers are meaningless", not that "performance doesn't matter". Do your own testing, for your own usecase. The Caddy forum thread I linked to above highlighted a Tweet about Caddy being 20X more performant than nginx. This was from the Caddy team. The frustrating part is how benchmarks are championed as a selling point when they…
> The Caddy forum thread I linked to above highlighted a Tweet about Caddy being 20X more performant than nginx. That's just saying Caddy _can_ be faster, it's not saying Caddy _is always_ faster. That was never claimed. > when I just wanted to know how Caddy compares to nginx in the most broad terms But that's impossible. There's no way to "generally" benchmark a web server. There's just way too many ways it can be…
Earlier quoted context omitted.
We aren't "hiding" any performance stats. They just don't exist. It's super hard to generate them in a way that applies perfectly to everyone's use case. I'm still waiting to hear your performance requirements btw.
On the Caddy website ( https://caddyserver.com/ ) it says: > Caddy is both a flexible, efficient static file server and a powerful, scalable reverse proxy. > LIGHTWEIGHT For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput . > STATIC FILES By default, Caddy will serve static files in the current working directory. It's so brilliantly simple and works fast .…
It's not always about putting down other products. Both can be fast. Both can be efficient. Both can be fast and light. Both can be "high" without one having to be low in order for it to be valid to call it "high" -- because it's not always about the other product.
This discourse makes me exhausted, every time it comes up. I'm tired of everyone thinking I'm trying to outperform NGINX. Caddy's just fast and efficient, I don't care to defend that claim as much as people care to attack it.
Earlier quoted context omitted.
> The Caddy forum thread I linked to above highlighted a Tweet about Caddy being 20X more performant than nginx. That's just saying Caddy _can_ be faster, it's not saying Caddy _is always_ faster. That was never claimed. > when I just wanted to know how Caddy compares to nginx in the most broad terms But that's impossible. There's no way to "generally" benchmark a web server. There's just way too many ways it can be…
Think I found the Caddy developer.