6 ms·
HTTPS Reverse Proxy: Caddy Outperforms Nginx 4x
- progval 4y ago> With 4 concurrent requests, NGINX was able to run 100 calls/second, with a 90%-ile latency of 48ms. Under the same conditions, Caddy ran 400 calls/second, with a 90%-ile latency of 16ms. If you are processing only hundreds of queries a second, then both are either seriously misconfigured, or the bottleneck is elsewhere.
- datalopers 4y agoYeah there’s no way this is a Caddy nor nginx raw performance but ridiculously poor backend coding. At a glance the issue the difference though is caddy reverse proxy defaults to keepalive and nginx upstream does not. Enable keepalive in nginx and you’ll see similar performance.
- divbzero 4y agoSeems like nginx should update its default settings. Can’t think of a reason to not make keepalive the default.
- Karrot_Kream 4y agonginx is less opinionated and tends to err on the side of less resource utilization than Caddy by default. There are a myriad of situations where keepalives aren't appropriate, from the client not supporting them to not anticipating the request throughput to hold TCP connections open.
- Matthias247 4y agoIt will likely require more resources. No keepalive on a backend connection also means you need to potentially perform another TLS handshake for each request - which is immensely expensive. The cost of idle TCP connections compared to that is pretty small (maybe 100kB RAM per connection, and no CPU cost). I agree that there can be drawbacks - e.g. Nginx trying to use a keepalive connection while the backend already closed it due to badly aligned timeouts. That's a potential availability issue which can only be avoided by careful configuration. Client not supporting keepalives shouldn't be an issue, since Nginx is the client here.
- Matthias247 4y agoIt introduces an availability risk if the connection reuse times don't exactly match keepalive times on the backend. Plus an increased risk to be vulnerable to a HTTP request smuggling issue if anyone discovery a new and unpatched one. That said I agree that using keepalive seems like a reasonable default - especially since other HTTP clients do the same.
- tlack 4y agoHas anyone else switched to Caddy and seen similar performance improvements? I've been blindly using Nginx for years but have no love for that configuration file..
- chillfox 4y agoI switched to caddy for my personal stuff quite a while ago due to the easy config. I just have everything in a single Caddyfile (TOML). No idea about performance though as for the one thing that needs it I use Envoy proxy.
- rwaksmunski 4y agoBackend connections are not keepalive with that nginx config and benchmark is ran on a shared digital ocean VM. I suspect the author is inexperienced with proxies, operating systems and benchmarks.
- divbzero 4y agoInstead of commenting on the author, perhaps we could share an example of the appropriate nginx config: upstream http_backend { server 127.0.0.1:8080; keepalive 16; } server { ... location /http/ { proxy_pass http://http_backend; proxy_http_version 1.1; proxy_set_header Connection ""; ... } } https://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive https://nginx.org/en/docs/http/ngx_http_upstream_module.html...
- pablo1 4y agoHave always used nginx, but I'm interested in the newer alternatives out there like caddy, traefik or envoy. Is there a up-to-date comparison somewhere? Any personal experiences? Would be interested to hear if there are any reasons to switch. Performance has not been an issue for me, but there might be other good reasons.
- kawsper 4y agoNginx puts some of the more nifty features behind a paywall, whereas it comes natively in the others. One example of these is supporting SRV-records, which acts as glue for containerized workloads. At Billetto we use Nomad and Consul in our cluster, and internally we expose services with DNS and are using SRV-records, so doing a "$ dig SRV +short _billetto-production-rails.service.consul" will return the local IPs and ports where those containers are running.
- Karrot_Kream 4y agoCaddy is more opinionated and has more features than nginx but consumes more resources and is generally slower. It's probably plenty for low/moderate traffic sites, but not always appropriate for high traffic. Caddy is a lot more friendly to use than nginx, and it's config and its defaults are IMO much more appropriate for modern websites. Caddy has all sorts of quality-of-life features than nginx either paywalls or does not have. Envoy is a lot more programmable and configurable than nginx. If you find yourself templating nginx configs and refreshing configuration while live frequently, Envoy is a better solution. Envoy requires more upfront work, uses either crufty YAML config or a custom service catalog backend, but is better overall in high-configurability situations. Can't comment on Traefik. We work at high scales at $WORK so we've standardized around nginx, but if I were at a smaller company I'd definitely look seriously into Caddy. Then again, once configured nginx doesn't really need much reconfiguration so it's more of a one-time-cost.
- moehm 4y agoWhat are some features Caddy brings and Nginx doesn't? I know about the built-in Let's Encrypt handling, anything else?
- YarickR2 4y agoYou should try with location / { return 200; } and turn on SSL caching in nginx . Also, check default ciphers in both cases
- AtNightWeCode 4y ago4 vus, stopped reading there...