[ 
https://issues.apache.org/jira/browse/QPID-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13820253#comment-13820253
 ] 

Flavio Baronti edited comment on QPID-5334 at 11/12/13 5:05 PM:
----------------------------------------------------------------

CPU usage with few sessions is higher on the broker, and lower on the client.
Increasing the number of session appears to increase the load on the client, 
and lower it on the broker. In both cases I'm quite far from 100% usage (more 
around 10%).


was (Author: flavio):
CPU usage with few sessions is higher on the broker, and lower on the client.
Increasing the number of session increases the load on the client, and lowers 
it on the broker. In both cases I'm quite far from 100% usage.

> Low throughput with thousands of queues
> ---------------------------------------
>
>                 Key: QPID-5334
>                 URL: https://issues.apache.org/jira/browse/QPID-5334
>             Project: Qpid
>          Issue Type: Improvement
>          Components: C++ Broker, Java Client
>    Affects Versions: 0.24
>         Environment: Broker: Linux 2.6.32 64bit
> Client: Windows 7, Java 1.7.0_21 64bit
>            Reporter: Flavio Baronti
>              Labels: performance
>         Attachments: JMSGenerator.java, JMSReceiver.java
>
>
> I have an use case where I need to create hundreds of thousands of queues,
> each one subscribed to a different topic (therefore I have as many topics
> as queues).
> I set up a test with a single producer generating data on a randomly
> chosen topic, and a receiver retrieving data from the queues (and throwing
> it away).
> I'm using the JMS api, and doing the obvious thing makes the throughput
> drop dramatically from 10k msg/sec with a single topic/queue (around the
> top my network adapter can sustain) to 20 msg/sec with 100k topics/queues.
> I found out that I can recover performance by using more JMS sessions and
> connections - e.g. create 4 connections with 100 sessions each, and
> randomly distributing the receiving queues on them.
> This however is less than ideal, since with the JMS client a thread is
> created for each session, I can manage the workload with 1 thread only when 
> it's over a single queue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to