You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by oseymen <oz...@tdpg.com> on 2011/05/26 16:35:00 UTC
Enqueue performance with camel multicast
Hello,
I came across a case while conducting performance testing using ActiveMQ
v5.4.2 and Camel v2.6.
I have two queues (Q1 and Q2) and one camel route defined as:
Q1 to Q2
I have one console app (C#) sending messages to Q1. Delivery mode is
Persistent. I do not set the acknowledge mode (so default AutoAcknowledge is
used). I am not using transactions and there are no connection uri
parameters set (tcp://localhost:61616). This app increments performance
counters every time a message is sent. There are no consumers on those
queues (apart from Camel) - so messages build up in queues.
I start the broker, stop the camel route and start the publisher app. I see
~380-420 msg/s enqueue speed. When I start camel route, speed drops to
~200-250 msg/s. When I stop the camel route again, speed comes back up to
~400 msg/s.
BTW: Both AMQ and producer is running on one box.
My conclusion from this is that my producer appears to be waiting for camel
to move messages from Q1 to Q2 (and message to be safely persisted to Q2)
before it gets an ack back from the broker.
Do you think my conclusion is correct? If I add a couple of more queues for
Camel to multicast, would I see even decreased enqueue performance?
Any guidance is appreciated.
oseymen
--
View this message in context: http://activemq.2283324.n4.nabble.com/Enqueue-performance-with-camel-multicast-tp3552714p3552714.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
RE: Enqueue performance with camel multicast
Posted by Gary Tully <ga...@gmail.com>.
The producer would not wait unless the broker is configured for straight
through processing. By default dispatch is asynchronous.
This looks like a disk limit. With the route started there is twice as much
disk io b/c each message will be persisted twice. By default a producer
waits till the message is fsynced to disk.
As a quick validation, add persistence=false to your broker element
configuration.
On 27 May 2011 17:46, "Ozan Seymen" <Oz...@tdpg.com> wrote:
> Realized that Camel config is not appearing in email readers, so here is
the route:
>
> <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
> <route>
> <description>Q1 to Q2</description>
> <from uri="activemq:queue:Q1"/>
> <multicast>
> <to uri="activemq:queue:Q2"/>
> </multicast>
> </route>
> </camelContext>
>
> oseymen
>
> -----Original Message-----
> From: oseymen [mailto:ozan.seymen@tdpg.com]
> Sent: 26 May 2011 15:35
> To: users@activemq.apache.org
> Subject: Enqueue performance with camel multicast
>
> Hello,
>
> I came across a case while conducting performance testing using ActiveMQ
> v5.4.2 and Camel v2.6.
>
> I have two queues (Q1 and Q2) and one camel route defined as:
>
>
>
> Q1 to Q2
>
>
>
>
>
>
>
> I have one console app (C#) sending messages to Q1. Delivery mode is
Persistent. I do not set the acknowledge mode (so default AutoAcknowledge is
used). I am not using transactions and there are no connection uri
parameters set (tcp://localhost:61616). This app increments performance
counters every time a message is sent. There are no consumers on those
queues (apart from Camel) - so messages build up in queues.
>
> I start the broker, stop the camel route and start the publisher app. I
see
> ~380-420 msg/s enqueue speed. When I start camel route, speed drops to
> ~200-250 msg/s. When I stop the camel route again, speed comes back up to
> ~400 msg/s.
>
> BTW: Both AMQ and producer is running on one box.
>
> My conclusion from this is that my producer appears to be waiting for
camel to move messages from Q1 to Q2 (and message to be safely persisted to
Q2) before it gets an ack back from the broker.
>
> Do you think my conclusion is correct? If I add a couple of more queues
for Camel to multicast, would I see even decreased enqueue performance?
>
> Any guidance is appreciated.
>
> oseymen
>
>
>
> --
> View this message in context:
http://activemq.2283324.n4.nabble.com/Enqueue-performance-with-camel-multicast-tp3552714p3552714.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email______________________________________________________________________
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email______________________________________________________________________
>
> This e-mail and any attached files are intended for the named addressee
only. It contains information which may be confidential and legally
privileged and also protected by copyright. Unless you are the named
addressee (or authorised to receive for the addressee) you may not copy or
use it or disclose it to anyone else. If you received it in error please
notify the sender immediately and then delete it from your system.
>
> Please be advised that the views and opinions expressed in this e-mail may
not reflect the views and opinions of The Digital Property Group Limited or
any of its subsidiary companies.
>
> We make every effort to keep our network free from viruses. However, you
do need to check this e-mail and any attachments to it for viruses as we can
take no responsibility for any computer virus which may be transferred by
way of this e-mail. We reserve the right to monitor all e-mail
communications.
>
> The Digital Property Group Limited is a Daily Mail and General Trust plc
company.
> Registered Office: Northcliffe House, 2 Derry Street, London, W8 5TT.
> Registered in England & Wales No: 02290527 VAT no. 243571174
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
RE: Enqueue performance with camel multicast
Posted by Ozan Seymen <Oz...@tdpg.com>.
Realized that Camel config is not appearing in email readers, so here is the route:
<camelContext id="camel" xmlns="http://camel.apache.org/schema/spring">
<route>
<description>Q1 to Q2</description>
<from uri="activemq:queue:Q1"/>
<multicast>
<to uri="activemq:queue:Q2"/>
</multicast>
</route>
</camelContext>
oseymen
-----Original Message-----
From: oseymen [mailto:ozan.seymen@tdpg.com]
Sent: 26 May 2011 15:35
To: users@activemq.apache.org
Subject: Enqueue performance with camel multicast
Hello,
I came across a case while conducting performance testing using ActiveMQ
v5.4.2 and Camel v2.6.
I have two queues (Q1 and Q2) and one camel route defined as:
Q1 to Q2
I have one console app (C#) sending messages to Q1. Delivery mode is Persistent. I do not set the acknowledge mode (so default AutoAcknowledge is used). I am not using transactions and there are no connection uri parameters set (tcp://localhost:61616). This app increments performance counters every time a message is sent. There are no consumers on those queues (apart from Camel) - so messages build up in queues.
I start the broker, stop the camel route and start the publisher app. I see
~380-420 msg/s enqueue speed. When I start camel route, speed drops to
~200-250 msg/s. When I stop the camel route again, speed comes back up to
~400 msg/s.
BTW: Both AMQ and producer is running on one box.
My conclusion from this is that my producer appears to be waiting for camel to move messages from Q1 to Q2 (and message to be safely persisted to Q2) before it gets an ack back from the broker.
Do you think my conclusion is correct? If I add a couple of more queues for Camel to multicast, would I see even decreased enqueue performance?
Any guidance is appreciated.
oseymen
--
View this message in context: http://activemq.2283324.n4.nabble.com/Enqueue-performance-with-camel-multicast-tp3552714p3552714.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
This e-mail and any attached files are intended for the named addressee only. It contains information which may be confidential and legally privileged and also protected by copyright. Unless you are the named addressee (or authorised to receive for the addressee) you may not copy or use it or disclose it to anyone else. If you received it in error please notify the sender immediately and then delete it from your system.
Please be advised that the views and opinions expressed in this e-mail may not reflect the views and opinions of The Digital Property Group Limited or any of its subsidiary companies.
We make every effort to keep our network free from viruses. However, you do need to check this e-mail and any attachments to it for viruses as we can take no responsibility for any computer virus which may be transferred by way of this e-mail. We reserve the right to monitor all e-mail communications.
The Digital Property Group Limited is a Daily Mail and General Trust plc company.
Registered Office: Northcliffe House, 2 Derry Street, London, W8 5TT.
Registered in England & Wales No: 02290527 VAT no. 243571174
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________