Hi all, I was looking into some sluggish consumer creation performance with the Java client for a posting on the user list, and eventually narrowed the issue down to TCP_NODELAY being set false by default, leading to ExecutionSyncs taking an extraordinary amount of time to complete. This made every consumer creation take 40-80ms on average, depending on whether the queue already existed or not (which influences the operations and number of syncs performed). Enabling TCP_NODLAY gets this process down to 2-3ms.
We have previosuly noted poorer performance with the Java broker using 0-10 than it managed historically with its 0-9 support (which used a different IO layer on the client until recently), especially when using transient messages and transactions. Running some noddy tests sugggests TCP_NODELAY (which is enabled on the broker by default) to be the root cause of those issues too, because it also caused performance to increase somewhere between mildly noticable and mouth open levels depending on what you are doing. I understand there may be certain situations where this is slightly slower and that it could lead to higher bandwidth usage in some cases, but the effect of enabling it seems generally far too positive not to do so by default (which is what some other messaging products seem to do). Is there a strong argument not to? Does anyone know off hand what the other clients do? I plan to change the default for the Java client to true in a day or two unless talked out of it. Robbie --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
