Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of robbie.gemmell@gmail.com
 designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ECFD2EA.4080905@blueyonder.co.uk>
References: <4ECF52D5.10609@blueyonder.co.uk>
	<4ECFC0F4.40807@redhat.com>
	<4ECFD2EA.4080905@blueyonder.co.uk>
Date: Mon, 28 Nov 2011 17:18:26 +0000
Message-ID: 
 <CAFitrpQs7ruj94ycEXo83D6oQj3hr8S9aci74NQBwgAM6jqyqw@mail.gmail.com>
Subject: Re: Connections from JMS take noticeably longer than from C++
From: Robbie Gemmell <robbie.gemmell@gmail.com>
To: users@qpid.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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> wro=
te:
> 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 clie=
nts
>> 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 comma=
nd
>> line tool it will connect every time it's run. If they write a script th=
at
>> uses the tool 100 times they will not be pleased to wait more than a min=
ute.
>> 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 th=
is
>> 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 =3D System.currentTimeMillis();
> System.out.println("Create Connection");
> =A0 =A0 =A0 =A0 =A0 Context jndi =3D new InitialContext(props);
> =A0 =A0 =A0 =A0 =A0 ConnectionFactory connectionFactory =3D
> (ConnectionFactory)jndi.lookup("ConnectionFactory");
> =A0 =A0 =A0 =A0 =A0 connection =3D connectionFactory.createConnection();
> long elapsed =3D (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 =3D
> connectionFactory.createConnection();" and it was still registering > 900=
ms
> 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'r=
e
> actually scripting qpid-config and qpid-route at the moment to restart an=
y
> links that might have died as a result of source broker restart (we're us=
ing
> queue routes). We've got a large federated topology and the script can ta=
ke
> several minutes to run, which is painful and results in us restricting ho=
w
> often we run it.
>
> Frase
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: =A0 =A0 =A0http://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