You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Flavio Baronti (JIRA)" <ji...@apache.org> on 2013/11/12 18:05:17 UTC

[jira] [Commented] (QPID-5334) Low throughput with thousands of queues

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

Flavio Baronti commented on QPID-5334:
--------------------------------------

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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org