I use an empty "heartbeat" method that does a render :nothing => true, and then I look for this request via an ACL in the front-end and give it a default backend of the mongrels. option httpchk /blahblah/heartbeat acl dyn_mongrels path_beg /blahblah/heartbeat use_backend mongrels if dyn_mongrels
We try to identify most other dynamic requests and send them straight to the mongrels via ACLs, while the remainder go to the webserver (nginx in our case) and are redirected back to the correct backend port for the mongrels backend if they're deemed to be dynamic. On Sun, Feb 22, 2009 at 7:17 AM, Dusty Doris <[email protected]> wrote: > Right now, I simply have that file in the public directory so its > served by apache directly, instead of placing it in a rails queue. > This does make haproxy blind to whether or not Rails is broken, > because its only checking to see if Apache is responding. However, if > you want to take down the instance, you can just turn off apache and > haproxy will take it out of the queue. Or simply rename that file. > > But, I realize that's not ideal. I still haven't come up with the > best way to do this so that haproxy is checking the actual status of > your ruby processes. I'm thinking that it might be actually starting > up a single mongrel/thin/ebb/webrick process, and then using > mod_rewrite to send those particular httpchk requests to that process > instead of going into the passenger queue. > > In addition, I use the global queue in passenger. That seems to help > if we have any long running actions. > > http://www.modrails.com/documentation/Users%20guide.html#PassengerUseGlobalQueue > > Hope that is helpful. > > On Fri, Feb 20, 2009 at 4:27 AM, Matthias Müller > <[email protected]> wrote: > > Hi there > > > > seems like the failing requests issue is related to the check interval > for > > "option httpchk /health_check.html" > > > > I guess these requests are being queued by Apache itself. > > We're having a couple of long running requests on our machines. These > > requests are queued in Apache by the Apache and Passenger internal queue. > > Maybe the check requests are so as well. So, if it takes longer than the > > specified check interval to complete the check request, HAProxy treats > > Apache to be down. And as there is no other server to forward the request > > to, the reuqest is dismissed. > > > > After increasing the check interval, HAProxy works fine. > > > > Does anyone have experience with having "option httpchk" enabled for > > Passenger? > > > > Thanks > > > > Matt > > > > > > Willy Tarreau wrote: > >> > >> On Thu, Feb 19, 2009 at 10:02:36AM +0100, Matthias Müller wrote: > >>> > >>> Hello there > >>> > >>> I'm trying to find a suitable solution to load balance Rails > applications > >>> via Passenger and HAProxy.Currentliy I'm doing a lot of testing using > Apache > >>> Bench. > >>> > >>> The setting is as simple as follows: > >>> > >>> machine A: HAProxy > >>> machine B: Apache with mod_rails > >>> > >>> my test: 100 concurrent requests via Apache Bench > >>> > >>> When running 100 concurrent requests against HAProxy, Apache Bench has > a > >>> lot of non 2XX responses and I get a lot of BADRQ in my HAProxy log > like: > >>> > >>> Feb 19 08:50:25 localhost.localdomain haproxy[1890]: 10.0.0.1:33917 > >>> [19/Feb/2009:08:50:10.898] http-proxy http-proxy/member1 > -1/13816/1/-1/14702 > >>> 503 13757 - - ---- 99/99/99/9/0 0/32 "<BADREQ>" > >> > >> There's something odd in the log above. It implies that the request was > >> sent > >> into the queue waiting for a server to be free, but also that the > request > >> was > >> invalid or perhaps empty. I suspect that AB has timedout slightly before > >> haproxy while waiting for a server response, but I don't understand why > we > >> have "BADREQ" here, we should not have got a 503 with BADREQ. Could you > >> please > >> indicate what exact version this is ? This would help explaining why we > >> can > >> have BADREQ and 503 at the same time. > >> > >> Regards, > >> Willy > >> > > > > > > > >
