qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Connections from JMS take noticeably longer than from C++
Date Mon, 28 Nov 2011 18:48:03 GMT
Cheers Robbie,
It was Alan who had previously asked whether I was using the Java 
broker  which is why I mentioned it. I'll have a play with the 
TCP_NODELAY stuff and get back to you on my results.

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
>
> On 28 November 2011 18:04, Fraser Adams <fraser.adams@blueyonder.co.uk> 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 <fraser.adams@blueyonder.co.uk>
>>> 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:users-subscribe@qpid.apache.org
>>>>
>>>>
>>>>
>>>>         
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project:      http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>   


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message