Hi Greg, On 2010-03-20 6:52 AM, Greg Gard wrote: > i remember somewhere in the archives mention of a plan to make health > checks get queued like any other request. did that happen in 1.4.x > branch with all the work to health checks. i searched the archives, > but didn't turn up what i remembered. my use case is rails/mongrel > with maxconn = 1 so i don't want health checks getting sent to a > mongrel that might be serving a request or more critically having a > request puke because haproxy sent a health check to the same server it > just sent a client request to.
The haproxy -> mongrel topic was discussed several times in the past. I think, your health checks should not be a problem. If you know and configure your haproxy well. Yes, mongrels are only able to process one request at a time but they are also able to queue requests themselves without puking on the second. This results in having the health checks queued with the regular requests on the mongrels. IMHO that should be no problem if you configure your check timeouts accordingly such that they can handle a rather long regular request queued in front of he health check (depending on your actual setup). I think, you should always check all your mongrels as they have the tendency to just die if something went wrong. If you just check one, it might not detect some failed mongrels. For health checks of rails apps we use a simple dedicated controller inside the rails app (that depends on all the initializers) which just performs a SELECT true; from the database. This works really well for us, although we do not use mongrels anymore but glassfish+jruby. As this check is rather fast, it should not lead to mayor issues even on mongrels. --Holger
