qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rafael H. Schloming (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PROTON-568) messenger client slows and grows with large address space
Date Wed, 23 Apr 2014 19:50:14 GMT

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

Rafael H. Schloming commented on PROTON-568:
--------------------------------------------

Messenger will establish a new link for every new address that it sees, and it currently doesn't
ever attempt to close idle links, so I'm not surprised you are seeing this behaviour given
the scenario you describe. By the time you get to 13000 messages, messenger will be holding
13000 links open.

I'm not sure I would prioritize this super high since I don't think this is that common a
scenario, but I think there are two possible fixes. One option would be for Messenger to have
some kind of limit (possibly configurable) for how many links it will keep open before closing
idle ones. The other option would be to try to use the anonymous node so that all the messages
could be sent over a single link.

> messenger client slows and grows with large address space
> ---------------------------------------------------------
>
>                 Key: PROTON-568
>                 URL: https://issues.apache.org/jira/browse/PROTON-568
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>            Reporter: michael goulish
>
> A messenger-based sending client grows from little memory to over 3 GB, and slows down
by at least 10x, when transmitting 1 message each to many addresses.
> here is the setup:
> 1. a single messenger-based sender.
> 2. a single dispatch router
> 3. 5000 messenger-based receivers, each listening to 10 unique addresses.  i.e. 50,000
unique addresses total.
> 4. the sender sends a single to each unique address.
> 5. the first 10 messages go to addr1 ... addr10 -- all of which belong to the first receiver.
> 6. when each receiver gets all 10 of its messages, it shuts down.
> 7. each message is 1-to-1, and fire-and-forget.
> 8. This means that the sender only sends 1 message to each address and then moves on,
never to return.
> Result
> -----------------------------------
> The sending application started out doing something like 100-200 messages per second.
 Its memory footprint was small.  
> By the time I reach 13,000 messages sent, output has fallen to about 25 messages per
second, and memory (RSS) has risen to about 1.7 GB.
> It keeps getting larger and slower until the user rebels.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message