You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Fraser Adams <fr...@blueyonder.co.uk> on 2011/12/03 18:21:25 UTC
Re: Connections from JMS take noticeably longer than from C++
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:users-subscribe@qpid.apache.org
Re: Connect to broker over a socket?
Posted by Robbie Gemmell <ro...@gmail.com>.
Hi Joe,
You can certainly bypass the ConnectionFactory and JNDI by using the
underlying implementation classes of the client, eg just using the
AMQConnection class directly. This wouldnt normally be advisable
though since it isnt intended as the supported API and can change
without notice, but either way as per my previous email on the matter
you would still need to work around limitations of running on Android
because the clients implementation classes implement JMS which itself
lives in the javax namespace.
Robbie
On 3 December 2011 18:00, Joe Porto <Jo...@agilex.com> wrote:
> Is there anyway to connect to a broker over a socket? I don't want to go through the normal connection factory route because I am working on putting a client library on the android platform. The droid platform does not support JNDI, javax, etc.
> ---------------------------------------------------------------------
> 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
Connect to broker over a socket?
Posted by Joe Porto <Jo...@agilex.com>.
Is there anyway to connect to a broker over a socket? I don't want to go through the normal connection factory route because I am working on putting a client library on the android platform. The droid platform does not support JNDI, javax, etc.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Connections from JMS take noticeably longer than from C++
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Robbie Gemmell wrote:
> 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
>
>
Hi Robbie you're correct that I'm mainly interested in this because I've
been putting together a few command line clients which generally perform
one connection then shutdown, though it's obviously not an ideal
situation whatever the scenario. To be fair I only really noticed how
bad it was when I was monitoring qpid-printevents and starting up a
variety of C++ and Java clients and I saw a noticeable lag between
starting and the createConnection event with the Java clients which
prompted me to start measuring.
It is indeed odd that the worst you saw was still twice as fast as mine
(though 2x really sucky is still quite sucky :-)). My results are pretty
consistent over a few different JMS clients.
My box is a fairly reasonable one, it's a core 2 duo based laptop
(Intel(R) Core(TM)2 Duo CPU P7450 @ 2.13GHz). I "guess" one
possibility is that it has CPU scaling - when I run cat /proc/cpuinfo
when idle it reports "cpu MHz : 800.000" though in my experience
it scales up pretty quickly under load, I'd be surprised if that
accounts for the difference as I ran my test several times in succession
with similar results.
As mentioned previously I've been using Qpid 0.12 with the C++ broker
and Java Client (on Ubuntu Linux) and the figures I mentioned were
obtained using a pretty simple currentTimeMillis delta before and after
the ConnectionFactory createConnection() call.
I might do a bit of digging on this myself it's piqued my curiosity :-)
Would you mind if I raised a Jira?
Regards,
Frase
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Connections from JMS take noticeably longer than from C++
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <fr...@blueyonder.co.uk> 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:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org