> HAProxy is staying true to its principle of not accessing the disks during runtime and so all objects are cached in memory. The maximum object size is as big as the value of the global parameter “tune.bufsize”, which defaults to 16KB.
> This is a general-purpose caching mechanism that makes HAProxy usable as a small object accelerator in front of web applications or other layers like Varnish. The cool thing here is that you can control how large the objects to cache and accelerate delivery should be.
If this is on a server with a few GB RAM, is there any reason not to use it as the only cache? Is there any reason not to set the bufsize to a few MB, for example (assuming memory is not a constraint)?
I have a somewhat complex setup with several micro services each served by a dynamic set of backends. Caching for some of it would be nice, but I couldn't figure out a way to use varnish (or other external cache) without ending up with 1 varnish instance per backend (a pain to maintain), introducing a single point of failure (one per service - and still a pain to maintain), or losing some of the benefit and power of haproxy as a frontend (with varnish in front of it).
If this is on a server with a few GB RAM, is there any reason not to use it as the only cache? Is there any reason not to set the bufsize to a few MB, for example (assuming memory is not a constraint)?
I have a somewhat complex setup with several micro services each served by a dynamic set of backends. Caching for some of it would be nice, but I couldn't figure out a way to use varnish (or other external cache) without ending up with 1 varnish instance per backend (a pain to maintain), introducing a single point of failure (one per service - and still a pain to maintain), or losing some of the benefit and power of haproxy as a frontend (with varnish in front of it).