[Eventmachine-talk] Ruby I/O

Thomas Ptacek
Tue, 13 Mar 2007 06:19:04 -0000

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
>