| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| The connections numbers |
« View previous topic :: View next topic » |
| Author |
Message
|
| SilentWind |
 Posted: Fri Jan 05, 2007 12:35 am Post subject: |
 |
|
Acolyte
Joined: 11 Jan 2006
Posts: 58
|
| mvic wrote: |
But from previous posts multiple Sessions appears not the best solution either. Was it really the multiple-session (multiple MQI connection) issue that was causing your problems? It would be a pity to solve a problem that didn't need solving here. |
Yes, you do understand my problem. I only resorted to the multiple MQI connection because it seemed to be the only solution for my implementation. If I could use the multiple session solution (and thus solve the connection problem), this problem won't be a problem in the first place.
Ok, I conducted a few tests.
If I use multiple sessions (multiple connections), the listeners were instantly registered (together with their Topic and TopicSubscribers). This instantly I did a java system time print and it was less than 1 second per subscriber. (approx 0.4 s, the results were very random, I did a basic averaging).
If I use single session (single connection), the first listener was instant. (< 1 sec). The other subscribers were very random. E.g. the 2-10th listener could take 5 sec on one client, but take 10 sec for another client. Subsequent listeners take longer and longer. After doing a simple tabulation, the time taken seem to be slightly linear (a curve at the higher ends with increasing time for more subscribers).
I hope my explanation above is clear.
| Quote: |
| Suggest you raise a call with IBM Support - sounds like a bug. Please post the details if/when you have them. |
The problem with this problem is that it requires a significant number of subscribers on several clients with a significant message load. I would require more time before I can post the actual results.
Also, I have tested the same settings on the multiple connections solution, but I have not received such an error before. Only with the single session solution, have I seen such an error happen. Hence I can expect to believe that the single session solution may have a different behaviour than its counterpart and thus may cause the previously mentioned error. |
|
| Back to top |
|
 |
| mvic |
| Posted: Fri Jan 05, 2007 2:06 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| SilentWind wrote: |
| If I use single session (single connection), the first listener was instant. (< 1 sec). The other subscribers were very random. E.g. the 2-10th listener could take 5 sec on one client, but take 10 sec for another client. Subsequent listeners take longer and longer. After doing a simple tabulation, the time taken seem to be slightly linear (a curve at the higher ends with increasing time for more subscribers). |
Although I am not much experienced in doing exactly what you're doing, these do sound like unexepected results. I suggest calling Support. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 05, 2007 4:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| mvic wrote: |
| SilentWind wrote: |
| If I use single session (single connection), the first listener was instant. (< 1 sec). The other subscribers were very random. E.g. the 2-10th listener could take 5 sec on one client, but take 10 sec for another client. Subsequent listeners take longer and longer. After doing a simple tabulation, the time taken seem to be slightly linear (a curve at the higher ends with increasing time for more subscribers). |
Although I am not much experienced in doing exactly what you're doing, these do sound like unexpected results. I suggest calling Support. |
The result is not that surprising.
Remember the documentation states that messages in the same session for multiple receivers are single threaded (synchronized) on the same queue. This may not amount to much of a delay (dependant on message size) if you have 2 or 3 subscribers in the same session. Having 100s of them on the SAME queue in the SAME session will kill your performance. I suggest you have the broker distribute the subscription to a unique queue per subscriber. You can then handle multiple subscribers per session as they all go to different queues.
Remember however that the transactional boundary is the session. This may not be practical if you have a lot of subscribers in the same session...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| SilentWind |
| Posted: Sun Jan 07, 2007 6:53 pm Post subject: |
|
|
Acolyte
Joined: 11 Jan 2006
Posts: 58
|
| fjb_saper wrote: |
Remember the documentation states that messages in the same session for multiple receivers are single threaded (synchronized) on the same queue. This may not amount to much of a delay (dependant on message size) if you have 2 or 3 subscribers in the same session. Having 100s of them on the SAME queue in the SAME session will kill your performance. I suggest you have the broker distribute the subscription to a unique queue per subscriber. You can then handle multiple subscribers per session as they all go to different queues.
Remember however that the transactional boundary is the session. This may not be practical if you have a lot of subscribers in the same session...
|
Makes sense. Now since I expect to have not more than 20 topics per client, I am going to limit my session to have 20 subscribers. Hopefully that should show better results and performance. Will be updating the results at a later date.  |
|
| 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
|
|
|
|
