> You were expecting Caddy to "trounce" nginx? Most people expect the opposite.
I absolutely was, yes. As an observer I see a lot of people saying positive things about Caddy around here, and how it’s superior performance-wise to a variety of ‘classic’ httpd software. Lots of people love Caddy, and they’re quite vocal, so it’s not a stretch to assume there are reasons why they love it. Nginx development has slowed since the events in Ukraine, unsurprisingly, so again it’s not a leap to surmise Caddy is making good things happen in the meantime.
Ahh, right -- so there's a lot more to performance than just req/sec and HTTP errors. And that's probably the love/hype you're hearing about. (Though Caddy's req/sec performance is quite good too, as you can see!)
Caddy scales better than NGINX especially with regards to TLS/HTTPS. Our certificate automation code is the best in the industry, and works nicely in clusters to coordinate and share, automatically.
Caddy performs better in terms of security overall. Go has stronger memory safety guarantees than C, so your server is basically impervious to a whole class of vulnerabilities.
And if you consider failure modes, there are pros and cons to each, but it can definitely be argued that Caddy dropping fewer requests than nginx (if any at all!) is "superior performance".
I'm actually quite pleased that Caddy can now, in general, perform competitively with nginx, and hopefully most people can stop worrying about that.
And if you operate at Cloudflare-"nginx-is-now-too-slow-for-us"-scale, let's talk. (I have some ideas.)
Can you add details on _scales better_, what do you mean? I've read recent post from Cloudflare on their thread pool and it makes sense, do you mean things of that sort or?
I had the case when after push notifications mobile clients wakeup and all of them doing TLS handshake to LoadBalancers (Nginx), hitting cpu limit for minute or so, but otherwise had no problem with 5-15k rps and scaling.
Caddy does connection pooling (perhaps differently than what Cloudflare's proxy does, we'll have to see once they open source it) just as Go does. But what Caddy does so well is scale well with the number of certificates/sites.
So we find lots of people using Caddy to serve tens to hundreds of thousands of sites with different domain names because Caddy can automate those certificates without falling over. (Huge deployments like this will require a little more config and planning, but nothing a wiki article [0] can't help with. You might also want sufficient hardware to keep a lot of certs in memory, etc.)
Also note that rps is not a useful metric when TLS enters the picture, as it says nothing useful about the actual TLS impact (TLS connection does not necessarily correlate to HTTP request - and there are many modes for TLS connections that vary).
> So we find lots of people using Caddy to serve tens to hundreds of thousands of sites with different domain names because Caddy can automate those certificates without falling over.
Okay, interesting. It seems their operation mode is quite different from what I used for/see around.
I wonder how they do it for active / passive LB setup, internal services (not accessible over internet for http challenge and so on) , probably it's not their case though.
Not saying it's not useful, just so minor part of the other things for my operations burden.
> I wonder how they do it for active / passive LB setup, internal services (not accessible over internet for http challenge and so on) , probably it's not their case though.
It is, actually!
Caddy automatically coordinates with other instances in its cluster, which means simply sharing the same storage (file system, DB, etc.) -- so it works great behind LB. Caddy's reverse proxy also offers powerful load balancing capabilities similar to and, in some ways, superior to, what you find in HAProxy, nginx, etc. Caddy uses the TLS-ALPN challenge and HTTP challenge by default, automatically fails over to another when one doesn't work, and even learns which one is more successful and prefers that over time.
Caddy can also get certificates for internal use, both from public CAs using the DNS challenge, or from its own self-managed CA which is also totally automated.
It turns out that these abilities save some companies tens of thousands of dollars per year!
I absolutely was, yes. As an observer I see a lot of people saying positive things about Caddy around here, and how it’s superior performance-wise to a variety of ‘classic’ httpd software. Lots of people love Caddy, and they’re quite vocal, so it’s not a stretch to assume there are reasons why they love it. Nginx development has slowed since the events in Ukraine, unsurprisingly, so again it’s not a leap to surmise Caddy is making good things happen in the meantime.