Re:Re:Reply:Re:re:About the efficiency of the consumer creation.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Re:Re:Reply:Re:re:About the efficiency of the consumer creation.

DepestBlue
Here comes more performance test information:
Without transaction, I can perform the flow about 500 times per second.
With transaction, it's only 20 times per second.



At 2011-11-29 09:35:30,lzr <[hidden email]> wrote:

Thanks a lot for your timely response!
I'll try it again following up your advice.
I make further test with transaction and found it gets worse and worse:(
Following are my cases:
Client sends request 1 to queue S1, then wait response 1;
Server1 receives request 1 and sends request 2 to queue S2, then wait response 2;
Server2 receives request 2 and sends response 2 back;
Server1 receives response 2 and sends response 1 back;
Client receives response1 and records , the flow is done.



At 2011-11-28 17:19:46,SuoNayi <[hidden email]> wrote:

It takes more than one network trips(1.5  network trip in fact) when a consumer is created and closed.

Broker will keep the status of all consumers so your use case may cause broker overheat.
You may try the following:
1,ensuring only one connection is created and reused it always.
   Do not create connection every time when you need create session, producer or consumer etc.
2,Property named alwaysSessionAsync of ConnectionFactory is set to be false(default true).

At 2011-11-28 16:17:10,lzr <[hidden email]> wrote:

MessageConsumer creating and closing frequently!



At 2011-11-28 10:51:12,SuoNayi <[hidden email]> wrote:


Only creating consumers no close?
Note that with sparse match of selector, you may get into the trouble of dispatching message.



--

Wangyin
[hidden email]
 











Reply | Threaded
Open this post in threaded view
|

Reply:Re:Re:Reply:Re:re:About the efficiency of the consumer creation.

SuoNayi-2
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re:Reply:Re:Re:Reply:Re:re:About the efficiency of the consumer creation.

DepestBlue

Thanks a lot for your continuous replying!
In fact I was struggling to improve the performance:
Following up your suggestion, vmCursor is presented in queuePolicy without producerFlowControl and no OOM;
By my test, the performance down greatly than the test case without the transaction.
I attached my source files and configuration files.
Could you please to check it and given me some clause?

Thanks again,
Zhuran Li


At 2011-11-29 17:10:02,SuoNayi <[hidden email]> wrote: >In addition, you may try the following as well: >3,vmCursor will help to increase the performance of consumers but you'd better enable producerFlowControl if you do not want to get an OOM. >4,for queue enabling optimizedDispatch will be helpful too. >5,consumer with transaction should be faster than that without transaction. >But if you commit the transaction each time consuming a message it will be slower indeed. >  >At 2011-11-29 10:21:48,lzr <[hidden email]> wrote: > >Here comes more performance test information: >Without transaction, I can perform the flow about 500 times per second. >With transaction, it's only 20 times per second. > > > >At 2011-11-29 09:35:30,lzr <[hidden email]> wrote: > >Thanks a lot for your timely response! >I'll try it again following up your advice. >I make further test with transaction and found it gets worse and worse:( >Following are my cases: >Client sends request 1 to queue S1, then wait response 1; >Server1 receives request 1 and sends request 2 to queue S2, then wait response 2; >Server2 receives request 2 and sends response 2 back; >Server1 receives response 2 and sends response 1 back; >Client receives response1 and records , the flow is done. > > > >At 2011-11-28 17:19:46,SuoNayi <[hidden email]> wrote: > >It takes more than one network trips(1.5  network trip in fact) when a consumer is created and closed. > >Broker will keep the status of all consumers so your use case may cause broker overheat. >You may try the following: >1,ensuring only one connection is created and reused it always. >   Do not create connection every time when you need create session, producer or consumer etc. >2,Property named alwaysSessionAsync of ConnectionFactory is set to be false(default true). > >At 2011-11-28 16:17:10,lzr <[hidden email]> wrote: > >MessageConsumer creating and closing frequently! > > > >At 2011-11-28 10:51:12,SuoNayi <[hidden email]> wrote: > > >Only creating consumers no close? >Note that with sparse match of selector, you may get into the trouble of dispatching message. > > > >-- > >Wangyin >[hidden email]  >  > > > > > > > > > > > > > >



amq_test.jar (22K) Download Attachment
activemq.xml (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Reply:Reply:Re:Re:Reply:Re:re:About the efficiency of the consumer creation.

SuoNayi-2
In reply to this post by DepestBlue
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re:Reply:Reply:Re:Re:Reply:Re:re:About the efficiency of the consumer creation.

DepestBlue
>>>You'd better learn how to respect others at first before you ask for more help again.I really feel not very happy for this. How can you say like that?
Following your suggestions, I almost trying all the possible parameters what I can figure out.
Maybe the parameter and the codes doesn't in normal status because of my revision back and forth.
The reason I want more help is the project is urgent and I really have no more time to make deep research.


With and without transaction the performance is different greatly, for same business logic;
This is what I see from my testing.
OK, forget it! I'll try other open source MOM.


Thanks a lot any way,
Zhuran Li


At 2011-11-30 11:54:07,SuoNayi <[hidden email]> wrote:

>I glanced round your code which is not normative and found that you didnot follow what I had suggested.
>You'd better learn how to respect others at first before you ask for more help again.
>
>
>
>At 2011-11-29 17:07:37,SuoNayi <[hidden email]> wrote:
>
>In addition, you may try the following as well:
>3,vmCursor will help  to increase the performance of consumers but you'd better enable producerFlowControl if you do not want to get an OOM.
>4,for queue enabling optimizedDispatch will be helpful too.
>5,consumer with transaction should be faster than that wihtout transaction.
>But if you commit the transaction each time consuming a message it will be slower indeed.
>At 2011-11-29 10:21:48,lzr <[hidden email]> wrote:
>
>Here comes more performance test information:
>Without transaction, I can perform the flow about 500 times per second.
>With transaction, it's only 20 times per second.
>
>
>
>At 2011-11-29 09:35:30,lzr <[hidden email]> wrote:
>
>Thanks a lot for your timely response!
>I'll try it again following up your advice.
>I make further test with transaction and found it gets worse and worse:(
>Following are my cases:
>Client sends request 1 to queue S1, then wait response 1;
>Server1 receives request 1 and sends request 2 to queue S2, then wait response 2;
>Server2 receives request 2 and sends response 2 back;
>Server1 receives response 2 and sends response 1 back;
>Client receives response1 and records , the flow is done.
>
>
>
>At 2011-11-28 17:19:46,SuoNayi <[hidden email]> wrote:
>
>It takes more than one network trips(1.5  network trip in fact) when a consumer is created and closed.
>
>Broker will keep the status of all consumers so your use case may cause broker overheat.
>You may try the following:
>1,ensuring only one connection is created and reused it always.
>   Do not create connection every time when you need create session, producer or consumer etc.
>2,Property named alwaysSessionAsync of ConnectionFactory is set to be false(default true).
>
>At 2011-11-28 16:17:10,lzr <[hidden email]> wrote:
>
>MessageConsumer creating and closing frequently!
>
>
>
>At 2011-11-28 10:51:12,SuoNayi <[hidden email]> wrote:
>
>
>Only creating consumers no close?
>Note that with sparse match of selector, you may get into the trouble of dispatching message.
>
>
>
>--
>
>Wangyin
>[hidden email]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>