Hi Andrew, On Thu, Apr 26, 2018 at 10:06:00PM +0100, Andrew Smalley wrote: > Hello Haproxy mailing list > > I have been looking at caching technology and have found this > > https://github.com/jiangwenyuan/nuster/ > > It claims to be a v1.7 / v1.8 branch fully compatible with haproxy > and indeed based on haproxy with the added capibility of having a > really fast cache as described here > https://github.com/jiangwenyuan/nuster/wiki/Web-cache-server-performance-benchmark:-nuster-vs-nginx-vs-varnish-vs-squid > > It looks interesting but I would love some feedback please
It's indeed interesting. By the way it's only for 1.7 as the 1.8 branch also contains 1.7. First, he found that nginx's primary job is not to be a cache (just like haproxy is not), and that in the end, only squid and varnish are real caches. Second, he focuses on performance. It's not new for many of us that haproxy rocks here, being 3 times faster than nginx in single core and 3 times faster than varnish using 12 cores is easily expected since haproxy never makes any single I/O access. He could even have compared with the small object cache in 1.8. But there's an important point which is missed there : manageability. Varnish is a real cache and made for being manageable and flexible. It probably has its own shortcomings, but it does the job perfectly for those who need a fully manageable cache. Putting a full-blown cache into haproxy is not a good idea in my opinion. A load balancer must be mostly stateless so that it can be killed, rebooted or tweaked. Implementing a full-blown cache into it seriously affects this capacity. It may even require some reloads just to flush the cache, while a load balancer should never have to be touched for no reason, especially when it's shared between multiple customers. The reason I was OK with the "favicon cache" in haproxy is that I noticed that when placing haproxy in front of varnish, we wasted more CPU and time processing the connection between haproxy and varnish than delivering a very small object from memory. And others had noticed that before, seeing certain configs use dummy backends with "errorfile 503" to deliver very small objects. So I thought that a short-lived, tiny objects cache saving us from having to connect to varnish would benefit both components without adding any requirement for cache maintenance. It's really where I draw the line between what is acceptable in haproxy and what is not. The day someone asks here if we can implement a cache flush on the CLI will indicate we've gone too far already, and we purposely refrained from implementing it. With this said, I can understand why some people would like to have more, especially when seeing the performance numbers on the site above. Possibly that we should think how to make it easier for these people to maintain their code without having to rebase too much (eg they may need some extra register functions or hooks to avoid patching the core). Regards, Willy
