qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Weekly plans.
Date Thu, 08 Nov 2007 10:48:30 GMT
I don't think there has been a degradation, its just that the test is
different. As I said, the client machine maxed out before the broker or
network did, so the 100k I observed was not the brokers best effort. In fact
I will try and run the test that gave you 200k+ and see if I can improve my
test case to do this too.

One thing I did notice about the 200k test, is that it only ran for
0.5seconds. If latency is around 50ms (guessing), then it would be
advisable to
run the test for at least 5 seconds (100 times latency). The results I
obtained all ran at constant rates for ten minutes, and it has been a bit
tricky to do this. Reason being that max throughput tests have to run the
broker at saturation load for some time, and it becomes all to easy to end
up overflowing the queues, consequently there is logic in the test code to
hold back when too many messages at once are in flight.

The test you are refering to is Publisher/Listener under

On 08/11/2007, Robert Greig <robert.j.greig@gmail.com> wrote:
> On 07/11/2007, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> > The fastest I've seen the Java M2 go on pubsub 2:16 is around 100k
> msgs/sec
> > w. 256 byte messages. Although, I feel it could go faster because I was
> > testing with just one client machine, and the CPU maxed out on the
> client
> > and not the broker well before the connection was saturated :(
> This seems like there has been a significant degradation over time. On
> the old topic test (which is checked in on the M2 branch now) we used
> to see over 200k messages per second.
> Does you test use a single JVM for all the clients? I would be
> interested to know if there is any difference between a single JVM
> with multiple connections and multiple JVMs each with a single
> connection.
> Carl, does your test use separate processes or a single process with
> connections?
> > Best I have seen so far was SwiftMQ which managed to write
> > batch 8k msgs/sec in auto ack mode, 16:16 p2p, on a disk setup that can
> > handle maybe 500 IOPS (very rough estimate), which is impressive.
> What does this test do exactly - what does the "batch 8k msgs/sec"
> mean? How does it compare with the same test on Qpid?
> RG

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message