thanks holger, i did some research and was able to find more on mongrel and queuing. so that helps to clarify. i am unsure what i will do viz checking in the end as we have some long running requests that are frankly the bane of my existence and complicate load balancing. we need to refactor as part of the solution.
just to be complete, are there any plans to have health checks get queued? On Sat, Mar 20, 2010 at 8:14 AM, Holger Just <w...@meine-er.de> wrote: > 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 > > -- greg gard, psyd www.carepaths.com
