drb server efficiency while running in irb

[Joel VanderWerf]

I've noticed that a drb server running in irb handles requests at a
different rate depending on whether the main irb thread is running
separately or has joined the drb thread. It's *much* slower as a
separate thread. Typically the difference is about 1000 req/sec vs. 3
req./sec. That is puzzling to me because the irb thread isn't doing
anything but waiting for input. Both threads are priority 0, not that it
should matter.

The example is based on the Pickaxe drb example--see below. My ruby
version is:

$ ruby -v
ruby 1.9.0 (2004-01-08) [i686-linux]

The really *bizarre* behavior is that if I make the irb thread (the one
that's running alongside the drb thread) do some work, like:

irb(main):019:0> 500000.times {10**100; 0}

then the server gets *faster*, up to 15-20 req/sec.

If the irb thread sleeps, then the server gets up to 600-700 req/sec
(which makes some sense).

Increasing the DRb.thread.priority helps a bit (up to 15 req/sec)

Any theories? Suggestions?

----

==== paste this into irb, with or without the last line: ====
==== server.rb ====
require 'drb'

class TestServer
def doit
"Hello, Distributed World"
end
end

aServerObject = TestServer.new
DRb.start_service('druby://localhost:9000', aServerObject)
DRb.thread.join # Without this line, drb service is much slower
================

==== run this as script or from irb ====
==== client.rb ====
require 'drb'
DRb.start_service()
obj = DRbObject.new(nil, 'druby://localhost:9000')

n = 1000

z0 = Time.now
n.times do
obj.doit
end
z1 = Time.now

puts "Elapsed time: #{z1-z0}", "Rate: #{n/(z1-z0)} requests per second"
================

 

[Joel VanderWerf]

I've noticed that a drb server running in irb handles requests at a
different rate depending on whether the main irb thread is running
separately or has joined the drb thread. It's *much* slower as a
separate thread. Typically the difference is about 1000 req/sec vs. 3
req./sec. That is puzzling to me because the irb thread isn't doing
anything but waiting for input. Both threads are priority 0, not that it
should matter.

On further investigation, it seems the problem is drb in conjunction
with readline (and there's nothing particular about irb causing the
problem). Two other data points that may shed some light on the
drb+readline problem:

- Replacing drb with a generic threaded socket server restores normal
throughput (still using readline).

- Replacing readline with gets restores normal throughput (still using drb).

Very strange. Maybe something in the readline lib is keeping drb from
being responsive, but why doesn't that make the socket server
unresponsive, as well?

I'll spare y'all the code this time (but ask if you want it). Eventually
maybe I'll figure it out...