Live data from Hacker News

Caddy – Open-source web server with automatic HTTPS

caddyserver.com

41–50 of 132 posts

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

#41
post #20

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…

Yeah but this means that you could wait 8x longer with NGINX before building a custom solution.

Which itself is pretty meaningless considering almost no one bottlenecks on their reverse proxy.

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

#42
post #39

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…

Can't think of any situations I was involved where the bottleneck was the http server app rather than the application behind it. Am I the only one?

If you’re only serving up heavyweight web apps, then this is probably true.

But Caddy also markets itself as an efficient static file webserver right on the home page:

> Caddy is both a flexible, efficient static file server and a powerful, scalable reverse proxy.

Perhaps the confusing part is the way that Caddy is marketed as “The Ultimate Server” when instead it’s designed to be a fast-enough reverse proxy for applications where performance doesn’t matter. There are many applications where performance really does matter. Static file serving is the most obvious example.

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

#43

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 ditch Caddy?

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

#44
post #27

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.

> I'm still waiting to hear your performance requirements btw. I suppose this encapsulates why I get turned off of Caddy every time I look into it: Basic concerns (including questions about approximate performance) are met with suggestions that I don’t know what I want and therefore I’m not qualified to make such judgments.

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 rights to not use Caddy, but it makes no sense to complain that you can't get the performance information you need when you won't share any information about your use case.

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

#46

Caddy is fantastic. I do the odd freelance contract making touch screen interactives for museums here. These have to run on the local host machine which usually isn't networked and Caddy is perfect for this. The last one I did had a massive DeepZoom/OpenSeaDragon image tileset and Caddy managed to serve that flawlessly where my old go to server Mongoose couldn't keep up.

Neat use case! First I've heard of it. Can you tell me more about the museums?

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

#47

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…

What is not as amazing?

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

#49

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.

> 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 benefit the project, but the argument becomes “official benchmarks are meaningless” as soon as they don’t.

That, and the weird opaque responses and insistence that we debate my performance requirements on the internet when I just wanted to know how Caddy compares to nginx in the most broad terms. Similar performance? Order of magnitude faster? Order of magnitude slower? Why does such a large debate have to erupt when such simple questions are asked?

If Caddy is good for one use case but not for others, why not just say it? Why must it become a one-on-one debate? I don’t literally have one use case for a web server. I want to know when it’s appropriate to choose so I can make these decisions myself without engaging in an HN comment section back-and-forth to figure it out.

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

#50
post #39

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…

Can't think of any situations I was involved where the bottleneck was the http server app rather than the application behind it. Am I the only one?

No. But looking at the site Caddy appears to be a product for easy and quick deployment, so that zero-knowledge people can run a web server. Their point is unlikely to be performance, it is probably in the lines of "low code".
Post reply on HN