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 On 28 November 2011 18:04, Fraser Adams <[email protected]> wrote: > Alan & Robbie just to be clear I'm talking about connecting from a JMS > client to the C++ broker (specifically it was the 0.10 broker but I got > similar results with the 0.8 C++ broker) > > The client runtime was 0.10. > > I would try changing the TCP_NODELAY myself to see what happens, but I'm > currently without a working broker :-( (see my posts on the woes I'm having > upgrading to 0.12....) > > Robbie you say 420ms is craptacular - imagine how I'm feeling seeing 980ms. > > Still even that's better than having a broken broker :-D > > Frase > > Robbie Gemmell wrote: >> >> A couple of things occur to me here, TCP_NODELAY and classloading. >> >> I changed the setting of TCP_NODELAY for 0.14 and trunk for the Java >> client to true, from false previously. I would expect that to make a >> somewhat massive difference here due to the chatty synchronous nature >> of the connection setup. What version of client are you testing with? >> >> I tried a similar test using the trunk Java broker and client and got >> a fairly craptacular 420ms on my first attempt. However, doing two >> Connections instead of just one, the second connection got as low as >> 8ms. That suggested the test may be incurring some one-time-only >> overhead on the first Connection. Looking through the connection >> process and just picking a class to load in advance of doing the first >> Connection, I got the first connection time down by 300ms without any >> other changes, suggesting that classloading is indeed part of the >> 'problem'. >> >> Robbie >> >> On 25 November 2011 17:39, Fraser Adams <[email protected]> >> wrote: >> >>> >>> Alan Conway wrote: >>> >>>> >>>> There's no reason at the AMQP layer why it should be this slow. I don't >>>> know if JMS imposes something that takes a long time - do other JMS >>>> clients >>>> have the same problem? If not then it should be fixed. The "created >>>> infrequently" excuse doesn't hold up. e.g. if someone is writing a >>>> command >>>> line tool it will connect every time it's run. If they write a script >>>> that >>>> uses the tool 100 times they will not be pleased to wait more than a >>>> minute. >>>> The slow startup of the management clients infuriates me for this very >>>> reason - its creating a lot of drag in our own test suite. Apparently >>>> this >>>> will be better with qmf2, but i digress. >>>> >>>> >>>> >>> >>> Hi Alan, >>> I know I'm not imagining it because I've just done the following: >>> >>> long _startTime = System.currentTimeMillis(); >>> System.out.println("Create Connection"); >>> Context jndi = new InitialContext(props); >>> ConnectionFactory connectionFactory = >>> (ConnectionFactory)jndi.lookup("ConnectionFactory"); >>> connection = connectionFactory.createConnection(); >>> long elapsed = (long)Math.round(System.currentTimeMillis() - _startTime); >>> System.out.println("Creating connection took " + elapsed); >>> >>> And it's consistently telling me it's taking between ~ 920 and 990 >>> milliseconds >>> >>> So that backs up my gut feeling that "it seems a bit slow" >>> >>> I moved the "_startTime" bit to just before "connection = >>> connectionFactory.createConnection();" and it was still registering > >>> 900ms >>> so it looks like the problem is somewhere in createConnection(). >>> >>> If someone can suggest something stupid that I might be doing that would >>> be >>> great, otherwise I'll raise a Jira. >>> >>> I totally agree that "created infrequently" excuse doesn't hold up - >>> we're >>> actually scripting qpid-config and qpid-route at the moment to restart >>> any >>> links that might have died as a result of source broker restart (we're >>> using >>> queue routes). We've got a large federated topology and the script can >>> take >>> several minutes to run, which is painful and results in us restricting >>> how >>> often we run it. >>> >>> Frase >>> >>> >>> --------------------------------------------------------------------- >>> 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] >> >> >> > > > --------------------------------------------------------------------- > 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]
