On: 35M Hot Dogs: Benchmarking Caddy vs. Nginx

[Havoc]

Close enough to not matter in most use cases. ie pick whatever is convenient

[shabbatt → Havoc]

This is the answer I was looking for but sadly, this type of insignificance becomes ammunition for managers/founders who are obsessed with novelty

[zivkovicp → Havoc]

This is almost always the case, no matter the service we're talking about.

[no_time → zivkovicp]

Is this how we ended up with electron for desktop applications and Java for backend?

[philipwhiuk → no_time]

Yes, because developers and expensive and so developer productivity dominates almost everything else.

[eddieroger → zivkovicp]

Also, "pick what you know" applies here, too. If you know NGINX, then all you get from switching to Caddy is experience, and likewise, vice versa.

[mholt → eddieroger]

*and memory safety*

This cannot be understated. Caddy is not written in C! And it can even run your NGINX configs. :) https://github.com/caddyserver/nginx-adapter

[excitom → mholt]

A solution in search of a problem.

[5d8767c68926 → excitom]

Nginx security page [0] lists a non-zero amount of exploitable issues rooted in manual memory management.

[0] https://nginx.org/en/security_advisories.html

[5d8767c68926 → Havoc]

When would it matter? I write in Python, so performance was never a concern for me, but I am curious the scenarios in which this was likely to be the weakest link in real workloads.

Given available options, I will take the network software written in a memory safe language every time.