Is it possible with HAproxy to change backend to secondary (backup) if primary don’t answer in certain time? I need all request sent do backend1, but if reply from backend1 won’t come in 500 ms then this request should be instead directed to backend2. In that case “stale” connection to backend1 should be terminated (or at least late reply from backend1 should be discarded). After 500 ms only reply from backend2 should be send to client.
Can you provide any tips for such configuration? Thank you in advance!
The question should rather be:
What causes your backend1 to respond significantly slower than backend2? To me, the solution seems to work past the problem.
From my point of view this would be something you should solve via HealthCheck instead of just using both backends - and not realizing that one of your backends has a problem.
This is specific case in which timing is crucial. If we have to wait over 500 ms for reply (because of whatever reason) than this particular reply is no good for us. We have to serve another content in this situation.
Health check won’t work in this case, because timing has to be measured and checked for every single request. Some of requests will finish in <500 ms and those will be ok, and others, which will took more than 500 ms, we have to move to another backend.
But why repeat the request on the other backend? And what could backend 2 do better in this case? Or is this just a case of error handling? In this case I would suggest strict timeout settings and the use of error handling.
Business needs. If dynamically generated JS can’t be returned in 500 ms from backend1 then client should get empty js with proper headers. If specific graphic file can’t be returned in 500 ms from backend1 then client should get empty image 0x0 px with proper headers. It should be easy to do with backend 2 and probably quite hard (or impossible) to get with custom error handling.
Is there any way to achieve such time based backend handling in HAproxy?
Hello @idaho, were you able to find solution?
I am facing the same problem, and above custom error page link does not seem to address the original problem!