Hello,
Thank you so much Maciej, I will give it a try - although in that
referenced email it seems like a scary thing to do... A hard thing to
evaluate is the cost of having such rspirep processing in every
response coming from that specific frontend... Is it too overwhelming
to the performance?
If you're running 10000 request/s you should be careful not to add too
many such statements, but at lower speeds, you will almost not notice
the extra CPU usage, particularly if you've built with the PCRE
library,
which is extremely fast. I have seen large configurations where people
use between 100 and 200 regexes per request and it does not appear to
affect them that much.
Not really running 10000 reqs/sec, maybe about 1000 in peak times, so
I'd say I'd want top performance for at least 3000 reqs/sec. If at
3000 reqs/sec it's not a problem to use that, then it's perfect.
Wouldn't this just be a perfect candidate for having it's own
directive, in the likes of errorfile and errorloc, but specifically
only for errors returned by servers instead of only HAProxy? ;-)
Something like:
errorserverfile 404 /etc/haproxy/errorfiles/404generic.http
errorserverloc 404 http://127.0.0.1:8080/404generic.html
it might be, but I don't really know if we need the "errorserverfile"
or not. Becase if we only need the "errorserverloc" above, then you
will be able to do it using ACLs when they're usable on the response
path.
Thanks for this, using ACLs on the response path was something I
completely missed. Of course, the errorserverloc I suggested is
implemented by ACLs on responses. Would be, of course, nice to have
the "errorserverfile" functionality, but it's not really something
that cannot be accomplished with what we have now.
Cheers!
Pedro.
