13 ms·
wow this is huge: https://www.haproxy.com/blog/dns-service-discovery-haproxy/ https://www.haproxy.com/blog/dns-service-discovery-haproxy/ h2 only on the fronten
by merb 9y ago
wow this is huge: https://www.haproxy.com/blog/dns-service-discovery-haproxy/ https://www.haproxy.com/blog/dns-service-discovery-haproxy/
h2 only on the frontend, as expected.
- ksec 9y agoAlso HTTP Small Object Caching, i wonder how it compares to varnish in performance.
- wtarreau 9y agoThe purpose is not to compare to varnish. If you need a real cache, please use varnish. haproxy is to the cache what varnish is to the load-balancer. Ie: we both do a little bit of it to simplify certain deployments, but serious ones need both. We did this to address certain regular demands from users of dirty servers suffering from just "GET /favicon.ico" (hence the "favicon cache" term we've been using for a long time). I've been annoyed by seeing people abusing the "errorfile 503" to deliver a few static objects and this is an elegant response to address this. Over time it may turn out that it could combine well with varnish, for example to improve a little bit the scalability of haproxy+varnish nodes, we'll see. But it definitely is not at all an alternative to varnish. As a rule of thumb, I'd say that if you have a cache, keep it. If you only have haproxy, you can try with a few rules to enable very basic caching and see if that improves the situation for you. Then you'll get a better idea about what would be required in your application to deploy an advanced cache and what benefits it could bring.
- sofaofthedamned 9y agoThat is superb! I love haproxy but although it's rugged and rock-solid it's always seemed like a relic from the old way of doing things. Adding service discovery brings its reliability into a microservice age. Awesome.