ok, one last post. sorry about the serialization.

so here is what i am trying now. for each physical server i have 15
mongrels, each on a separate port. for each "cluster" i have one of
the mongrel processes reserved for health checks and mark that one
with backup and have my check inter rise fall config. on the actual
servers that will be processing requests (ie the other 14 mongrels) i
have a weight and track mongrel_1 (ie the backup doing the checks).

my haproxy.cfg looks like (with server names etc changed to protect
the innocent):

global
        maxconn 4096
        user haproxy
        group haproxy
        daemon
        log 127.0.0.1   local0
        spread-checks 5s

# http
defaults
        log global
        retries 3
        timeout queue 600s
        timeout connect 5s
        timeout client  600s
        timeout server  600s
        timeout check 2s

  stats enable
  stats auth user:pw
  stats refresh 20s
  balance roundrobin
  http-check disable-on-404

server
listen proxy1 server1:8080
  mode http
  option abortonclose
  option redispatch
  option httplog
  option httpclose
  option httpchk HEAD /check HTTP/1.0

  server mongrel_1 host:port backup maxconn 1 check inter 20s rise 1 fall 3
  server mongrel_2 host:port weight 10 maxconn 1 track mongrel_1
  server mongrel_3 host:port weight 10 maxconn 1 track mongrel_1
  ...
  server mongrel_15 host:port weight 10 maxconn 1 track mongrel_1

is this the solution for mongrels? will i run into problems with this?
obviously, it would be nice to have either queued health checks OR
(and even better) some kind of app server for rails that allows you to
have more than a single connection. obviously, mongrel_1 better stay
up or i lose all servers in cluster. not idea.

anyway, sorry for the extended email(s), just trying to resolve a
persistant issue.

...gg





On Sat, Mar 20, 2010 at 7:04 AM, Greg Gard <[email protected]> wrote:
> an update. i have set my servers to use a rails method and have tested
> that on several long running requests (e.g. 60+ sec) my mongrel gets
> marked down on check rise 1 fall 3 inter 20s. i can live with that i
> guess. it makes my stats page look like a warzone with servers getting
> marked down and missed checks etc.
>
> what concerns me is what happens when a health check is sent to the
> server and is processing at exactly the same time when a client
> request from the queue is sent. will the request get redispatched,
> queued, or will i start getting complaints from users and see my logs
> filling up with mysterious 5xx errors?
>
> i could really use some clarification. thanks for all the hard work...gg
>
> On Sat, Mar 20, 2010 at 1:52 AM, Greg Gard <[email protected]> wrote:
>> hi,
>>
>> 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.
>>
>> how much of a problem is this kind of collision with mongrel and
>> haproxy health checks? i have 20 sec checks at this point on static
>> files, but i keep getting burned with mongrel returning ok when in
>> fact rails is hung. so i need to use a regular rails controller
>> action, but would like to do so with a  "non-blocking" health check if
>> that makes any sense. ie i can only have one connection to a mongrel
>> at a time. if health checks are independent of client requests there
>> are bound to be collisions.
>>
>> suggestions?
>>
>> thanks...gg
>>
>> --
>> greg gard, psyd
>> www.carepaths.com
>>
>
>
>
> --
> greg gard, psyd
> www.carepaths.com
>



-- 
greg gard, psyd
www.carepaths.com

Reply via email to