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 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: raindrops/last_data_recv Date: Fri, 25 Mar 2011 16:57:26 +0000 Message-ID: <20110325165726.GA719@dcvr.yhbt.net> References: <4D8C7AEA.5000901@mrtech.ru> <4D8C7AEA.5000901@mrtech.ru> 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 1301072258 2153 80.91.229.12 (25 Mar 2011 16:57:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2011 16:57:38 +0000 (UTC) To: raindrops@librelist.com Original-X-From: raindrops@librelist.com Fri Mar 25 17:57:33 2011 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:31 Archived-At: Received: from zedshaw.xen.prgmr.com ([64.71.167.205]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q3AKL-0002fG-1Y for gclrrg-raindrops@m.gmane.org; Fri, 25 Mar 2011 17:57:33 +0100 Received: from zedshaw.xen.prgmr.com (localhost [IPv6:::1]) by zedshaw.xen.prgmr.com (Postfix) with ESMTP id B9A6A21C3C4 for ; Fri, 25 Mar 2011 16:57:39 +0000 (UTC) Troex Nevelin wrote: > I've setup raindrops/last_data_recv with unicorn and rails: > > I'm able to access /_raindrops and /raindrops/last_data_recv. > The last one shows some aggregated data like Watcher, but what > exactly? last_data_recv only works for TCP, but can be more accurate than watcher. watcher snapshots the queue length at a predefined interval (1s by default). This means data can slip through the cracks between intervals with watcher. last_data_recv measures the actual time a client spent in the TCP queue (rounded to the nearest 10ms[1]) before it was accept()-ed In my experience, Watcher is much easier to setup and use. I need to stick that in the rdoc/website somewhere... > As I understand it is possible to implement Watcher > functionality inside my App or in Raindrops middleware. If it is > true than I'll not need Watcher to monitor my unicorns and I'll > be able to collect the same data from middleware itself. Yes, but Watcher needs to be run in a single-process (but multi-threaded) for data sharing. Reading tcp_diag or /proc/net/unix can be expensive, so you really don't want multiple processes aggregating the same data. [1] - depends on the kernel timer resolution, I think, need to verify. -- Eric Wong