4 ms·
> 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
by gregmac 9y ago
> 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).
- snvzz 9y agoIf swap is not present, memory access can be deterministic. Disk access can never be deterministic, which is terrible if you care about latency.
- bpineau 9y agoAlso, I understand we can configure the objects max size (with tune.bufsize). But can we configure the whole cache size (ie. the number of tune.bufsize KB cached objects) ?
- wtarreau 9y agoYes, it's using a similar shctx to ssl, I just don't know how to configure it for now, let's wait for William to push a bit of doc first :-)