[cunthorpe]

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.

[francislavoie]

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.

[PragmaticPulp]

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

[ksec]

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.

[francislavoie]

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

[Eldt]

Think I found the Caddy developer.

[francislavoie]

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

[TimWolla]

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.

[FpUser]

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

[mcspiff]

Not to diverge too much, but if you’re keeping everything in memory how do you handle hardware failures etc? Wouldn’t that result in data loss?

[FpUser]

Data is written to disk but requests are batched and executed as a single transaction. It is very fast. Partner systems know that the request may fail and business processes are organized accordingly. In practice it never really happens. The overall performance is insane (hundreds of times better) comparatively to some Python scripts fishing in database for every request.

[kreetx]

Yup. They should just say "it's the ease of use" and be done with it. It's a pretty good reason to use a technology.