Have you ever test the performance of the "consumer.receive"?
At 2011-10-20 17:23:30,SuoNayi <suonayi2...@163.com> wrote: >I have tested the performance of the consumer before some days, it 's not >possible consumer is slower than producer so much. >you can try to set messagelistener for consumer instead of using the >synchronous method consumer.receive(). > >At 2011-10-20 16:49:18,lzr <jsw...@163.com> wrote: >>Yes, I run the both consumer and producer in Eclipse. When the sent done, >>start consumer to receive the messages from queue. >> >> >> >> >> >>At 2011-10-20 16:20:09,lzr <jsw...@163.com> wrote: >>>Yes, its are persistent messages. >>>As these messages in a huge transaction, without compression property set >>>the broker will run out of memory. >>> >>> >>> >>> >>> >>>At 2011-10-20 15:42:28,"Torsten Mielke" <tors...@fusesource.com> wrote: >>>>Are these persistent messages? >>>> >>>>From my own performance tests I know that enqueuing a persistent message >>>>takes longer than dequeuing it, which is the opposite behavior from what >>>>you're seeing. Persistent msgs need to be persisted to the brokers store. >>>> >>>>Do you encounter the same behavior when turning off compression? >>>>Are producer/broker/consumer on the same machine? >>>>Also, I presume there are no transactions used? >>>> >>>> >>>> >>>>Torsten Mielke >>>>tors...@fusesource.com >>>>tmie...@blogspot.com >>>> >>>>On Oct 20, 2011, at 9:32 AM, lzr wrote: >>>> >>>>> Hi all, >>>>> >>>>> >>>>> In my cases, I produces and consumes messages with big data: 40K per >>>>> message, 10000 messages produced and consumed for each exchange. For >>>>> better performance I used jms.useCompression in my connection and it did >>>>> work well: >>>>> 10000 messages sent in 5 seconds; >>>>> But my consumer takes about 70 seconds to receive these messages from >>>>> queue (Just received, no process to message). >>>>> How is the consumer so lower than producer? Is there any optimization to >>>>> the consumer? >>>>> >>>>> >>>>> It's much appreciated if any suggestions! >>>>> >>>>> >>>>> Best regards, >>>>> Zhuran Li >>>> >>>> >>>> >>>> >>>>
