| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Wanted Beta Testers |
« View previous topic :: View next topic » |
| Author |
Message
|
| RogerLacroix |
 Posted: Mon Mar 21, 2005 9:42 am Post subject: |
 |
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
All,
Last week a couple of people on the MQ ListServer expressed concerns over a situation when a queue manager has high levels (thousands) of connections and when the security exit has 'max channel connection' feature enabled, the issuing of a PCF command per connection would cause excessive overhead.
One of the suggestion was to use shared memory and walk through it to find / store the channel count and another was to do something similar to SupportPac ME71 and store the information in a queue.
After thinking about it for a while, I concluded that under a load of thousands of connections, the architect / design of SupportPac ME71, would cause excessive overhead too (getting & putting to its status queue).
Now the idea of using shared memory is good, but has 2 problems:
(1) Walking through 100 over more channels in shared memory is still overhead (i.e. string compares)
(2) How do you know the counter in shared memory is accurate? What if the MQ Admin adds the exit definition to a running channel or what if they remove the definition from a channel then add it back in an hour or the next day. The values in shared memory would be totally out of sync.
So, here's the design that I came up with and I believe that it addresses all of these issues, along with any concerns about speed / overhead.
Each active channel will allocate its own very small piece of shared memory (no common shared memory). Therefore, there is no walking (string compares) through shared memory looking for the matching channel name.
To keep the shared memory in sync with what is really happening with active channel, I have introduced 2 new iniFile keywords to control the refreshing of the shared memory by issuing a PCF command after 'x' seconds or 'n' connections attempts. I have set the default values for 60 seconds and 100 connection attempts. But for queue managers with thousands of active channels, the user can increase these values to keep the overhead to a minimum. I.e. 600 seconds and 1000 connection attempts
I have created and deployed the security exits with the new 'max channel connection' design. It is now extremely fast even when 'max channel connection' feature is enabled
For more information about the beta program for the 2 security exits, go to:
http://www.capitalware.biz/beta.html
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Mar 21, 2005 10:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Quote: |
Each active channel will allocate its own very small piece of shared memory (no common shared memory).
|
How much Roger? If I have 3,000 client channels running, how much more memory does the server need?
| Quote: |
But for queue managers with thousands of active channels, the user can increase these values to keep the overhead to a minimum. I.e. 600 seconds and 1000 connection attempts.
|
How does this exactly work? If I had set the max allowed channels to 10, and the refresh values are set to 600 and 1000, what PCF Inquiries will be done for:
9 Channels running in the above scenario?
10 Channels running with #11 trying to get in?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Mar 21, 2005 10:52 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
The shared memory is allocated based on the channel definition and not how many active channels you have.
(A) If those 3000 active channels all belong to 1 channel defintion (i.e. 'ABC.CH01') then only 1 shared memory segement is allocated (100 bytes).
(B) If those 3000 active channels belong to 100 different channel defintion (i.e. 'ABC.CH01', 'DEF.CH01', 'XYZ.CH01', etc..) then 100 shared memory segement are allocated (100 * 100 bytes).
Example:
UseMCC=Y
ABC.CH01=10
PETER.CH01=50
MCCRedoSeconds=600
MCCRedoCount=1000
The PCF inquire channel status command will only be issued after 600 seconds or 1000 connection attempts (which ever comes first) per channel. It does not get all channel statuses just the status for its own channel.
Therefore, the security exit will allow up to a maximum of 10 connections on channel 'ABC.CH01' and up to a maximum of 50 connections on channel 'PETER.CH01'.
Now lets say channel 'ABC.CH01' has lots of connections / disconnections per minute. Therefore, most likely the 'count of 1000' will be it first (rather than 600 seconds). The PCF command will be issue (i.e. dis chs('ABC.CH01') ). The shared memory for that particular channel will be refreshed including the attempts counter & timestamp. Hence, the PCF command will not be issued again for that channel until either 600 seconds or 1000 connection attempts are reached.
| Quote: |
| 10 Channels running with #11 trying to get in? |
First, #11 will not be allowed to connect. Secondly, if the 'attempts counter' in the shared memory is at 450. Then no PCF command is issued. If the 'attempts counter' in the shared memory is at 999. Then 1 PCF command will be issued to refresh the shared memory 'active channel status' variable.
Hope that helps.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Mar 21, 2005 11:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
I guess I don't understand how #11 is blocked from starting, if the PCFInquiry has not been issued lately?
How does the exit know not to start #11, if it has been like 450 seconds since the last PCFInquiry? Maybe in the last 450 seconds, the 10th channel has started, so now there are 10 active channels for this particular channel. How will the exit know not to start #11, if it has to wait 150 seconds more?
I feel I need to know what is happening behind the scenes so I can pick good values for the retry counts and intervals for the exit.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Mar 21, 2005 11:54 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
| Quote: |
| I guess I don't understand how #11 is blocked from starting, if the PCFInquiry has not been issued lately? |
The PCF Inquiry is ONLY used to refresh a variable in the shared memory called 'active channel connections'.
The task of validating a incoming connection and issuing the PCF Inquiry command have nothing to do with each other (under the new design).
Everytime a connection is attempted, the security exit adds 1 to the 'active channel connections' variable in shared memory. A few lines later, the security exit then compares the 'active channel connections' variable against the 'max connection channel' variable.
i.e.
if ACC > MCC then reject connection
else continue
Notice that no PCF inquiry is involved. When 'x' seconds have passed or 'n' 'connection attempts' have passed then a PCF inquiry command will be issued to get the current number of active connections from the queue manager. This number will then be saved to the 'active channel connections' variable.
i.e.
ACC = results from PCF Inquiry command.
Once the refresh of ACC is done by a PCF inquiry, you really don't need to do it again for quite a while (unless channels are crashing or the MQ Admin is playing around with the channel definitions).
Personally, I would set those keywords to:
MCCRedoSeconds=3600
MCCRedoCount=10000
or even higher
MCCRedoSeconds=86400
MCCRedoCount=100000
86400 is the number of seconds in a day.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Mar 21, 2005 12:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
OK, that helps.
Maybe this is too anal.....
MCC is set to 100.
There are 50 channels up, and for the sake of arguement, the ACC is refreshed, and it correctly says 50 now.
In the next second, 51 new channels try and start. The last one fails, because it pushes ACC over MCC. Cool.
Now take this example:
We have 100 channels, the interval passes, ACC is set to 100.
40 channels drop in the next 10 seconds.
The exit still thinks ACC is 100, even though there are really only 60, right, because the interval or connection attempts did not pass, so it is stuck on cached data?
So what happens at this point if 10 new channels try and start? Will they all fail, because the exit incorrectly has ACC cached at 100?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Mar 21, 2005 12:43 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Ok, I have simplified it greatly. I have left out a few thousand lines of code.
(1) When a channel attempt is initiated, MQ fires ExitReason of MQXR_INIT. In the security exit, it adds 1 to ACC.
(2) When a channel is ended, MQ fires ExitReason of MQXR_TERM. In the security exit, it subtracts 1 from ACC.
(3) For security flows, MQ fires ExitReason of MQXR_INIT_SEC or MQXR_SEC_MSG the security exits begins it’s processing.
| Quote: |
| We have 100 channels, the interval passes, ACC is set to 100. 40 channels drop in the next 10 seconds. The exit still thinks ACC is 100, even though there are really only 60, right, because the interval or connection attempts did not pass, so it is stuck on cached data? |
No. As the connections are dropped, ACC will be decremented by 1 each time. Therefore, ACC should reflect the correct value of 60.
| Quote: |
| So what happens at this point if 10 new channels try and start? Will they all fail, because the exit incorrectly has ACC cached at 100? |
No. Since ACC is at 60, they will be able to connect and that will cause ACC to be raised to 70.
Hummmm. I can rent a room in the evening at the MQ conference for $750. Do you think I should rent it and have a session on have to install/configure the new security exits?
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Mar 21, 2005 12:47 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Thanks Roger. So it looks like you refresh the ACC by a PCF inquiry only every so often to make sure your #s are still good, as you seem to incriment and decrement the # everytime it would change anyway.
I don't know about the room. I think if you include all the above info in the manual for the exit, including a few sample scenarios, it should be enough.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Mar 21, 2005 10:08 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
| Quote: |
| So it looks like you refresh the ACC by a PCF inquiry only every so often to make sure your #s are still good, as you seem to incriment and decrement the # everytime it would change anyway. |
Exactly.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| 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
|
|
|
|
