For 10,000 msgs per test, at 200k msgs per second, by Little's law, I would estimate the latency to be:
Waiting events = Throughput * Latency Latency = 10,000 / 200,000 = 1/20 = 50ms. On 08/11/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > > I thought I saw 'total time: 500ms' on a previous mail you sent about > this, but I guess I am mistaken. > > Trouble with max throughput tests, is that at saturation who can say what > the latency will be? > > On 08/11/2007, Robert Greig <[EMAIL PROTECTED]> wrote: > > > > On 08/11/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > 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. > > > > That is interesting since previously we were not hitting the CPU limit > > even with 16 clients running. > > > > > One thing I did notice about the 200k test, is that it only ran for > > > 0.5seconds. > > > > ? The test was configurable in terms of the number of messages sent. > > We ran with various sizes (including very large numbers) but it was > > pretty consistent so I think we often just ran with 10,000 message > > batches. > > > > > If latency is around 50ms (guessing), then it would be > > > advisable to > > > run the test for at least 5 seconds (100 times latency). > > > > I hope latency is far lower than 50ms for transient messaging. > > > > > The test you are refering to is Publisher/Listener under > > > org.apache.qpid.topic? > > > > Yes. > > > > RG > > > >
