| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Problem: QueueSender sends message in 500ms |
« View previous topic :: View next topic » |
| Author |
Message
|
| vermakov |
 Posted: Thu Sep 24, 2009 6:45 am Post subject: Re: Problem: QueueSender sends message in 500ms |
 |
|
Novice
Joined: 22 Sep 2009
Posts: 11
Location: Canada
|
| manicminer wrote: |
| You shouldn't use currentTimeMillis for performance timing (it is inaccurate and doesn't update regularly) but besides that... |
I'm not doing performance timing. I'm looking for the spot where we are loosing time. For the rough estimation, the currentTimeMillis() is good enough to find a several hundreds of milliseconds delay...
| manicminer wrote: |
| Are you 100% sure of the message persistence selected for each message? Could it be that the server is sending a non-persistent message where as the client is sending a persistent one? That coupled with a lack of disk IO bandwidth might explain the difference between the 2. |
Client and server sending non-persistent short object messages. I'm 100% sure of that.
I am continue looking into possible infrastructure issue including hardware of the participating boxes. The thing is that client is consistently slow on different machines running different versions of Windows. MQ server is a powerful box with lots of available resources, CPUs, memory, HD space, 1GB NIC card, and so on... |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Sep 24, 2009 7:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| vermakov wrote: |
| mqjeff wrote: |
| Did you ensure that your receiver was using the native form of the selector to match the reply? |
We are not using selectors. All reply messages are consumed by the client and dispatched internally to the right thread. Also, there is no delay on server reply, delay is on client send. |
You are not in any way doing anything to pick the specific reply to your specific request?
You are reading from the replyto queue in a first in first out manner? |
|
| Back to top |
|
|
| vermakov |
| Posted: Thu Sep 24, 2009 7:19 am Post subject: |
|
|
Novice
Joined: 22 Sep 2009
Posts: 11
Location: Canada
|
| fjb_saper wrote: |
| Have you looked at the client application and the network being the culprit? |
Yes, I'm looking into it. Client is consistently slower than server on different machines with different Windows and hardware. It tells me that there's something in our code or Main Queue setup (not in the network) that makes client slower.
| fjb_saper wrote: |
| Are you opening a client connection for each send or are you using pooled connections? |
Client and server use one connection and one session. The number of senders and receivers is configurable.
| fjb_saper wrote: |
| What is the speed supported by your network for the message size you are sending? |
I don't know. I assume it is good enough allowing server to work efficiently.
| fjb_saper wrote: |
| Remember that a process using bindings will work way faster than a client process over tcp/ip client connection! |
Could be... But I'm bound to existing application framework and MQ setup. I have to prove that existing implementation is not efficient. So far, I see that server is fine. Something is wrong with the client application or queue setup... |
|
| Back to top |
|
|
| vermakov |
| Posted: Thu Sep 24, 2009 7:24 am Post subject: |
|
|
Novice
Joined: 22 Sep 2009
Posts: 11
Location: Canada
|
| mqjeff wrote: |
You are not in any way doing anything to pick the specific reply to your specific request?
You are reading from the replyto queue in a first in first out manner? |
Yes. I'm reading reply queue as FIFO. Then client application finds the waiting thread by CorrelationId, wakes it up and gives it the reply object.
Server does similar work. It reads Main Queue by priority only. Every message is dispatched to a certain processor using data in the message... |
|
| Back to top |
|
|
| vermakov |
| Posted: Sun Sep 27, 2009 5:28 am Post subject: Issue closed |
|
|
Novice
Joined: 22 Sep 2009
Posts: 11
Location: Canada
|
I found the problem. Our developer created listeners and receivers on one session on one connection. This would be fine but he has decided to create listener as asynchronous so
- it listens the Q for 1 sec as QueueReceiver.receive(1000) ,
- releases and checks its status
- goes listening again if status was "continue"
MQ assigned-contact admin significant amount of resources for each start-stop of the receiver. That was affecting ability of QueueSender to send messages.
The better solution in our case is to create MessageConsumer. The other solution would be to have synchronous listener on separate session.
Thanks everyone for your input. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
