unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: Request queue length
Date: Fri, 11 Feb 2011 13:20:36 -0800	[thread overview]
Message-ID: <20110211212036.GA26634@dcvr.yhbt.net> (raw)
In-Reply-To: <4D559396.3070109@mrtech.ru>

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
>             address     active     queued
>        929          0
>        984          0
>        978          0
>        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
>             address     active     queued
>         21          8
>         21          9
>         21         10
>         23          0
>          1          0
>          0          0
>          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,

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

  reply	other threads:[~2011-02-11 21:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-06 14:03 Request queue length Troex Nevelin
2011-02-06 19:02 ` Eric Wong
2011-02-11 19:52   ` Troex Nevelin
2011-02-11 21:20     ` Eric Wong [this message]
2011-02-12 15:58       ` Troex Nevelin
2011-02-26 13:12         ` Troex Nevelin
2011-02-26 20:40           ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110211212036.GA26634@dcvr.yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=mongrel-unicorn@rubyforge.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).