| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Help With C# 4 Parallel Prog. and MQ Async Connection Archit |
« View previous topic :: View next topic » |
| Author |
Message
|
| shashikanth_in |
 Posted: Wed Sep 08, 2010 8:59 pm Post subject: |
 |
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
5 million messages in 15hrs is about less than 100 messages/second. Is there some kind of pattern of message sends? do you expect the message send to be spread evenly across 15hour time?
Do you want the messages to be Persistent? If not you can go for Asynchronous Send for non-persistent messages which will provide better throughput. |
|
| Back to top |
|
 |
| codemonkey |
| Posted: Mon Sep 13, 2010 10:17 am Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
| shashikanth_in wrote: |
5 million messages in 15hrs is about less than 100 messages/second. Is there some kind of pattern of message sends? do you expect the message send to be spread evenly across 15hour time?
Do you want the messages to be Persistent? If not you can go for Asynchronous Send for non-persistent messages which will provide better throughput. |
No it's not even, it's non linear. There are peak times and off peak times. The async method is what I'm trying to do. I'm not sure if it's actually async or not. From the client perspective, it's not truly async because, it's server code that will be executing a request to a WCF service. The WCF service is what ultimately must process the message to the queue. There's some things we're doing at the WCF level which will help throughput, like caching.
Would you happen to have some code samples of the async method of publishing and subscribing?
I've created a wrapper around the IBM.XMS assembly to abstract out the connection calls using a factory method pattern. The connection is established inside the wrapper. This means that the connection is opened, work is done and then the connection is immediately closed. Currently we're spawning a new thread for each of these connections. We noticed that MQ returns an error when we exceed the maximum number of connections, which occurs frequently. We'll probably wind up increasing the max number of connections or we'll have to try a different approach, which would be to establish and maintain an open connection on several pre-defined threads and issue publish requests across those threads.
Do you have any thoughts on either of these architectures? |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Sep 13, 2010 5:39 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| we'll have to try a different approach, which would be to establish and maintain an open connection on several pre-defined threads and issue publish requests across those threads. |
This is actually best practise for designing high volume MQ interfaces.
Establishing a connection, doing one transaction and then disconnecting is very inefficient and will not meet your high performance goals. I have seen applications increase their volume and then fall to their knees with unaccepable throughput using this poor design paradigm. Establishing a connection is the single most expensive MQ operation, next to Opening an MQ object.
_________________
Glenn |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 13, 2010 5:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gbaddeley wrote: |
| Establishing a connection, doing one transaction and then disconnecting is very inefficient and will not meet your high performance goals. I have seen applications increase their volume and then fall to their knees with unaccepable throughput using this poor design paradigm. Establishing a connection is the single most expensive MQ operation, next to Opening an MQ object. |
It's for this reason WAS (and similar) offer connection pooling facilities to the contained application.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Tue Sep 14, 2010 12:47 am Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
You can find the sample code for asnynchronous publishing in SimpleAsyncProducer.cs. You can locate this file under tools\dotnet\samples\cs\simple\wmq\SimpleAsyncProducer of your MQ install folder.
But as you say since yours is a web service request, Async publisher may not help. |
|
| 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
|
|
|
|
