Hello Ulf, I am sending messages with a byte array of 100 bytes and I am using Berkley DB as a message store (which should be slower than having memory only message store, no?)
With 1 consumer, 1 producer and no broker, I am at 33k msgs/sec if they are all on the same machine and I have set "jms.forceAsyncSend=true" on the producer and "jms.sendAcksAsync=true" for the consumer. Are you using other options to get 190k? Do you think JMS might be a bottleneck? Or something else in my config/test? JMS client 0.9.0 Qpid Java Broker 6.0.1 Dispatcher 0.6.0 Adel > Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid > Java Broker 6.0.0 > To: [email protected] > From: [email protected] > Date: Wed, 3 Aug 2016 16:23:06 +0200 > > Hi, > > Excuse me if this was already mentioned somewhere, but what is the size > of the messages you are sending ? > > FWIW, I'm able to get around 30-40k msgs/sec sustained with 1 producer, > 1 consumer, 1 dispatch (4 worker threads) and 1 broker (activemq-5). The > sender sends unsettled messages as fast as it can using qpid-proton > reactor API which is sending async up to the window limit. > > With no broker involved, I'm getting ~190k msgs/sec. > > All of these numbers are from my 8 core laptop. Message size is 128 bytes. > > I don't know the dispatcher that well, but I think it should be able to > handle data from each connector just fine given the numbers I have seen. > > On 08/03/2016 02:41 PM, Adel Boutros wrote: > > > > > > > > Hello again, > > > > > > > As requested, I added a 2nd connector and the appropriate autoLinks on the > > same host/port but with a different name. It seems to have resolved the > > issue. > > > > 1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 1 connectors --> 5000 > > msg/s. > > 1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 2 connectors --> 6600 > > msg/s. > > 1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 2 connectors --> 7700 > > msg/s. > > > > I think this confirms the problem is due to the fact a single connection is > > being shared by all clients (consumers/producers) and that having a sort of > > pool of connections or a connection per workerThread is a solution to > > consider. > > > > What do you think? > > > > I added a 3rd connector to see if it changes anything but it > > didn't. Do you think this is maybe because the dispatcher is not able > > to process fast enough and saturate the 2 connectors? > > 1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 3 connectors --> 7700 > > msg/s. > > > > > > > Adel > > > >> From: [email protected] > >> To: [email protected] > >> Subject: RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with > >> Qpid Java Broker 6.0.0 > >> Date: Tue, 2 Aug 2016 22:21:54 +0200 > >> > >> Sorry for the typo. Indeed, it was with 3 producers. I used 4 and 8 > >> workerThread but there wasn't a difference. > >> We want to benchmark in the worst case scenarios actually to see what is > >> the minimum we can guarantee. This is why we are using synchronous > >> sending. In the future, we will also benchmark with full SSL/SASL to see > >> what impact it has on the performance. > >>> Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with > >>> Qpid Java Broker 6.0.0 > >>> To: [email protected] > >>> From: [email protected] > >>> Date: Tue, 2 Aug 2016 20:41:54 +0100 > >>> > >>> On 02/08/16 20:25, Adel Boutros wrote: > >>>> How about the tests we did with consumer/producers connected directly to > >>>> the dispatcher without any broker where we had 16 000 msg/s with 4 > >>>> producers. Is it also a very low value given that there is no > >>>> persistence or storing here? It was also synchronous sending. > >>> > >>> The rate is low because it is synchronous. One messages is sent to the > >>> consumer who acknowledges it, the acknowledgement is then conveyed back > >>> to the sender who then can send the next message. > >>> > >>> The rate for a single producer through the router was 6,000 per second. > >>> That works out as a roundtrip time of 167 microsecs or so. In your > >>> table, the 16,000 rate was listed as being for 3 producers. Based on the > >>> rate of a single producer, the best you could hope for there is 3 * > >>> 6,000 i.e 18,000. (How many worker threads did you have on the router > >>> for that case?) > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > > > > > > > > -- > Ulf > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
