I rave about Caddy. Worth it just to never have to think about HTTPS again. We used to have an Nginx+certbot docker container and it was fragile at best, but migration to Caddy was very easy. One feature it has that I love: If a request comes in but a backend is down, instead of returning an error it'll wait a set amount of time for the backend to come up, then forward the request. This means you can do zero-downtime…
Caddy – Open-source web server with automatic HTTPS
91–100 of 132 posts
Re: Caddy – Open-source web server with automatic HTTPS
#92Earlier 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…
Hmm, so you're hung up on all things we've fixed with Caddy v2 years ago. I recommend giving it a try again with a fresh mindset. It's a totally different product.
Re: Caddy – Open-source web server with automatic HTTPS
#93Earlier quoted context omitted.
It’s funny that your complaint about opaque answers got responses that imply that performance doesn’t matter. What this tells me is that Caddy is slower than its competitors and they know it. If it wasn’t, then they wouldn’t hide behind meaningless responses. Basically they answered without answering.
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. But still, a server should rarely ever be your bottleneck. Your application's DB I/O will be.
I have C++ server. Instead of constantly querying DB it holds all business data in RAM in appropriate structures optimized for real time usage, not how they're kept in DB. All read requests are basically limited by network IO except when some request calculates some more or less complex math. No waiting for DB. Writes are batched and a frequency of those is way less than that of reads.
It reverse proxied by Nginx. Putting Caddy instead would be a disaster if Caddy is much slower.
Re: Caddy – Open-source web server with automatic HTTPS
#94Earlier quoted context omitted.
Hmm, so you're hung up on all things we've fixed with Caddy v2 years ago. I recommend giving it a try again with a fresh mindset. It's a totally different product.
I don't know if the tone of the marketing is fixed. In the past I found the lack of humility surrounding the project off putting. Now I go to the website and the first thing I see is a giant "THE ULTIMATE SERVER", not a good start.
Re: Caddy – Open-source web server with automatic HTTPS
#95Earlier quoted context omitted.
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 .…
Not everything needs to be read as a comparison to other products. Adjectives have meaning without competition. They can be interpreted as ratios, for example requests / available memory, or load / latency. 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"…
Now, Caddy is a web server. You say that it's fast and efficient. I'm not putting that into question. But what do you base that on? What would it take for Caddy to be judged as "slow" or "inefficient" by you? Maybe you don't have a precise answer, and that's perfectly okay. But you must have a way to evalute what's slow and what's fast, even when not comparing to other product. At least that's how I (and I assume, the people asking you all these questions) think.
> This discourse makes me exhausted, every time it comes up. I'm tired of everyone thinking I'm trying to outperform NGINX.
That's fair, and I can empathize. However, I think that's what will happen when the first thing people see on the website of Caddy is "THE ULTIMATE SERVER". Ultimate, for a good amount of people, is related to performance, so people are going to ask you about that. And when they don't get a clear answer, they're going to get frustrated.
Again, I'm not trying to be confrontational here. But there seems to be a real lack of understanding in this conversation, and I'm trying to clarify what people mean when they ask about Caddy's performance.
Re: Caddy – Open-source web server with automatic HTTPS
#96I learned only recently that Apache can do automatic Letsencrypt certificate management, not with some third-party module, but with the bundled mod_md.
Of course, it's still experimental: https://httpd.apache.org/docs/trunk/mod/module-dict.html#Sta...
"Experimental" status indicates that the module is available as part of the Apache kit, but you are on your own if you try to use it. The module is being documented for completeness, and is not necessarily supported.
Nonetheless, it would certainly be something to make Apache competitive with the likes of Caddy and Nginx again, if they manage to implement the functionality in a resilient and easy to use manner to the end.Re: Caddy – Open-source web server with automatic HTTPS
#97I love what the Caddy project is doing, but every time I look into it I can’t get a straight answer about performance. One of the top search results for Caddy performance is this Caddy forum thread with a response from the Caddy author: https://caddy.community/t/performance-compared-to-nginx/7993 But it seems to be dodging the question and linking to the most misleading possible Tweets instead of providing any actual…
I think the point is just that for most applications, the reverse proxy server is not a performance bottleneck, so it doesn't matter for any practical purpose. Caddy could be twice as fast or slow and it would not change the number of servers you need to deploy one way or another. If your reverse proxy is a bottleneck, you'll know and probably have the resources to build something custom instead of using Caddy or wha…
I'm not commenting either way on Caddy vs. other solutions, but whether or not a reverse proxy is a pure performance bottleneck, it can become a cost issue. If a reverse proxy is capable of handling twice as much traffic as another solution (through some combination of simultaneous connections and raw speed), it'll cost half as much to operate. Especially at scale, those costs can really matter.
Raw speed for speed's sake is only sometimes the most important factor.
Edit: grammar.
Re: Caddy – Open-source web server with automatic HTTPS
#98Earlier 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. But still, a server should rarely ever be your bottleneck. Your application's DB I/O will be.
> 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 link you provided had some results from eva2000, I think those are good indication of how Caddy performs. I have used some of his work since... I think some 20 years ago. ( Jeez.... ) So he has been testing server and frameworks all the way back since CGI-Bin era.
But I do understand the frustration, may be Caddy should be up front about it. On the other hand I can see how the author doesn't want to do benchmarks. If you have to benchmarks this may not be for you.
I do wish they at least had memory usage on their web site. Although in my testing it is always less than 100MB I dont bother much with it on a low traffic website.
Re: Caddy – Open-source web server with automatic HTTPS
#99Earlier quoted context omitted.
Think I found the Caddy developer.
Yes, I'm a maintainer. What's your point?
Disclosure: Not a Caddy user. Turned off from it by the maintainers shamelessly plugging Caddy as the best thing since sliced bread whenever a competitor is mentioned somewhere. I'm also a community contributor to HAProxy which might or might not be considered a competitor.
Re: Caddy – Open-source web server with automatic HTTPS
#100Earlier quoted context omitted.
I think the point is just that for most applications, the reverse proxy server is not a performance bottleneck, so it doesn't matter for any practical purpose. Caddy could be twice as fast or slow and it would not change the number of servers you need to deploy one way or another. If your reverse proxy is a bottleneck, you'll know and probably have the resources to build something custom instead of using Caddy or wha…
> I think the point is just that for most applications, the reverse proxy server is not a performance bottleneck I'm not commenting either way on Caddy vs. other solutions, but whether or not a reverse proxy is a pure performance bottleneck, it can become a cost issue. If a reverse proxy is capable of handling twice as much traffic as another solution (through some combination of simultaneous connections and raw spee…
I guess my point is that even an inefficient proxy is going to be light on resource usage, and you will always need extras. At some scale, the inefficiency matters, but at most scales it really doesn't. So if Caddy is easy to operate, I'd say go for it. (But personally I use envoy + cert-manager. More flexible and less magic.)