You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by David Stewart <Da...@igindex.co.uk> on 2010/02/25 17:51:05 UTC
SubscriptionManager performance problem.
Hi all,
we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly? Is there a better way for us to achieve the result we require?
for (int i=0; i < 20000; ++i) {
std::stringstream ss; ss << "listener" << i;
// Try and declare the exchange. Will succeed even if it already exists.
oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
qpid::client::arg::type="fanout",
qpid::client::arg::alternateExchange=std::string(),
qpid::client::arg::passive=false,
qpid::client::arg::durable=true);
oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
qpid::client::arg::exclusive=true,
qpid::client::arg::autoDelete=false);
oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
qpid::client::arg::queue=ss.str(),
qpid::client::arg::bindingKey=ss.str());
oSubscriptionManager.subscribe(*this, ss.str());
}
Regards,
Dave
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/25/2010 11:51 AM, David Stewart wrote:
> Hi all,
> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>
> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>
> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly? Is there a better way for us to achieve the result we require?
>
> for (int i=0; i< 20000; ++i) {
> std::stringstream ss; ss<< "listener"<< i;
>
>
> // Try and declare the exchange. Will succeed even if it already exists.
> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::type="fanout",
> qpid::client::arg::alternateExchange=std::string(),
> qpid::client::arg::passive=false,
> qpid::client::arg::durable=true);
>
> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
> qpid::client::arg::exclusive=true,
> qpid::client::arg::autoDelete=false);
>
> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::queue=ss.str(),
> qpid::client::arg::bindingKey=ss.str());
>
> oSubscriptionManager.subscribe(*this, ss.str());
> }
The Session calls above are synchronous, you can make them asynchronous by doing:
async(oSession).exchangeDeclare() etc.
That will probably make a big difference. Unfortunately there isn't currently a
way to make the SessionManager::subscribe() call asynchronous. You might get
better mileage by doing the asynchronous declare/bind in one loop and the
subscribe()s in another.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Rafael Schloming <ra...@redhat.com>.
Alan Conway wrote:
> On 03/01/2010 11:45 PM, Rafael Schloming wrote:
>> Gordon Sim wrote:
>>> On 02/26/2010 03:09 PM, Alan Conway wrote:
>>>> On 02/26/2010 09:47 AM, Gordon Sim wrote:
>>>>> On 02/26/2010 02:29 PM, Alan Conway wrote:
>>>>>> Gordon/Rafi: this raises an interesting question for the new APIs. It
>>>>>> seems like async declare/bind/subscribe are important features for
>>>>>> cases
>>>>>> like this.
>>>>>
>>>>> I agree, this is an interesting case. On the face of it my initial
>>>>> suggestion would be a single receiver for an address using create:
>>>>> always and a list of binding 20,000 long.
>>>>
>>>> You mean construct a single address string with 20,000 bindings in it?
>>>
>>> Wouldn't necessarily need to be done as a string. The
>>> qpid::messaging::Address class can be manipulated directly. However...
>>>
>>>> That doesn't sound practical. I think we need a way to split apart the
>>>> process of constructing a receiver in this case so we can create a
>>>> receiver and then incrementally add bindings to it. That would seem
>>>> like
>>>> a useful feature in any case - the set of things a receiver is
>>>> interested in may change dynamically over its lifetime so it would be
>>>> good to be able to add/remove bindings to a receiver.
>>>
>>> ...I can see that being a valuable addition for some cases, yes.
>>
>> It turns out that the python client (sort of by accident) is actually
>> capable of doing an async query/declare/bind/subscribe.
>>
>> It just so happens that if you create receivers on a disconnected
>> connection they get created locally, but not remotely until the
>> connection is connected again, and when this happens they're all created
>> in a big batch.
>>
>> Out of curiosity I tried creating 20,000 separate receivers in this
>> manner with the python client and it took about 75 seconds:
>>
>> c = Connection("localhost", 5672)
>> s = c.session()
>>
>> rcvs = []
>> for i in range(20000):
>> rcvs.append(s.receiver("amq.topic/%s" % i))
>>
>> print "connecting"
>> c.connect()
>> print "connected"
>>
>> Unfortunately if you connect() before creating the receivers then the
>> receiver() call will block until the resulting receiver is fully
>> subscribed before returning, thereby rendering the whole process
>> synchronous again. This version of the code was still running after 30
>> minutes, although part of that is due to a linear search through the
>> receivers list:
>>
>> c = Connection("localhost", 5672)
>> s = c.session()
>>
>> print "connecting"
>> c.connect()
>>
>> rcvs = []
>> for i in range(20000):
>> rcvs.append(s.receiver("amq.topic/%s" % i))
>>
>> print "connected"
>>
>> It would, however, be straightforward to add an option to the receiver
>> call to control explicitly whether or not it blocks, thereby permitting
>> asynchronous receiver creation on a connected connection.
>>
>
> Sounds like that would be a worthwhile extension before we release the
> API, with a similar option on the C++ side.
Agreed
> What about declaring
> queues/exchanges and creating bindings?
Addresses can include queue, exchange, and binding declarations, so you
can always do this via asynchronously declaring a whole bunch of
senders. This is natural if you intend to use the senders, but it is
obviously a bit hackish if you are just creating them for the side effect.
I do think we need a better way to do this in the latter case, however I
think that this would fall more into the management side of things than
into the messaging API proper. We just need to be sure they work
naturally with each other.
One thing that isn't covered though is the ability to adjust an address
while in use, e.g. update the address definition to add or remove a
binding without resorting to the above hack. IMHO this is something that
should ultimately be covered in a slightly nicer way by the API,
although I think we can add it in later without too much trouble.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 03/01/2010 11:45 PM, Rafael Schloming wrote:
> Gordon Sim wrote:
>> On 02/26/2010 03:09 PM, Alan Conway wrote:
>>> On 02/26/2010 09:47 AM, Gordon Sim wrote:
>>>> On 02/26/2010 02:29 PM, Alan Conway wrote:
>>>>> Gordon/Rafi: this raises an interesting question for the new APIs. It
>>>>> seems like async declare/bind/subscribe are important features for
>>>>> cases
>>>>> like this.
>>>>
>>>> I agree, this is an interesting case. On the face of it my initial
>>>> suggestion would be a single receiver for an address using create:
>>>> always and a list of binding 20,000 long.
>>>
>>> You mean construct a single address string with 20,000 bindings in it?
>>
>> Wouldn't necessarily need to be done as a string. The
>> qpid::messaging::Address class can be manipulated directly. However...
>>
>>> That doesn't sound practical. I think we need a way to split apart the
>>> process of constructing a receiver in this case so we can create a
>>> receiver and then incrementally add bindings to it. That would seem like
>>> a useful feature in any case - the set of things a receiver is
>>> interested in may change dynamically over its lifetime so it would be
>>> good to be able to add/remove bindings to a receiver.
>>
>> ...I can see that being a valuable addition for some cases, yes.
>
> It turns out that the python client (sort of by accident) is actually
> capable of doing an async query/declare/bind/subscribe.
>
> It just so happens that if you create receivers on a disconnected
> connection they get created locally, but not remotely until the
> connection is connected again, and when this happens they're all created
> in a big batch.
>
> Out of curiosity I tried creating 20,000 separate receivers in this
> manner with the python client and it took about 75 seconds:
>
> c = Connection("localhost", 5672)
> s = c.session()
>
> rcvs = []
> for i in range(20000):
> rcvs.append(s.receiver("amq.topic/%s" % i))
>
> print "connecting"
> c.connect()
> print "connected"
>
> Unfortunately if you connect() before creating the receivers then the
> receiver() call will block until the resulting receiver is fully
> subscribed before returning, thereby rendering the whole process
> synchronous again. This version of the code was still running after 30
> minutes, although part of that is due to a linear search through the
> receivers list:
>
> c = Connection("localhost", 5672)
> s = c.session()
>
> print "connecting"
> c.connect()
>
> rcvs = []
> for i in range(20000):
> rcvs.append(s.receiver("amq.topic/%s" % i))
>
> print "connected"
>
> It would, however, be straightforward to add an option to the receiver
> call to control explicitly whether or not it blocks, thereby permitting
> asynchronous receiver creation on a connected connection.
>
Sounds like that would be a worthwhile extension before we release the API, with
a similar option on the C++ side. What about declaring queues/exchanges and
creating bindings?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> On 02/26/2010 03:09 PM, Alan Conway wrote:
>> On 02/26/2010 09:47 AM, Gordon Sim wrote:
>>> On 02/26/2010 02:29 PM, Alan Conway wrote:
>>>> Gordon/Rafi: this raises an interesting question for the new APIs. It
>>>> seems like async declare/bind/subscribe are important features for
>>>> cases
>>>> like this.
>>>
>>> I agree, this is an interesting case. On the face of it my initial
>>> suggestion would be a single receiver for an address using create:
>>> always and a list of binding 20,000 long.
>>
>> You mean construct a single address string with 20,000 bindings in it?
>
> Wouldn't necessarily need to be done as a string. The
> qpid::messaging::Address class can be manipulated directly. However...
>
>> That doesn't sound practical. I think we need a way to split apart the
>> process of constructing a receiver in this case so we can create a
>> receiver and then incrementally add bindings to it. That would seem like
>> a useful feature in any case - the set of things a receiver is
>> interested in may change dynamically over its lifetime so it would be
>> good to be able to add/remove bindings to a receiver.
>
> ...I can see that being a valuable addition for some cases, yes.
It turns out that the python client (sort of by accident) is actually
capable of doing an async query/declare/bind/subscribe.
It just so happens that if you create receivers on a disconnected
connection they get created locally, but not remotely until the
connection is connected again, and when this happens they're all created
in a big batch.
Out of curiosity I tried creating 20,000 separate receivers in this
manner with the python client and it took about 75 seconds:
c = Connection("localhost", 5672)
s = c.session()
rcvs = []
for i in range(20000):
rcvs.append(s.receiver("amq.topic/%s" % i))
print "connecting"
c.connect()
print "connected"
Unfortunately if you connect() before creating the receivers then the
receiver() call will block until the resulting receiver is fully
subscribed before returning, thereby rendering the whole process
synchronous again. This version of the code was still running after 30
minutes, although part of that is due to a linear search through the
receivers list:
c = Connection("localhost", 5672)
s = c.session()
print "connecting"
c.connect()
rcvs = []
for i in range(20000):
rcvs.append(s.receiver("amq.topic/%s" % i))
print "connected"
It would, however, be straightforward to add an option to the receiver
call to control explicitly whether or not it blocks, thereby permitting
asynchronous receiver creation on a connected connection.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Gordon Sim <gs...@redhat.com>.
On 02/26/2010 03:09 PM, Alan Conway wrote:
> On 02/26/2010 09:47 AM, Gordon Sim wrote:
>> On 02/26/2010 02:29 PM, Alan Conway wrote:
>>> Gordon/Rafi: this raises an interesting question for the new APIs. It
>>> seems like async declare/bind/subscribe are important features for cases
>>> like this.
>>
>> I agree, this is an interesting case. On the face of it my initial
>> suggestion would be a single receiver for an address using create:
>> always and a list of binding 20,000 long.
>
> You mean construct a single address string with 20,000 bindings in it?
Wouldn't necessarily need to be done as a string. The
qpid::messaging::Address class can be manipulated directly. However...
> That doesn't sound practical. I think we need a way to split apart the
> process of constructing a receiver in this case so we can create a
> receiver and then incrementally add bindings to it. That would seem like
> a useful feature in any case - the set of things a receiver is
> interested in may change dynamically over its lifetime so it would be
> good to be able to add/remove bindings to a receiver.
...I can see that being a valuable addition for some cases, yes.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/26/2010 09:47 AM, Gordon Sim wrote:
> On 02/26/2010 02:29 PM, Alan Conway wrote:
>> Gordon/Rafi: this raises an interesting question for the new APIs. It
>> seems like async declare/bind/subscribe are important features for cases
>> like this.
>
> I agree, this is an interesting case. On the face of it my initial
> suggestion would be a single receiver for an address using create:
> always and a list of binding 20,000 long.
You mean construct a single address string with 20,000 bindings in it? That
doesn't sound practical. I think we need a way to split apart the process of
constructing a receiver in this case so we can create a receiver and then
incrementally add bindings to it. That would seem like a useful feature in any
case - the set of things a receiver is interested in may change dynamically over
its lifetime so it would be good to be able to add/remove bindings to a receiver.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Gordon Sim <gs...@redhat.com>.
On 02/26/2010 02:29 PM, Alan Conway wrote:
> Gordon/Rafi: this raises an interesting question for the new APIs. It
> seems like async declare/bind/subscribe are important features for cases
> like this.
I agree, this is an interesting case. On the face of it my initial
suggestion would be a single receiver for an address using create:
always and a list of binding 20,000 long. On the c++ side the binds
would all be async in this case, but I haven't ever tested that large a
set out!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/26/2010 05:13 AM, David Stewart wrote:
> The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
> The bottleneck still appears to be the SessionManager though.
>
> I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
> Should I see better performance from a linux broker?
>
I suspect the synchronous subscribe() is still the big hold up.
Attached patch adds a synchronous option to SubscriptionSettings
Use it like this:
SubscriptionSettings settings;
settings.synchronous = false;
subs.subscribe(*this, queue, settings);
If it helps I'll consider committing it if there are no objections.
Gordon/Rafi: this raises an interesting question for the new APIs. It seems like
async declare/bind/subscribe are important features for cases like this. This
isn't the first such case, I seem to remember JPMC folks having a case where
they were declaring large quantities of queues and needed it to be async.
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/26/2010 05:13 AM, David Stewart wrote:
> The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
> The bottleneck still appears to be the SessionManager though.
>
> I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
> Should I see better performance from a linux broker?
I doubt it. The SessionManager::subscribe is synchronous regardless and I think
that's the big hold up.
>
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: 25 February 2010 17:39
> To: dev@qpid.apache.org
> Cc: David Stewart; users@qpid.apache.org
> Subject: Re: SubscriptionManager performance problem.
>
> On 02/25/2010 04:51 PM, David Stewart wrote:
>> Hi all,
>> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>>
>> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>>
>> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
>> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
>
> Is oSession an AsyncSession or a SyncSession (a plain Session is a SyncSession)? Each call to SubscriptionManager::subscribe() will involve a sync() which will certainly reduce the rate you can get through them, but 1000 in ~3 minutes seems slow even then.
>
>> Is there a better way for us to achieve the result we require?
>>
>> for (int i=0; i< 20000; ++i) {
>> std::stringstream ss; ss<< "listener"<< i;
>>
>>
>> // Try and declare the exchange. Will succeed even if it already exists.
>> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::type="fanout",
>> qpid::client::arg::alternateExchange=std::string(),
>> qpid::client::arg::passive=false,
>>
>> qpid::client::arg::durable=true);
>>
>> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
>> qpid::client::arg::exclusive=true,
>> qpid::client::arg::autoDelete=false);
>>
>> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::queue=ss.str(),
>>
>> qpid::client::arg::bindingKey=ss.str());
>>
>> oSubscriptionManager.subscribe(*this, ss.str()); }
>>
>> Regards,
>> Dave
>>
>> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/26/2010 05:13 AM, David Stewart wrote:
> The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
> The bottleneck still appears to be the SessionManager though.
>
> I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
> Should I see better performance from a linux broker?
I doubt it. The SessionManager::subscribe is synchronous regardless and I think
that's the big hold up.
>
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: 25 February 2010 17:39
> To: dev@qpid.apache.org
> Cc: David Stewart; users@qpid.apache.org
> Subject: Re: SubscriptionManager performance problem.
>
> On 02/25/2010 04:51 PM, David Stewart wrote:
>> Hi all,
>> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>>
>> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>>
>> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
>> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
>
> Is oSession an AsyncSession or a SyncSession (a plain Session is a SyncSession)? Each call to SubscriptionManager::subscribe() will involve a sync() which will certainly reduce the rate you can get through them, but 1000 in ~3 minutes seems slow even then.
>
>> Is there a better way for us to achieve the result we require?
>>
>> for (int i=0; i< 20000; ++i) {
>> std::stringstream ss; ss<< "listener"<< i;
>>
>>
>> // Try and declare the exchange. Will succeed even if it already exists.
>> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::type="fanout",
>> qpid::client::arg::alternateExchange=std::string(),
>> qpid::client::arg::passive=false,
>>
>> qpid::client::arg::durable=true);
>>
>> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
>> qpid::client::arg::exclusive=true,
>> qpid::client::arg::autoDelete=false);
>>
>> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::queue=ss.str(),
>>
>> qpid::client::arg::bindingKey=ss.str());
>>
>> oSubscriptionManager.subscribe(*this, ss.str()); }
>>
>> Regards,
>> Dave
>>
>> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/26/2010 08:56 AM, Gordon Sim wrote:
> On 02/26/2010 10:13 AM, David Stewart wrote:
>> The session was synchronous. Using the AsyncSession brought the 75
>> seconds down to 5-10 which is a fantastic improvement.
>> The bottleneck still appears to be the SessionManager though.
>
> SessionManager::subscribe() is synchronous, which will impact the rate.
> One tip is to turn off message flow when you subscribe (use
> SubscriptionSettings(FlowControl::messageWindow(0))) and then add credit
> to resize the window on each subscription after you are set up
> (Subscription::grantMessageCredit() or Session::messageFlow()) to enable
> messages to flow (this can be asynchronous). I get through 20000 in ~25
> secs on my laptop with that (see attached).
>
> However can I ask why you need a separate queue per exchange? Could you
> instead have one queue bound into each of the exchanges? That would be
> far more efficient (both for setup and at runtime) and would still give
> you all the messages sent to any of those exchanges.
That is probably a better solution than my patch for async subscribe.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/26/2010 08:56 AM, Gordon Sim wrote:
> On 02/26/2010 10:13 AM, David Stewart wrote:
>> The session was synchronous. Using the AsyncSession brought the 75
>> seconds down to 5-10 which is a fantastic improvement.
>> The bottleneck still appears to be the SessionManager though.
>
> SessionManager::subscribe() is synchronous, which will impact the rate.
> One tip is to turn off message flow when you subscribe (use
> SubscriptionSettings(FlowControl::messageWindow(0))) and then add credit
> to resize the window on each subscription after you are set up
> (Subscription::grantMessageCredit() or Session::messageFlow()) to enable
> messages to flow (this can be asynchronous). I get through 20000 in ~25
> secs on my laptop with that (see attached).
>
> However can I ask why you need a separate queue per exchange? Could you
> instead have one queue bound into each of the exchanges? That would be
> far more efficient (both for setup and at runtime) and would still give
> you all the messages sent to any of those exchanges.
That is probably a better solution than my patch for async subscribe.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: SubscriptionManager performance problem.
Posted by David Stewart <Da...@igindex.co.uk>.
Thanks Gordon. I'll fold your example into our code.
The only reaon we have a queue per exchange is that we can monitor queue lengths for individual instruments in the event of delays on our pricing. If it is optimal to have one queue per session then we can implement that.
Thanks for your help.
Regards,
Dave
-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com]
Sent: 26 February 2010 13:57
To: David Stewart
Cc: dev@qpid.apache.org; users@qpid.apache.org
Subject: Re: SubscriptionManager performance problem.
On 02/26/2010 10:13 AM, David Stewart wrote:
> The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
> The bottleneck still appears to be the SessionManager though.
SessionManager::subscribe() is synchronous, which will impact the rate.
One tip is to turn off message flow when you subscribe (use
SubscriptionSettings(FlowControl::messageWindow(0))) and then add credit to resize the window on each subscription after you are set up
(Subscription::grantMessageCredit() or Session::messageFlow()) to enable messages to flow (this can be asynchronous). I get through 20000 in ~25 secs on my laptop with that (see attached).
However can I ask why you need a separate queue per exchange? Could you instead have one queue bound into each of the exchanges? That would be far more efficient (both for setup and at runtime) and would still give you all the messages sent to any of those exchanges.
>
> I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
> Should I see better performance from a linux broker?
>
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: 25 February 2010 17:39
> To: dev@qpid.apache.org
> Cc: David Stewart; users@qpid.apache.org
> Subject: Re: SubscriptionManager performance problem.
>
> On 02/25/2010 04:51 PM, David Stewart wrote:
>> Hi all,
>> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>>
>> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>>
>> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
>> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
>
> Is oSession an AsyncSession or a SyncSession (a plain Session is a SyncSession)? Each call to SubscriptionManager::subscribe() will involve a sync() which will certainly reduce the rate you can get through them, but 1000 in ~3 minutes seems slow even then.
>
>> Is there a better way for us to achieve the result we require?
>>
>> for (int i=0; i< 20000; ++i) {
>> std::stringstream ss; ss<< "listener"<< i;
>>
>>
>> // Try and declare the exchange. Will succeed even if it already exists.
>> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::type="fanout",
>> qpid::client::arg::alternateExchange=std::string(),
>>
>> qpid::client::arg::passive=false,
>>
>> qpid::client::arg::durable=true);
>>
>> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
>> qpid::client::arg::exclusive=true,
>>
>> qpid::client::arg::autoDelete=false);
>>
>> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
>>
>> qpid::client::arg::queue=ss.str(),
>>
>> qpid::client::arg::bindingKey=ss.str());
>>
>> oSubscriptionManager.subscribe(*this, ss.str()); }
>>
>> Regards,
>> Dave
>>
>> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
RE: SubscriptionManager performance problem.
Posted by David Stewart <Da...@igindex.co.uk>.
Thanks Gordon. I'll fold your example into our code.
The only reaon we have a queue per exchange is that we can monitor queue lengths for individual instruments in the event of delays on our pricing. If it is optimal to have one queue per session then we can implement that.
Thanks for your help.
Regards,
Dave
-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com]
Sent: 26 February 2010 13:57
To: David Stewart
Cc: dev@qpid.apache.org; users@qpid.apache.org
Subject: Re: SubscriptionManager performance problem.
On 02/26/2010 10:13 AM, David Stewart wrote:
> The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
> The bottleneck still appears to be the SessionManager though.
SessionManager::subscribe() is synchronous, which will impact the rate.
One tip is to turn off message flow when you subscribe (use
SubscriptionSettings(FlowControl::messageWindow(0))) and then add credit to resize the window on each subscription after you are set up
(Subscription::grantMessageCredit() or Session::messageFlow()) to enable messages to flow (this can be asynchronous). I get through 20000 in ~25 secs on my laptop with that (see attached).
However can I ask why you need a separate queue per exchange? Could you instead have one queue bound into each of the exchanges? That would be far more efficient (both for setup and at runtime) and would still give you all the messages sent to any of those exchanges.
>
> I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
> Should I see better performance from a linux broker?
>
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: 25 February 2010 17:39
> To: dev@qpid.apache.org
> Cc: David Stewart; users@qpid.apache.org
> Subject: Re: SubscriptionManager performance problem.
>
> On 02/25/2010 04:51 PM, David Stewart wrote:
>> Hi all,
>> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>>
>> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>>
>> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
>> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
>
> Is oSession an AsyncSession or a SyncSession (a plain Session is a SyncSession)? Each call to SubscriptionManager::subscribe() will involve a sync() which will certainly reduce the rate you can get through them, but 1000 in ~3 minutes seems slow even then.
>
>> Is there a better way for us to achieve the result we require?
>>
>> for (int i=0; i< 20000; ++i) {
>> std::stringstream ss; ss<< "listener"<< i;
>>
>>
>> // Try and declare the exchange. Will succeed even if it already exists.
>> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::type="fanout",
>> qpid::client::arg::alternateExchange=std::string(),
>>
>> qpid::client::arg::passive=false,
>>
>> qpid::client::arg::durable=true);
>>
>> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
>> qpid::client::arg::exclusive=true,
>>
>> qpid::client::arg::autoDelete=false);
>>
>> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
>>
>> qpid::client::arg::queue=ss.str(),
>>
>> qpid::client::arg::bindingKey=ss.str());
>>
>> oSubscriptionManager.subscribe(*this, ss.str()); }
>>
>> Regards,
>> Dave
>>
>> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Gordon Sim <gs...@redhat.com>.
On 02/26/2010 10:13 AM, David Stewart wrote:
> The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
> The bottleneck still appears to be the SessionManager though.
SessionManager::subscribe() is synchronous, which will impact the rate.
One tip is to turn off message flow when you subscribe (use
SubscriptionSettings(FlowControl::messageWindow(0))) and then add credit
to resize the window on each subscription after you are set up
(Subscription::grantMessageCredit() or Session::messageFlow()) to enable
messages to flow (this can be asynchronous). I get through 20000 in ~25
secs on my laptop with that (see attached).
However can I ask why you need a separate queue per exchange? Could you
instead have one queue bound into each of the exchanges? That would be
far more efficient (both for setup and at runtime) and would still give
you all the messages sent to any of those exchanges.
>
> I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
> Should I see better performance from a linux broker?
>
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: 25 February 2010 17:39
> To: dev@qpid.apache.org
> Cc: David Stewart; users@qpid.apache.org
> Subject: Re: SubscriptionManager performance problem.
>
> On 02/25/2010 04:51 PM, David Stewart wrote:
>> Hi all,
>> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>>
>> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>>
>> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
>> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
>
> Is oSession an AsyncSession or a SyncSession (a plain Session is a SyncSession)? Each call to SubscriptionManager::subscribe() will involve a sync() which will certainly reduce the rate you can get through them, but 1000 in ~3 minutes seems slow even then.
>
>> Is there a better way for us to achieve the result we require?
>>
>> for (int i=0; i< 20000; ++i) {
>> std::stringstream ss; ss<< "listener"<< i;
>>
>>
>> // Try and declare the exchange. Will succeed even if it already exists.
>> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::type="fanout",
>> qpid::client::arg::alternateExchange=std::string(),
>> qpid::client::arg::passive=false,
>>
>> qpid::client::arg::durable=true);
>>
>> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
>> qpid::client::arg::exclusive=true,
>> qpid::client::arg::autoDelete=false);
>>
>> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::queue=ss.str(),
>>
>> qpid::client::arg::bindingKey=ss.str());
>>
>> oSubscriptionManager.subscribe(*this, ss.str()); }
>>
>> Regards,
>> Dave
>>
>> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
Re: SubscriptionManager performance problem.
Posted by Gordon Sim <gs...@redhat.com>.
On 02/26/2010 10:13 AM, David Stewart wrote:
> The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
> The bottleneck still appears to be the SessionManager though.
SessionManager::subscribe() is synchronous, which will impact the rate.
One tip is to turn off message flow when you subscribe (use
SubscriptionSettings(FlowControl::messageWindow(0))) and then add credit
to resize the window on each subscription after you are set up
(Subscription::grantMessageCredit() or Session::messageFlow()) to enable
messages to flow (this can be asynchronous). I get through 20000 in ~25
secs on my laptop with that (see attached).
However can I ask why you need a separate queue per exchange? Could you
instead have one queue bound into each of the exchanges? That would be
far more efficient (both for setup and at runtime) and would still give
you all the messages sent to any of those exchanges.
>
> I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
> Should I see better performance from a linux broker?
>
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: 25 February 2010 17:39
> To: dev@qpid.apache.org
> Cc: David Stewart; users@qpid.apache.org
> Subject: Re: SubscriptionManager performance problem.
>
> On 02/25/2010 04:51 PM, David Stewart wrote:
>> Hi all,
>> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>>
>> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>>
>> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
>> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
>
> Is oSession an AsyncSession or a SyncSession (a plain Session is a SyncSession)? Each call to SubscriptionManager::subscribe() will involve a sync() which will certainly reduce the rate you can get through them, but 1000 in ~3 minutes seems slow even then.
>
>> Is there a better way for us to achieve the result we require?
>>
>> for (int i=0; i< 20000; ++i) {
>> std::stringstream ss; ss<< "listener"<< i;
>>
>>
>> // Try and declare the exchange. Will succeed even if it already exists.
>> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::type="fanout",
>> qpid::client::arg::alternateExchange=std::string(),
>> qpid::client::arg::passive=false,
>>
>> qpid::client::arg::durable=true);
>>
>> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
>> qpid::client::arg::exclusive=true,
>> qpid::client::arg::autoDelete=false);
>>
>> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
>> qpid::client::arg::queue=ss.str(),
>>
>> qpid::client::arg::bindingKey=ss.str());
>>
>> oSubscriptionManager.subscribe(*this, ss.str()); }
>>
>> Regards,
>> Dave
>>
>> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/26/2010 05:13 AM, David Stewart wrote:
> The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
> The bottleneck still appears to be the SessionManager though.
>
> I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
> Should I see better performance from a linux broker?
>
I suspect the synchronous subscribe() is still the big hold up.
Attached patch adds a synchronous option to SubscriptionSettings
Use it like this:
SubscriptionSettings settings;
settings.synchronous = false;
subs.subscribe(*this, queue, settings);
If it helps I'll consider committing it if there are no objections.
Gordon/Rafi: this raises an interesting question for the new APIs. It seems like
async declare/bind/subscribe are important features for cases like this. This
isn't the first such case, I seem to remember JPMC folks having a case where
they were declaring large quantities of queues and needed it to be async.
RE: SubscriptionManager performance problem.
Posted by David Stewart <Da...@igindex.co.uk>.
The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
The bottleneck still appears to be the SessionManager though.
I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
Should I see better performance from a linux broker?
-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com]
Sent: 25 February 2010 17:39
To: dev@qpid.apache.org
Cc: David Stewart; users@qpid.apache.org
Subject: Re: SubscriptionManager performance problem.
On 02/25/2010 04:51 PM, David Stewart wrote:
> Hi all,
> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>
> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>
> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
Is oSession an AsyncSession or a SyncSession (a plain Session is a SyncSession)? Each call to SubscriptionManager::subscribe() will involve a sync() which will certainly reduce the rate you can get through them, but 1000 in ~3 minutes seems slow even then.
> Is there a better way for us to achieve the result we require?
>
> for (int i=0; i< 20000; ++i) {
> std::stringstream ss; ss<< "listener"<< i;
>
>
> // Try and declare the exchange. Will succeed even if it already exists.
> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::type="fanout",
> qpid::client::arg::alternateExchange=std::string(),
> qpid::client::arg::passive=false,
>
> qpid::client::arg::durable=true);
>
> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
> qpid::client::arg::exclusive=true,
> qpid::client::arg::autoDelete=false);
>
> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::queue=ss.str(),
>
> qpid::client::arg::bindingKey=ss.str());
>
> oSubscriptionManager.subscribe(*this, ss.str()); }
>
> Regards,
> Dave
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: SubscriptionManager performance problem.
Posted by David Stewart <Da...@igindex.co.uk>.
The session was synchronous. Using the AsyncSession brought the 75 seconds down to 5-10 which is a fantastic improvement.
The bottleneck still appears to be the SessionManager though.
I should mention that we're running a vc90 C++ client against a vc90 C++ broker. Could the broker be the problem?
Should I see better performance from a linux broker?
-----Original Message-----
From: Gordon Sim [mailto:gsim@redhat.com]
Sent: 25 February 2010 17:39
To: dev@qpid.apache.org
Cc: David Stewart; users@qpid.apache.org
Subject: Re: SubscriptionManager performance problem.
On 02/25/2010 04:51 PM, David Stewart wrote:
> Hi all,
> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>
> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>
> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
Is oSession an AsyncSession or a SyncSession (a plain Session is a SyncSession)? Each call to SubscriptionManager::subscribe() will involve a sync() which will certainly reduce the rate you can get through them, but 1000 in ~3 minutes seems slow even then.
> Is there a better way for us to achieve the result we require?
>
> for (int i=0; i< 20000; ++i) {
> std::stringstream ss; ss<< "listener"<< i;
>
>
> // Try and declare the exchange. Will succeed even if it already exists.
> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::type="fanout",
> qpid::client::arg::alternateExchange=std::string(),
> qpid::client::arg::passive=false,
>
> qpid::client::arg::durable=true);
>
> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
> qpid::client::arg::exclusive=true,
> qpid::client::arg::autoDelete=false);
>
> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::queue=ss.str(),
>
> qpid::client::arg::bindingKey=ss.str());
>
> oSubscriptionManager.subscribe(*this, ss.str()); }
>
> Regards,
> Dave
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Gordon Sim <gs...@redhat.com>.
On 02/25/2010 04:51 PM, David Stewart wrote:
> Hi all,
> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>
> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>
> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
Is oSession an AsyncSession or a SyncSession (a plain Session is a
SyncSession)? Each call to SubscriptionManager::subscribe() will involve
a sync() which will certainly reduce the rate you can get through them,
but 1000 in ~3 minutes seems slow even then.
> Is there a better way for us to achieve the result we require?
>
> for (int i=0; i< 20000; ++i) {
> std::stringstream ss; ss<< "listener"<< i;
>
>
> // Try and declare the exchange. Will succeed even if it already exists.
> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::type="fanout",
> qpid::client::arg::alternateExchange=std::string(),
> qpid::client::arg::passive=false,
> qpid::client::arg::durable=true);
>
> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
> qpid::client::arg::exclusive=true,
> qpid::client::arg::autoDelete=false);
>
> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::queue=ss.str(),
> qpid::client::arg::bindingKey=ss.str());
>
> oSubscriptionManager.subscribe(*this, ss.str());
> }
>
> Regards,
> Dave
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Alan Conway <ac...@redhat.com>.
On 02/25/2010 11:51 AM, David Stewart wrote:
> Hi all,
> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>
> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>
> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly? Is there a better way for us to achieve the result we require?
>
> for (int i=0; i< 20000; ++i) {
> std::stringstream ss; ss<< "listener"<< i;
>
>
> // Try and declare the exchange. Will succeed even if it already exists.
> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::type="fanout",
> qpid::client::arg::alternateExchange=std::string(),
> qpid::client::arg::passive=false,
> qpid::client::arg::durable=true);
>
> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
> qpid::client::arg::exclusive=true,
> qpid::client::arg::autoDelete=false);
>
> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::queue=ss.str(),
> qpid::client::arg::bindingKey=ss.str());
>
> oSubscriptionManager.subscribe(*this, ss.str());
> }
The Session calls above are synchronous, you can make them asynchronous by doing:
async(oSession).exchangeDeclare() etc.
That will probably make a big difference. Unfortunately there isn't currently a
way to make the SessionManager::subscribe() call asynchronous. You might get
better mileage by doing the asynchronous declare/bind in one loop and the
subscribe()s in another.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: SubscriptionManager performance problem.
Posted by David Stewart <Da...@igindex.co.uk>.
I should have mentioned this is in the C++ API for qpid 0.5,
Sorry,
Dave
-----Original Message-----
From: David Stewart
Sent: 25 February 2010 16:51
To: dev@qpid.apache.org
Cc: users@qpid.apache.org
Subject: SubscriptionManager performance problem.
Hi all,
we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly? Is there a better way for us to achieve the result we require?
for (int i=0; i < 20000; ++i) {
std::stringstream ss; ss << "listener" << i;
// Try and declare the exchange. Will succeed even if it already exists.
oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
qpid::client::arg::type="fanout",
qpid::client::arg::alternateExchange=std::string(),
qpid::client::arg::passive=false,
qpid::client::arg::durable=true);
oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
qpid::client::arg::exclusive=true,
qpid::client::arg::autoDelete=false);
oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
qpid::client::arg::queue=ss.str(),
qpid::client::arg::bindingKey=ss.str());
oSubscriptionManager.subscribe(*this, ss.str()); }
Regards,
Dave
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: SubscriptionManager performance problem.
Posted by Gordon Sim <gs...@redhat.com>.
On 02/25/2010 04:51 PM, David Stewart wrote:
> Hi all,
> we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
>
> The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
>
> When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
> I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly?
Is oSession an AsyncSession or a SyncSession (a plain Session is a
SyncSession)? Each call to SubscriptionManager::subscribe() will involve
a sync() which will certainly reduce the rate you can get through them,
but 1000 in ~3 minutes seems slow even then.
> Is there a better way for us to achieve the result we require?
>
> for (int i=0; i< 20000; ++i) {
> std::stringstream ss; ss<< "listener"<< i;
>
>
> // Try and declare the exchange. Will succeed even if it already exists.
> oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::type="fanout",
> qpid::client::arg::alternateExchange=std::string(),
> qpid::client::arg::passive=false,
> qpid::client::arg::durable=true);
>
> oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
> qpid::client::arg::exclusive=true,
> qpid::client::arg::autoDelete=false);
>
> oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
> qpid::client::arg::queue=ss.str(),
> qpid::client::arg::bindingKey=ss.str());
>
> oSubscriptionManager.subscribe(*this, ss.str());
> }
>
> Regards,
> Dave
>
> The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
RE: SubscriptionManager performance problem.
Posted by David Stewart <Da...@igindex.co.uk>.
I should have mentioned this is in the C++ API for qpid 0.5,
Sorry,
Dave
-----Original Message-----
From: David Stewart
Sent: 25 February 2010 16:51
To: dev@qpid.apache.org
Cc: users@qpid.apache.org
Subject: SubscriptionManager performance problem.
Hi all,
we are running a bridge between our old middleware and qpid system which at startup queries the existing middleware for the number of broadcast groups it knows about. It is a pricing system so there are ~20000.
The bridge creates a fanout exchange for each broadcast group, creates a queue and binds it to the exchange. All this takes ~75 seconds for 20000. Not a problem.
When we add a SubscriptionManager.subscribe() to the loop we get though 1000 requests in ~3 minutes.
I have created an example below which exhibits the problem. The question are we using the SubscriptionManager incorrectly? Is there a better way for us to achieve the result we require?
for (int i=0; i < 20000; ++i) {
std::stringstream ss; ss << "listener" << i;
// Try and declare the exchange. Will succeed even if it already exists.
oSession.exchangeDeclare(qpid::client::arg::exchange=ss.str(),
qpid::client::arg::type="fanout",
qpid::client::arg::alternateExchange=std::string(),
qpid::client::arg::passive=false,
qpid::client::arg::durable=true);
oSession.queueDeclare(qpid::client::arg::queue=ss.str(),
qpid::client::arg::exclusive=true,
qpid::client::arg::autoDelete=false);
oSession.exchangeBind(qpid::client::arg::exchange=ss.str(),
qpid::client::arg::queue=ss.str(),
qpid::client::arg::bindingKey=ss.str());
oSubscriptionManager.subscribe(*this, ss.str()); }
Regards,
Dave
The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone (+44 (0)20 7896 0011) and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Index Ltd is a company registered in England and Wales under number 01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the Financial Services Authority. FSA Register number 114059.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org