[Eventmachine-talk] Ruby I/O

Tony Arcieri
Tue, 13 Mar 2007 00:20:59 -0000

This thread primarily addresses Francis, although I''d like to hear from
anyone interested in the subject.  Recently I''ve been asking around
with
various people, namely Koichi Sasada (author of the new Ruby VM) and
ruby-core about how to address the issue of Ruby''s I/O performance.

I''ve seen a number of interesting things in gprof, including a number
of
platform-specific oddities.  On Linux, during an I/O handling event loop,
Ruby spends a relatively large amount of time calling sigprocmask() (this
doesn''t occur on MacOS X).  When running EventMachine, there are a
large
number of calls to gettimeofday() (which I assume EventMachine is using for
its timer scheduling).  However, the overwhelming number of calls are to
select(), although this number decreased with an increasing number of
connections.

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
-------------- next part --------------
An HTML attachment was scrubbed...