[Eventmachine-talk] Ruby I/O

Tony Arcieri
Tue, 13 Mar 2007 10:37:08 -0000

Well, the main problem I''m seeing here is that while select() is called
the
most, it runs relatively quick until you start adding descriptors.  As more
descriptors are added the amount of time each call takes increases, even
with no I/O activity, and with it the amount of system time incurred by the
process.

- Tony

On 3/13/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> I don''t want to sound pendantic, or, worse, dense, but select() is
> USUALLY at the top of the profile for an event-driven program. When
> something else (like write, or malloc) is instead, you know
> something''s wrong.
>
> >From reading this message, the only sense I got was that select
> occupies relatively more of the profile than everything else, which
> may be as it should be.
>
> The gettimeofday stuff is a problem. Every high-speed project I''ve
> worked on has replaced gettimeofday; it''s a drag on performance.
I''m
> pretty sure the "correct" answer now is to calibrate and use
rdtsc,
> the cycle counter, which is essentially free (costs about as much as a
> non-cached DRAM access). If you calibrate, you can convert from TSC
> cycles to a struct timeval to hand select().
>
> On 3/13/07, Tony Arcieri <tony at clickcaster.com> wrote:
> > When there aren''t many connections being monitored, calls to
select()
> are
> > quick.  However, as the number of descriptors select() is monitoring
> > increases, it takes an increasing amount of system time.  This results
> in a
> > shorter amount of time in which Ruby is running and more system time
> spent.
> >
> > This is, of course, in the context of synthetic benchmarks, and
I''d like
> to
> > do some more tests before I can really say how Ruby scales in terms of
> I/O.
> > In my initial tests with a higher number of connections select()
quickly
> > popped up as the primary system time consumer.
> >
> > Has anyone else gprofed Ruby I/O, and if so, what were your results?
> >
> > My tests were done with Ruby 1.8.5, but I also plan to do a set
against
> Ruby
> > 1.9, and a more extensive set of benchmarks I can graph and actually
get
> a
> > sense of the scalability.
> >
> > I''d also be extremely interested in benchmarking the
epoll-based kqueue.
> > While other synthetic benchmarks of epoll I''ve seen still
show O(n)
> > scalability with epoll, I''d be interested to see if
epoll_wait() calls
> so
> > quickly jump to the #1 system time consumer.
> >
> > --
> > Tony Arcieri
> > ClickCaster, Inc.
> > tony at clickcaster.com
> > (970) 232-4208
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>



--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
(970) 232-4208
-------------- next part --------------
An HTML attachment was scrubbed...