Hello Dave, On Tue, May 29, 2018 at 5:55 PM, Dave Chiluk <chiluk+hapr...@indeed.com> wrote: > We've battled the same issue with our haproxys. We root caused it to slow > dns lookup times while parsing the config was causing haproxy config parsing > to take so long that we were attempting to reload again before the original > reload had completed. I'm still not sure why or where the Signals are > getting dropped to the old haproxy, but we found by installing a dns cache > on our haproxy nodes we were able to greatly decrease the likelihood of > creating zombie haproxy instances.
interesting findings. I however don't see on which part haproxy would need to do dns lookup on our side. Front end side is host matching and backend side is IP only. But I will have a closer look at this point. What I am missing for now is how to know when haproxy is considered as "ready" to prevent new reloads. > We further improved on that by rearchitecting our micro-service architecture > to make use of the haproxy dynamic scaling apis, and allocating dummy slots > for future expansion. Similar to > https://www.haproxy.com/blog/dynamic-scaling-for-microservices-with-runtime-api/. that's indeed what we are already doing for servers. Best, -- William
