Hi Willy Thank you for you for your detailed reply explaining why you think only the favicon cache is sensible and that a full-blown cache within Haproxy is not the best of ideas although interesting.
I will continue the search for a viable yet small cache. Andruw Smalley Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064 [email protected] Leave a Review | Deployment Guides | Blog On 28 April 2018 at 06:48, Willy Tarreau <[email protected]> wrote: > 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
