Request queue length

Request queue length

[Troex Nevelin]

Is there a way to get the number of requests that are currently awaiting 
to be executed by my rails app by unicorn?

Or there is no queue in unicorn and I should look for this information 
somewhere in nginx or other front-end server?

Couldn't find much information about this topic, so decided to ask here 
first.
_______________________________________________
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

Re: Request queue length

[Eric Wong]

Troex Nevelin <list@mrtech.ru> wrote:
> Is there a way to get the number of requests that are currently awaiting  
> to be executed by my rails app by unicorn?
>
> Or there is no queue in unicorn and I should look for this information  
> somewhere in nginx or other front-end server?

The queue is in the kernel and controlled by the listen(2) syscall.
If you're in Linux, you can inspect this with Raindrops[1] or just
read the output of ss(8) or /proc/net/tcp.  I don't know how to do
this in non-Linux kernels.

All TCP servers actually have this queue, so you can use ss(8),
/proc/net/tcp or raindrops to inspect this queue in nginx, too.


[1] http://raindrops.bogomips.org/
    I've found this example surprisingly useful, too:
    http://raindrops.bogomips.org/examples/linux-tcp-listener-stats.rb

-- 
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

Re: Request queue length

[Troex Nevelin]

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.


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'?
_______________________________________________
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

Re: Request queue length

[Eric Wong]

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

Re: Request queue length

[Troex Nevelin]

On 02/12/2011 12:20 AM, Eric Wong wrote:
> 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).

No I'm using any deferred stuff, I have delayed_job but this is other story.


> 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.

Currently I use thin 10 instances and pass 10 sockets to nginx. I forgot 
that unicorn uses only one socket to communicate with frontend :)
What I really want to track with unicorn is to see how many clients are 
really waiting in queue. I hope if I ran 10 unicorn instances and 
monitor socket during peak load I'll see 10 active and the queue will be 
the real queue :)
As you showed me above that thin can take requests 'on hold' and that is 
why I didn't understand the active number bigger than 1 with thin.

I'll post the results here, when I migrate to unicorn.
_______________________________________________
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

Re: Request queue length

[Troex Nevelin]

On 02/12/2011 06:58 PM, Troex Nevelin wrote:
> Currently I use thin 10 instances and pass 10 sockets to nginx. I forgot
> that unicorn uses only one socket to communicate with frontend :)
> What I really want to track with unicorn is to see how many clients are
> really waiting in queue. I hope if I ran 10 unicorn instances and
> monitor socket during peak load I'll see 10 active and the queue will be
> the real queue :)
> As you showed me above that thin can take requests 'on hold' and that is
> why I didn't understand the active number bigger than 1 with thin.
>
> I'll post the results here, when I migrate to unicorn.


We've moved to unicorn and I embeded Raindrops as middleware into our 
rails app, now I'm able to get some stats using /_raindrops url:
http://www.kinokopilka.tv/_raindrops

calling: 4
writing: 174
/var/www/kk/current/tmp/sockets/unicorn.sock active: 5
/var/www/kk/current/tmp/sockets/unicorn.sock queued: 0

The last 2 lines I undersand, that is what I wanted to get. But what 
about 'calling' and 'writing', what does these numbers says?
_______________________________________________
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

Re: Request queue length

[Eric Wong]

Troex Nevelin <list@mrtech.ru> wrote:
> We've moved to unicorn and I embeded Raindrops as middleware into our  
> rails app, now I'm able to get some stats using /_raindrops url:
> http://www.kinokopilka.tv/_raindrops
>
> calling: 4

This is the number of application dispatchers running.
Should always be <= worker_processes.

> writing: 174

This is the number of clients being written to.  Make sure
Raindrops::Middleware is at the outermost/topmost layer of your
middleware stack (top of config.ru).  Some other middlewares may
clobber/ignore the #close method.  You should probably contact the
middleware authors and make sure they properly proxy response bodies
that require a close.

Normally, (calling + writing) <= Unicorn worker_processes

> /var/www/kk/current/tmp/sockets/unicorn.sock active: 5
> /var/www/kk/current/tmp/sockets/unicorn.sock queued: 0
>
> The last 2 lines I undersand, that is what I wanted to get. But what  
> about 'calling' and 'writing', what does these numbers says?
_______________________________________________
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