It's been a while, but I did a test with just the proton C++ and QpidJMS
clients and can get closer to Virgilio's numbers.
I think the trouble I was running into was only in the Python Proton
library. For whatever reason, it is far slower than the others.
--
Sent from: http://qpid.2158936.n2.n
we've managed to do ~78 msg /s on qpid-1.36 on 3 qpid broker instances
on a intel X5670, 64GB ram, 4x 1gb lan, 16 clients flooding, 16 clients
receiving (~48000msg /s on each direction).
on a test running on 2011.
I'm pretty sure C++ broker is able to do a bit more than your numbers in
AMQP-0-
Thanks Chuck!
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
check it out.
-Chuck
- Original Message -
> From: "tomt"
> To: users@qpid.apache.org
> Sent: Friday, July 10, 2020 3:49:19 PM
> Subject: Re: default limits of qpid-c++ broker, dispatch router, or proton?
>
> You're right about the Python client. We
You're right about the Python client. We have a websocket client utility
that connects to the apache webserver and then locally we have a port that
opens that we connect the python client to that.
I'll try the different combinations. Thanks
--
Sent from: http://qpid.2158936.n2.nabble.com/Apac
On 10/07/2020 7:51 pm, tomt wrote:
MY configuration is that I have my receivers connecting to the router
(through an Apache web server) via websockets. The topics they subscribe to
live in the broker.
I have link routing configured for this, so I am getting real flow control
(based on what I re
MY configuration is that I have my receivers connecting to the router
(through an Apache web server) via websockets. The topics they subscribe to
live in the broker.
I have link routing configured for this, so I am getting real flow control
(based on what I read in the link above)
--
Sent fr
On 10/07/2020 4:58 pm, Robbie Gemmell wrote:
When you have the router in between the broker and producer/consumer
clients, then what happens will depend on how things have been set up
to operate
I had assumed you were testing with the broker *or* the router, but
re-reading after this I see I a
On Fri, 10 Jul 2020 at 16:54, Gordon Sim wrote:
>
> On 10/07/2020 4:03 pm, tomt wrote:
> > Thanks for the fast response. I spent a good part of the afternoon looking
> > into the whole flow control system to understand better given what you had
> > asked.
> >
> > I am using the Python client as m
The behaviour is going to be dependent on how your components are
actually configured, so it's hard to say specifics without more detail
on how e.g your router and broker are actually configured to work
together with the clients.
Senders have no ability to control credit, it is granted by the
rece
On 10/07/2020 4:03 pm, tomt wrote:
Thanks for the fast response. I spent a good part of the afternoon looking
into the whole flow control system to understand better given what you had
asked.
I am using the Python client as my receivers and the C++ API as my senders
who each synchronously send
Thanks for the fast response. I spent a good part of the afternoon looking
into the whole flow control system to understand better given what you had
asked.
I am using the Python client as my receivers and the C++ API as my senders
who each synchronously send on their own threads as fast as possi
On 09/07/2020 3:43 pm, tomt wrote:
Hello,
I have been trying to determine the highest rate of messages that can be
sent at any given time through my environment that includes the qpid-cpp
broker and the dispatch router all using AMQP 1.0 (via Proton).
There seems to be some maximum cap that onl
Hello,
I have been trying to determine the highest rate of messages that can be
sent at any given time through my environment that includes the qpid-cpp
broker and the dispatch router all using AMQP 1.0 (via Proton).
There seems to be some maximum cap that only lets me send up to 2500
messages/se
14 matches
Mail list logo