From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS6939 64.71.128.0/18 X-Spam-Status: No, score=-1.9 required=3.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_HEADER,WEIRD_PORT shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.raindrops.general Subject: Re: queued is always 0 Date: Mon, 28 Jun 2010 17:50:07 -0700 Message-ID: <20100629005007.GA25438@dcvr.yhbt.net> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1277772628 19950 80.91.229.12 (29 Jun 2010 00:50:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 Jun 2010 00:50:28 +0000 (UTC) To: raindrops@librelist.com Original-X-From: raindrops@librelist.com Tue Jun 29 02:50:27 2010 Return-path: Envelope-to: gclrrg-raindrops@m.gmane.org List-Archive: List-Help: List-Id: List-Post: List-Subscribe: List-Unsubscribe: Precedence: list Original-Sender: raindrops@librelist.com Xref: news.gmane.org gmane.comp.lang.ruby.raindrops.general:6 Archived-At: Received: from zedshaw.xen.prgmr.com ([64.71.167.205]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OTP1q-0000Px-GO for gclrrg-raindrops@m.gmane.org; Tue, 29 Jun 2010 02:50:22 +0200 Received: from zedshaw.xen.prgmr.com (localhost [IPv6:::1]) by zedshaw.xen.prgmr.com (Postfix) with ESMTP id C219021B751 for ; Tue, 29 Jun 2010 00:58:46 +0000 (UTC) Ryan King wrote: > I'm trying to see if raindrops will help us instrument our stack, so > I'm doing some tests. > > I have 16 unicorns running our app with rainbows and am hitting it > with ab with a concurrency of 100. However, according to > linux-tcp-listener-stats.rb I have 0 queued requests. Maybe I'm > missing something, but shouldn't there be queued requests somewhere > here? Hi Ryan, The Unicorns could be accept()-ing connections fast enough and the queued connections aren't noticeable[1]. Try sending SIGWINCH to the Unicorn master process and they should be queueing up because all the workers will have stopped. (SIGHUP to restart the workers). You can test and walk through this yourself on IRB, too: 1. startup irb: "irb -rsocket", then inside irb: server = TCPServer.new '127.0.0.1', 3000 2. Now, hit the address you started the server on in a different terminal with curl: curl -v http://127.0.0.1:3000/ # curl should block here 3. Run linux-tcp-listener-stats: ./examples/linux-tcp-listener-stats.rb 127.0.0.1:3000 # You should see one queued, zero active 4. Back in irb, accept the connection: client = server.accept # should get a TCPSocket object 5. Run linux-tcp-listener-stats again: ./examples/linux-tcp-listener-stats.rb 127.0.0.1:3000 # You should see one active, zero queued If you fire up more curl instances in other terminals without running "server.accept" in IRB, you should see more queued. Let me know how it goes for you. [1] - On a side note, Unicorn is very aggressive about accepting connections, it speculatively tries to accept() after each application dispatch (which could've taken a long time) instead of running select() on the listen socket first. -- Eric Wong