yes, I know, haproxy is not primarily for caching purposes. But it’s a great tool and I like it’s straight forward configuration.
With low latency HLS and it’s fast requests I see very seldom HITS in http headers for cached objects and I assume that’s because the simultaneously kind of connections from videoplayer-clients. Maybe there’s not enough time for haproxy to store files in cache and serve it from there?
Maybe anyone has an idea how I can optimize cache utilization in this situation?
In my experience, haproxy does not suffer from things being “too fast” for it… but it is a stickler for example in caching.
The only way haproxy will cache something (in my experience) is if it has absolutely zero cookies or session data attached to it, the URL is absolutely the same and of course that it fits into the maximum object and cache size you’ve set. I think these are all reasonable expectations, but you need to make sure your content is set up that way.
If a good static cache like NGINX could cache the object, its likely haproxy can as well… but i’ve never seen the reverse be true. HTH
Maybe there will be more caching or serving of cached files when requests starts to count up. I need to look more into caching stats or logs.
I experimented with slow down requests a little bit (100-200ms) but that’s no solution if all requests hits the server nearly simultaneously, which is kind of the nature of a hls low latency stream and a hls.js player configured for catching up the time.
I read about cache lock in nginx. As I understand, this addresses such scenarios.