5 ms·

I'm an Nginx guy, and I have been for some years, but I do love a little bit of Caddy jingoism[1] as the weekend approaches. This is a good write up. I was exp

I'm an Nginx guy, and I have been for some years, but I do love a little bit of Caddy jingoism[1] as the weekend approaches. This is a good write up. I was expecting Caddy to trounce Nginx, but that wasn't the case. I'll be back to re-read this with fresh eyes tomorrow. [1] For the avoidance of doubt, this is not meant as a snarky observation.

mholt 4y ago
You were expecting Caddy to "trounce" nginx? Most people expect the opposite. But Caddy certainly does in some cases, especially with the upcoming 2.6 release.
- petecooper 4y ago
  > 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.
  - mholt 4y ago
    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.)
    - CoolCold 4y ago
      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.
      - mholt 4y ago
        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). [0]: https://caddy.community/t/serving-tens-of-thousands-of-domains-over-https-with-caddy/11179?u=matt https://caddy.community/t/serving-tens-of-thousands-of-domai...
        CoolCold 4y ago
        > 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.
        4y ago

mholt 4y ago

You were expecting Caddy to "trounce" nginx? Most people expect the opposite. But Caddy certainly does in some cases, especially with the upcoming 2.6 release.

petecooper 4y ago
> 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.
- mholt 4y ago
  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.)
  - CoolCold 4y ago
    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.
    - mholt 4y ago
      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). [0]: https://caddy.community/t/serving-tens-of-thousands-of-domains-over-https-with-caddy/11179?u=matt https://caddy.community/t/serving-tens-of-thousands-of-domai...
      - CoolCold 4y ago
        > 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.
        4y ago