There seems to be an outstanding performance issue with
the aSocket library on single-CPU systems. Since I use
SMP systems for all of my testing this hasn't been
apparent to me until now, and I encourage someone to
look into this and let me know.
Try running 'Pingpong' from aSocket/test/p2p-bench on a
system (with either a single-CPU or SMP system on the
other end of the connection). You'll notice that
round-trip times are on the order of 10ms, 20ms, 30ms,
and so forth depending on certain factors (such as
message size). These intervals have to do with the
scheduling quantum in the Linux scheduler - would be
interested to see if they show up on other OS's as well.
My theory is that when writing a packet to the network,
the aSocket WriteEventHandler does not run and process
the packet write until the next scheduling quantum
*after* the Pingpong thread enqueues the outgoing
buffer for write - hence the 10ms (or more) delay.
Introducing Thread.currentThread().yield() calls at
various points seems to affect performance. On SMP
systems this is not an issue since WriteEventHandler
runs in parallel with the Pingpong thread.
The fix should involve some tuning of the scheduling
loop in aSocketThreadManager.java. It's possible that
this problem is only an issue for a simplistic
benchmark like Pingpong, which represents a "worst case
scenario" in terms of a *single* event propagating from
user stage to aSocket. In a real application, many
events are in flight at any given time so this overhead
might not appear.
Log in to post a comment.