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]
