Live data from Hacker News

Caddy – Open-source web server with automatic HTTPS

caddyserver.com

91–100 of 132 posts

Re: Caddy – Open-source web server with automatic HTTPS

#91
post #81

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…

I like that feature too! Someone else just wrote about it this week: https://til.simonwillison.net/caddy/pause-retry-traffic

Re: Caddy – Open-source web server with automatic HTTPS

#92
post #67

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…

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

#93

Earlier 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.

>"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

#94
post #67

Earlier 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.

We're more confident about that one.

Re: Caddy – Open-source web server with automatic HTTPS

#95
post #79
post #73

Earlier 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"…

I mean, I get your point, but adjectives don't exist in a vacuum. If everything is fast, everything is slow too, and nothing is fast too, because everything is the same. When you use an adjective like "fast" or "slow", you're separating yourself from the whole, and you're putting the thing you're talking about in a category. Of course this is relative. You can be a fast marathon runner. You can be a fast human. Or a fast animal. Or a fast car, or plane. All of those have vastly different speed. But they still have meaning.

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

#96
post #9

I learned only recently that Apache can do automatic Letsencrypt certificate management, not with some third-party module, but with the bundled mod_md.

This is super interesting!

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

#97

I 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 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 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

#98

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. 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…

I think generally speaking, if you really want or care about performance you shouldn't be using Caddy.

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

#99
post #78

Earlier quoted context omitted.

Think I found the Caddy developer.

Yes, I'm a maintainer. What's your point?

One thing would be indicating that you are a maintainer in your comment, when it's not immediately obvious, so that readers are able to understand your comment in a proper context. Like I will do at the bottom of my comment:

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

#100

Earlier 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…

For me, reverse proxy capacity is more about surviving machine failures. I'll need N+2 of them per region per zone regardless of how efficient they are. For my simple personal site, I run Envoy on 3 machines limited to 64M of RAM and it easily supports 10,000qps per instance with many more concurrent connections (for clients downloading the requested document slowly). One instance alone is enough for all the capacity I desire (and I have rate limits to prevent one IP from using more than its fair share of the limited capacity), so I pay for 128M of RAM that I don't need simply to survive VM failures during a deployment.

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.)

Post reply on HN