Author |
Message
|
vmcgloin |
Posted: Wed Feb 21, 2007 8:12 am Post subject: Performance - message set caching? |
|
|
Knight
Joined: 04 Apr 2002 Posts: 560 Location: Scotland
|
Can anyone point to me to a MB performance anaysis where message set caching is discussed please? Or any personal observations on message set caching?
After some technical testing using message flow accounting & statistics to analyse performance we have shown that the first time a message goes through some new flows it can take over 1 second to process, whereas after that it only takes milliseconds.
The messages are not large and the flows convert from MRM-XML to MRM-CWF. We presume the message set is causing the initial delay because reply flows that share the same message set do not get the same performance hit. The message set is not complicated or large - only 2 short XML message definitions and 2 CWF equivalents.
Any opinions/advice, or is this just something you accept happens the first time a message set is used?
Thanks,
Vicky |
|
Back to top |
|
 |
kimbert |
Posted: Wed Feb 21, 2007 8:13 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
This is exactly what I would expect. Is it a problem, or were you just curious? |
|
Back to top |
|
 |
vmcgloin |
Posted: Wed Feb 21, 2007 8:37 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002 Posts: 560 Location: Scotland
|
Thanks for the quick response. We expected some delay for caching but were surprised at it being over 1 second. I presume there is no tuning to be done (other than upgrade to V6 since I forgot to mention this is on V5)? |
|
Back to top |
|
 |
kimbert |
Posted: Wed Feb 21, 2007 9:05 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
v6 will not be faster than v5 when loading a message set for the first time.
I'm interested to know why you think this matters. Do you really care how long the very first usage of a message set takes? |
|
Back to top |
|
 |
vmcgloin |
Posted: Wed Feb 21, 2007 9:32 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002 Posts: 560 Location: Scotland
|
We care because there is a potential for timeouts/slow responses for the end user.
This will not happen often, but it will happen once every time the broker is restarted e.g. maintenance. We have multiple brokers (with clustered qmgrs for load balancing/resilience) so the user could potentially get multiple slow responses if they happen to be the first person to call a particular service.
This behaviour is expected and message broker might not be the most significant delay for the first call to the service but if we can minimise it we would like to. Users do not notice that their response is back in a hundredth of a second or so, but they notice (and remember) when it takes much longer (relatively).
To be honest though, we can simply say it is a delay due to caching and live with it.
Thanks,
Vicky |
|
Back to top |
|
 |
kimbert |
Posted: Wed Feb 21, 2007 1:48 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
I thought so - this is a quality-of-service agreement issue.
If it becomes a real issue you could very easily pre-cache the message sets. One way would be to construct a message flow which issues CREATE...PARSE using each message set in turn and trigger that flow exactly once as you start each broker. |
|
Back to top |
|
 |
|