raindrops RubyGem user+dev discussion/patches/pulls/bugs/help
 help / Atom feed
* raindrops/last_data_recv
@ 2011-03-25 11:22 Troex Nevelin
  2011-03-25 16:57 ` Eric Wong
  0 siblings, 1 reply; 2+ messages in thread
From: Troex Nevelin @ 2011-03-25 11:22 UTC (permalink / raw)
  To: raindrops

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?

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.

Are my decisions correct?


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: raindrops/last_data_recv
  2011-03-25 11:22 raindrops/last_data_recv Troex Nevelin
@ 2011-03-25 16:57 ` Eric Wong
  0 siblings, 0 replies; 2+ messages in thread
From: Eric Wong @ 2011-03-25 16:57 UTC (permalink / raw)
  To: raindrops

Troex Nevelin <list@mrtech.ru> 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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-25 11:22 raindrops/last_data_recv Troex Nevelin
2011-03-25 16:57 ` Eric Wong

raindrops RubyGem user+dev discussion/patches/pulls/bugs/help

Archives are clonable:
	git clone --mirror https://bogomips.org/raindrops-public
	git clone --mirror http://ou63pmih66umazou.onion/raindrops-public

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.raindrops
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.raindrops

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox