I think this applies to some cheap network cards. I can't find the article just now, but I did see an article about doing latency timings over a JMS impl. The author probably ran in it on his home PC or something. He found that his network card had an inherent latency built in, whereas good quality ones did not. To get round this, he did a ping-pong style test, but on the side of the test that bounces back the pong, added in a random delay > the card latency, and put the value of that delay into the message. When calculating the latency, this random delay is subtracted out again, to get the true latency of the message on the broker. Thinking about it, I can't really see how that gets round the issue, but it was something along those lines.
I wouldn't worry about it. On 27/09/2007, Martin Ritchie <[EMAIL PROTECTED]> wrote: > > On 17/09/2007, Alan Conway <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-08-31 at 19:26 +0100, Andrew Stitcher wrote: > > > Actually there is some reason to expect it might make a difference as > it > > > does mean that reading and writing in the client now happen in the > same > > > thread, where before they mostly happened in different threads. > > > > You mean the client cannot concurrently read/write on the same > > connection? That might make a difference since perftest can receive > > messages while it is sending them. > > > > Simple way to test it: modify one of the tests to use different > > connections for publish/subscribe vs. same connection. If different > > connections is faster then the threading limitation may be a problem. > > > > Cheers, > > Alan. > > I know this was ages ago but just catching up on the C++ emails :) > > One thing to note from an IO performance point of view is that while > your app may read/write to the socket in two threads. (Something mina > doesn't do in Java btw) You throughput will then be limited by the > network hardware. Some cheaper cards only poll their buffer for read & > write on an timer. While the better cards have two processors so they > too can process read/write simultaneously. > > Anyhoo you probably knew this but just thought I'd share. > > -- > Martin Ritchie >
