| Author |
Message
|
| vincent |
 Posted: Wed May 10, 2006 7:22 am Post subject: Channels stanza |
 |
|
Voyager
Joined: 21 Apr 2006
Posts: 81
|
Do we need to specify Channel Stanza if there is a communication between clients and server and clients are more than 40 connected concurrently?
-vince |
|
| Back to top |
|
 |
| vennela |
| Posted: Wed May 10, 2006 7:23 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| What is the max number of channels you may need? |
|
| Back to top |
|
|
| sandiksk |
| Posted: Wed May 10, 2006 7:24 am Post subject: |
|
|
Centurion
Joined: 08 Jun 2005
Posts: 133
|
| Do you mean Max channels. The default is 100 so that should be good unless you have lot of sender channels |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Wed May 10, 2006 7:24 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
I'm gonna try to predict Jeff's response to this one, and beat him to it.
Use the search button.
Read the manuals.
Last edited by Toronto_MQ on Wed May 10, 2006 7:24 am; edited 1 time in total |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed May 10, 2006 7:25 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 10, 2006 7:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The channels stanza does have more functionality than just the MaxActiveChannels.
And, unfortunately, just becuase there are 40 client applications, that doesn't mean that each client application is using only one client connection. You'd hope this was so, but....
Also, just because there are 40 client applications doing business work, there may also be 10000 other channels that need to be active to feed those client applications the work they need to perform and the results.
And then there might be several channels that need to be active for monitoring and management.
So there's not a one-one between client applications and MaxActiveChannels.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| vennela |
| Posted: Wed May 10, 2006 7:31 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Toronto_MQ wrote: |
I'm gonna try to predict Jeff's response to this one, and beat him to it.
Use the search button.
Read the manuals. |
If this is a compliment to Jeff then that's good.
Searching the forum would help him lot more than a simple answer anyway. |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Wed May 10, 2006 7:53 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
This is definitely a compliment. I'm glad Jeff makes people think about what they're asking instead of offering immediate answers to questions.
People should be able to dome *some* of the work themselves.
Steve |
|
| Back to top |
|
|
| vincent |
| Posted: Wed May 10, 2006 8:01 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006
Posts: 81
|
My problem is :
1. 40000 messages are added (via PUT) in 58 seconds to Q. Used 20 process to pump up.
2. The same 40000 messagre are retrieved (via GET) in 5 minutes(300sec) from Q.
Though 20 processes used to pull out, the time taken to process a message by one process and 20 process are not different.
I do not have any idea what is going on here......
What is the problem here? I think Get rate is more than Put rate.
3. When i put and get at the same time these 40000 by 40 process, the time taken is nearly 8 min(480sec). It is very high.
Let me know if these performance have any connection with channels?
-vinc |
|
| Back to top |
|
|
| sandiksk |
| Posted: Wed May 10, 2006 8:54 am Post subject: |
|
|
Centurion
Joined: 08 Jun 2005
Posts: 133
|
| If it were the channels issue, you should see some issues and errors in the error logs indicating that max channels limit is reached. I think you look more into the application thats processing the messages. |
|
| Back to top |
|
|
| vincent |
| Posted: Wed May 10, 2006 10:22 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006
Posts: 81
|
sandi & vennela,
I am not talking about the message communication between two QMs. A single Q Manger and single Q is served for both put and Get
Put is coming from Solaris box and Get is coming from Windows but QM is sitting on Solaris box
Hope i clearified
-vince |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 10, 2006 10:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
vincent - Is this a request/reply pattern? That is, is the Windows App sending a message to the Solaris app, and then getting a response back?
Or is the Solaris app just generating all these messages from some other source, and it is a one way communication with the Windows app?
Also, if the Solaris app is not committing the messages frequently, then the windows app will not be able to get messages until they are committed - regardless of how many messages the solaris app has put.
You need to understand these application level details in order to understand why adding more windows app instances is not increasing your processing speed.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| vincent |
| Posted: Wed May 10, 2006 11:03 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006
Posts: 81
|
Is this a request/reply pattern? That is, is the Windows App sending a message to the Solaris app, and then getting a response back?
Ans: No. It is a unidirectional. There is no response expected. Solaris app is putting messages on Q and it should be picked by Windwos client.
Or is the Solaris app just generating all these messages from some other source, and it is a one way communication with the Windows app?
Ans: Since i have a throughput problem with the application, I have written a smaill c++ sample program to put it from solaris and get it from windows.
Also, if the Solaris app is not committing the messages frequently, then the windows app will not be able to get messages until they are committed - regardless of how many messages the solaris app has put
Ans: The program is committing as soon as it puts into the Q and before putting the next message. Is there any mechanism available in Q or Q Manager level to commit explicitly?
You need to understand these application level details in order to understand why adding more windows app instances is not increasing your processing speed.
Ans: I have tried with Solaris-Get also, it is also performing in the same level.
Jeff, Tell me one thing. Have u achieved any time very high throughput from your experience? if so, what was the level and its architecture |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 10, 2006 11:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I have written applications that, under the requirements I had at the time, were "high-volume". That definition may not be the same as yours, though.
Let's talk a minute about all of the things that happen when a message is put on a remote queue until it is available for GETTING.
1) The putting application opens the remote queue, this is resolved under the covers to the XMITQ.
2) The message is PUT, onto the XMITQ.
3) The sending MCA (message channel agent) processes each message on the XMITQ, one at a time. Each message is read in syncpoint and transmitted over the network socket.
4) The receiving MCA reads the message from the network socket, and puts it under syncpoint to the destination queue.
5) The sender and receiver MCAs perform transactional handshaking to ensure that the message is received.
6) When the channel batch size is reached or the last message on the XMITQ is processed, then the syncpoints on both sides are committed.
7) when the MCA commits it, the message is available for GET on the destination queue.
I am a little bit unclear about the receiver syncpoint, whether it commits the message individually or not. I'm sure that the Intercommunications manual spells this out.
So you can impact the performance of the message channel itself by adjusting the batchsize.
What you should really do, though, is use RESET QUEUE STATISTICS to monitor the enqueue rate and dequeue rate of the destination queue at a fairly small interval (ten seconds or so). If they are the same, then messages are being read as fast as they are being put - and your performance is bound by factors like CPU speed or disk access or channel batch size. If messages are being put faster than they are gotten, then your performance is bound by the application GETTING messages. If messages are being put slower than they are being gotten, then your bound by channel speeds, and again batch size can be an issue OR it could be issues on the Solaris side with the sending MCA.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| vincent |
| Posted: Wed May 10, 2006 11:53 am Post subject: |
|
|
Voyager
Joined: 21 Apr 2006
Posts: 81
|
Jeff, I do not have XMIT Q at all. I think i might be confused you.
My scenario is that Solaris client is putting into Q and Windows client is getting from the same Q. There is no MCA in the picture at all. So there is a single unix process(Q) and put and get is happening at the same time
-vincent |
|
| Back to top |
|
|
|
|
