Hi Fraser, I must admit in retrospect I was probably overestimating the impact of TCP_NODELAY. I had seen it make 30-40ms difference in performing synchronous commands, of which there are actually probably only 3-4 during a connection creation which would explain your change in results.
I expect it is either just classloading, or one-time initialisation of data structures, but I didnt do any real analysis into it. As the two-connections test showed it could be done in 8ms it seemed clear it wasnt a systemic overhead in creation of every connection, so I just manipulated the regular classloading sequence of 1 class and observed that made a significant difference. When comparing to the other clients its probably important to note that the JMS client is massive in comparison to them, both due to the JMS implementation classes themselves and the multi protocol support it has, plus the classes tend to be loaded/used in a different manner, all of which I imagine contributes to this. All that said, the worst I saw it perform is still twice as fast as your best number below, which seems a little odd. Can I ask what you were running your tests on? I dont imagine there is a JIRA for this, no. I assume you are really interested in this due to running things which only perform one connection and then shutdown? Robbie On 3 December 2011 17:21, Fraser Adams <[email protected]> wrote: > Hi Robbie, > I've just got round to trying this using the 0.12 C++ broker and Java > client. > > a connection URL of: > amqp://guest:guest@QpidJMS/vhost?brokerlist='tcp://localhost?retries='2147483647'&connectdelay='5000'' > > took 967ms > > a connection URL of: > amqp://guest:guest@QpidJMS/vhost?brokerlist='tcp://localhost?retries='2147483647'&connectdelay='5000'&tcp_nodelay='True'' > > took 892ms > > a connection URL of: > amqp://guest:guest@QpidJMS/vhost?brokerlist='tcp://localhost?tcp_nodelay='True'' > > took 870ms > > > So I'm not seeing the sort of differences that you seem to be getting with > TCP_NODELAY. In any case I'm not convinced that the C++ clients default to > tcp-nodelay = true and they connect in next to no time. > > Your other theory about class loading might be be what the real issue is, > but if that's the case why should Java suck so much? From what I can gather > python connection times are similar to the C++ ones and python is a bytecode > based language too is it not. > > It could definitely do with some investigation, taking the best part of a > second to connect isn't great :-( > > Should I raise a Jira or is there already one covering this? > > Frase > > > > Robbie Gemmell wrote: >> >> I know you are using the C++ broker from your previous posts. I just >> used the Java broker as I had one running and it seemed clear it wasnt >> broker related, both from my hunches and the previous tests. >> >> I expect a lot of the additional difference you are seeing is going to >> be TCP_NODELAY related. 420ms was craptacular if every connection took >> that long, but the next test showed it doesnt and short of forcing the >> JVM to load classes at points it doesnt actaually need them im not >> sure we can improve that. (I was however surprised it apparently makes >> that much difference) >> >> Robbie >> >> > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
