Troex Nevelin <[email protected]> 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 - [email protected] http://rubyforge.org/mailman/listinfo/mongrel-unicorn Do not quote signatures (like this one) or top post when replying
