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.
But still, a server should rarely ever be your bottleneck. Your application's DB I/O will be.
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.
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.
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 used for any single benchmark to ever be valid.
Do your own benchmarks, for _your_ usecase. That's the only way you'll get any kind of real answer.
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.
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.
I guess it would make more sense if they came right out and said that it’s best used for these applications where it’s acting as a reverse proxy for a heavy backend and therefore performance isn’t a big issue.
But I’m constantly confused by the vague responses combined with the allusions to claims that it’s super-fast because it uses Go like Google or Tweets about it being 20X more performant than nginx when it’s clearly not.
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.
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.)
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.
Like what? Genuine question. I'm sure a cloud provider's layer 7 load balancer / Kubernetes Ingress would merit an optimized implementation but beyond those kinds of super-scale use cases I can't think of much.
But I feel the real bottleneck is developer pain. I switched to nginx from Apache like everyone else because nginx was nice to use and Apache wasn't. The performance aspect was only a rationalization.
Mentioning without context sounds like an emotional one.
This whole thread has a lot of unproductive animosity, and it's possible part of that is due to the opaqueness who the identity of those involved.
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.
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.
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.
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.
When it comes to tech in particular, things are pretty much always compared relative to each other, because there's very little other reference points. React is generally deemed as slow relative to Svelte. Rust is more efficient than Python at runtime. These claims mean very little in a vacuum, in fact I'd say that they are almost pointless. You can't base you business decisions on claims that haven't been backed up by data. And if you do, you might regret them later on.
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 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.
I don’t have one single set of requirements for every location I use a web server. Nobody does.
If Caddy is good for one thing but not so good for other things, why is it so hard to come out and say that?
Also, the benchmark I was questioning in the opening comment came from mholt on the official community forum. It’s mind boggling that I’m getting attacked for questioning the benchmark result that they provided in the first place.
You want performance metrics, but can't even tell us what metrics matter to you, but expect Matt and Caddy team to have them just available... You understand that your responses here are directly proving his point on not having them, right?
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.
I don't think you're being negative or whatever and I also think the other person has an idea of what they want to know but not how to explain it.
Do they want connection handling metrics? SSL terminations? Caching performance?
Also, not at you but a general laugh, "the reverse proxy isn't the bottleneck ever" is funny because prior to haproxy, getting gigabit throughput to a backend was considered extreme engineering.
Now I can load balance and ssl terminate a gigabit with like 5 raspberry pi and an old Intel box to load balance and cache.
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 info:
> Caddy is written in Go. It will perform just as well as any other Go web servers.
> Google, Netflix, Cloudflare, Fastly, and other large network companies deploy Go on their edge. You can too.
What a bizarre response.
They then link to a Tweet from someone who claims that Caddy performed 20X better than nginx. An impressive claim! But further investigation shows that virtually every other benchmark I can find shows the opposite situation: Nginx beating Caddy by up to 8X.
Performance isn’t everything and there are plenty of situations where Caddy’s ease of use might prevail, but I get nervous when project authors are giving cagey and misleading responses to straightforward (and important) questions.