[Mongrel] Again: Workaround found for request queuing vs. num_processors, accept/close

Simon Santoro simon.santoro at gmail.com
Wed Jan 23 14:18:10 EST 2008

Hello all.
I too found out that I sometimes have some action that can take up to 10 
seconds in my rails application. I've read all arguments Zed made about 
polling/and inbox strategies, and I think I just can't work around my feeling 
that a "wrong" request that takes up too much time should be able to lock 
subsequent requests in mongrels queue. That's what I have a balancer for, 
right? :)
So I tried Robert Melas hint[1] and used
BalancerMember http://foo max=1 acquire=100
to see if that helps. But I may have hit a bug[2], and this does not work for 
Does this work for someone? With what version of Apache? I am running 2.2.4. 
Or do all of you have only very fast requests that do not take more than a 
few seconds max to complete? Or do you run a different load balancer? 
I also think that the overall speed of the application would incerase even 
with relatively fast requests, because the balancer would forward the 
requests always to a free mongrel that has nothing to do, and can handle the 
request immediately.

BTW, it looks like the acquire parameter is not in seconds, but in 
milliseconds, so I tried acquire=100 as well, but no difference.
        /* Acquire timeout in milliseconds.
         * If set this will be the maximum time to
         * wait for a free connection.

Maybe this belongs to the Apache ml and not to mongrel, but I think maybe some 
of you hit this problem and solved it somehow.

Another issue: on my system, 
mongrel_rails --version
Mongrel Web Server 1.1.3 (installed as a gem)
the --num-procs parameter does not seem to work. To debug the problem I added
STDERR.puts "TEST: #{worker_list.length}  #{@num_processors}"
on line 279 of /usr/lib/ruby/gems/1.8/gems/mongrel-1.1.3/lib/mongrel.rb, and 
to my surprise it looks like the parameter is ignored. If I run it

$ mongrel_rails start -a -p 8999 --num-procs 1 &
[1] 18617
** Starting Mongrel listening at
** Starting Rails with development environment...
config/boot.rb:28:Warning: require_gem is obsolete.  Use gem instead.
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not 
work well.
** Mongrel 1.1.3 available at
** Use CTRL-C to stop.

and then:

$ w3m -dump http://localhost:8999/test >/dev/null
TEST: 0  950

So it looks like @num_processors is still at the default value of 950, and not 
1 as I told it on the command line. Does the deprecation warning maybe have 
something to do with this (I don't think so, but you never know...)?

Thank you!


More information about the Mongrel-users mailing list