On Mon, May 04, 2009 at 09:49:35AM -0400, Joe Gooch wrote: > > Pound will only mark a backend dead if the TCP connection to the backend > fails. (For instance, I'll add an iptables rule on the backend to REJECT > connections to the http port when doing maintenance) Similarly, resurrect > checks for a TCP connection to the backend. > > What you're talking about would happen if the TCP connection succeeded and > the httpd could not return data. This could also happen if a backend process > were running and generating content, but took a long time to complete. (This > happens a lot in my situation) I wouldn't want my backend to be marked dead > because someone ran a large report. > > Which is why the checks for life are so rudimentary in pound. But it's also > why there's a HAPort directive. You can craft a simple perl script that > listens on a different port, tries to read a dummy file from NFS on connect > attempts, and runs an accept() call if the check succeeds. If it doesn't, > the backend will be marked dead and stay dead until that check succeeds. I understand the need for the HAPort directive. I actually considered it at some point. But if applied, the number of connections made to the backend will increase drastically, I would even say unnecessary. More connection means more activity. So in the end more overhead. I think it'd be cheaper, in terms of resources to use the information gathered from ongoing requests to determine the status of a backend. I didn't look through the source code to determine the precise behaviour of having HAPort defined. So if I'm wrong, please correct me.
After all, in this case we're only interested in availablity of the backend as in: handle incoming HTTP requests. Using an external program to determine the availability of the data source still doesn't imply the availability of the backend itself. Such a situation is if the backend is under heavy load (your example) or in case the webserving daemon ends up in a race-condition situation. I don't think ignoring backend timeouts, as this seems to be the current behaviour in pound is desireable. Or the weak condition to resurrect a backend. Sure someone may be generating a large report which renders the server unresponsive for a limited period of time. But that doesn't change the fact the backend isn't responding. So it's logical to mark it either as dead or give a status to avoid requests being forwarded to it. And _only_ resurrect it when it answers to HTTP requests. An efficient solution is to have the ability to define a URL for Availability check, which is _only_ used in case a backend has been marked dead/unavailable. This mechanism looks similar to any other monitoring solution like Nagios. The difference, which makes this superior to the existing solution, is the backend won't be unnecessarily bombarded by Availability request checks. > This question comes up a lot. I'm sure there are plenty of examples in the > list archives. Couldn't find them. Maybe I should look harder. > It is interesting however that kill_be does not log that it is killing a > backend... That should likely happen. Indeed. Maybe someone else can shed some lights on this kind of bevahiour? Xiwen -- -- Xiwen Cheng System Administrator ;" Enthusiasm is contagious, Mathematical Institute ; but hype is a disease. " Leiden University ;E-mail: [email protected] Niels Bohrweg 1 K210 ;Office: (+31) 715277134 2333 CA Leiden ;Mobile: (+31) 611119991 The Netherlands ;GPG Key id: 194F572B ++ -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
