Re: Request queue length

[Eric Wong <normalperson@yhbt.net>]

Troex Nevelin <list@mrtech.ru> wrote:
> On 02/06/2011 10:02 PM, Eric Wong wrote:
>> [1] http://raindrops.bogomips.org/
>>      I've found this example surprisingly useful, too:
>>      http://raindrops.bogomips.org/examples/linux-tcp-listener-stats.rb
>
> Thank a lot for this link, I also found a lot of interesting. I'm  
> currently using thin (rails2.3 on ruby1.8), but thinking to try unicorn  
> on next update.
> I was monitoring nginx and thin using raindrops:
>
> Nginx:
> # ./linux-tcp-listener-stats.rb -d 1 80.93.53.99:80
>             address     active     queued
>      80.93.53.99:80        929          0
>      80.93.53.99:80        984          0
>      80.93.53.99:80        978          0
>      80.93.53.99:80        941          0
>
> Nginx is almost always shows that all sockets are active (~1000) and  
> queued sometimes I can see 1 or 2. As I understand that means that nginx  
> is fast and works well.

Yep, nginx does its job very well.

> Thin:
> # ./linux-tcp-listener-stats.rb -d 1 10.0.0.1:4000
>             address     active     queued
>       10.0.0.1:4000         21          8
>       10.0.0.1:4000         21          9
>       10.0.0.1:4000         21         10
>       10.0.0.1:4000         23          0
>       10.0.0.1:4000          1          0
>       10.0.0.1:4000          0          0
>       10.0.0.1:4000          2          0
>
> What can you say about these numbers? Actually I don't understand the  
> 'active' table. As I thought thin or unicorn can serv only one request  
> at a time because ruby/rails works like forks, so what means this 
> 'active'?

Thin can hold multiple connections open in a single process (idle or
doing I/O), but only execute the Rack app for one client at a time
(unless you're using the non-standard "app.deferred?" stuff).

With Unicorn, you'll still see multiple active because all the worker
processes share the same listener socket, but the active numbers
will be smaller and capped at the number of worker processes you have.
The queue is likely to be smaller if you're running multiple workers,
too.

-- 
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying