| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| time spent by a message |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Tue May 17, 2011 6:16 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| fedux wrote: |
I know, I know it is tiny, but I need to know how many milliseconds consumed!!
I have to prove that mq is not what is consuming the time ..!!!!!!
thanks |
I gather, perhaps incorrectly, from your post that you are new to benchmarking, performance tuning, problem-determination.
What exactly is the problem/issue that you/your management is facing? Are your MQ applications are failing to meet service-level agreements (SLAs)? Are some or all of your applications (MQ and non-MQ) failing to meet SLAs?
Throughput is an aggregate of all of the resources needed to perform a task. Each and every task incurs cpu cycles, network delays, disk i/o delays, and so on.
Access to cpu may be delayed by other work in the system. Access to the network (not just an mq channel) may be delayed by other network activity.
WMQ server software is an application that competes with all other applications for the limited resources of a computer.
You say that you have to prove that mq is not consuming the time. It is unrealistic to expect that WMQ imposes no additional workload on your system. WMQ does not artificially induce delays in throughput.
Performance problems are frequently the result of insufficient hardware resources. Is your processor in need of more cpus? More RAM? More I/O bandwidth? More network capacity? Is the application in question new? Recently change? Is there new workload on the processor? On the network? Has the network changed?
Performance problems for an individual application (or application-type) are frequently the result of poor application coding (poorly written SQL calls, for example).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
 |
| fedux |
| Posted: Tue May 17, 2011 7:03 am Post subject: |
|
|
Novice
Joined: 12 Jan 2007
Posts: 20
|
ok, I have an application that sent through a remote queue a request to another mq (ZOS) that processes it and returns the response to the original manager.
I need to know how long consumed the first manager to do its job
thanks |
|
| Back to top |
|
|
| fedux |
| Posted: Tue May 17, 2011 7:29 am Post subject: |
|
|
Novice
Joined: 12 Jan 2007
Posts: 20
|
| bruce2359 wrote: |
| fedux wrote: |
I know, I know it is tiny, but I need to know how many milliseconds consumed!!
I have to prove that mq is not what is consuming the time ..!!!!!!
thanks |
I gather, perhaps incorrectly, from your post that you are new to benchmarking, performance tuning, problem-determination.
What exactly is the problem/issue that you/your management is facing? Are your MQ applications are failing to meet service-level agreements (SLAs)? Are some or all of your applications (MQ and non-MQ) failing to meet SLAs?
Throughput is an aggregate of all of the resources needed to perform a task. Each and every task incurs cpu cycles, network delays, disk i/o delays, and so on.
Access to cpu may be delayed by other work in the system. Access to the network (not just an mq channel) may be delayed by other network activity.
WMQ server software is an application that competes with all other applications for the limited resources of a computer.
You say that you have to prove that mq is not consuming the time. It is unrealistic to expect that WMQ imposes no additional workload on your system. WMQ does not artificially induce delays in throughput.
Performance problems are frequently the result of insufficient hardware resources. Is your processor in need of more cpus? More RAM? More I/O bandwidth? More network capacity? Is the application in question new? Recently change? Is there new workload on the processor? On the network? Has the network changed?
Performance problems for an individual application (or application-type) are frequently the result of poor application coding (poorly written SQL calls, for example). |
everything you say is true (even I am new to banchamrk) fully agreed that the manager consumes resources and their performance is influenced by their environment as any other software.
but this should not prevent me to determine that the application made a put at xx: xx: xx.xxxx and the message successfully pass the host manager at xx: xx: xx.xxxxx ....
Obviously these times will have included the times of i / o network .... |
|
| Back to top |
|
|
| mvic |
| Posted: Tue May 17, 2011 8:15 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fedux wrote: |
| I need to know how long consumed the first manager to do its job |
2 ideas:
1. use "strmqtrc -m QMNAME -t api" to record the MQPUTs and MQGETs (and every other MQI call too). This will consume space in /var/mqm/trace so make sure there is plenty of space. Trace can be ended with "endmqtrc -m QMNAME". Make sure you are at a recent v7 fix pack as there were trace problems in early fix packs. No problems I am aware of in V6, though.
2. use API exits to record MQPUTs and MQGETs. There is a sample "amqsaxe0" to show what you can achieve with this. You cannot so easily turn this "on" and "off", though. It requires a restart of the queue manager to remove the API exit or change it.
Hope this helps. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 17, 2011 8:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
This is not a trivial requirement. Companies like HP and BMC (plus others I'm sure) sell products that can track particular messages across queue managers and provide reporting capabilities via web interfaces. I only mention this because if this was very easy to do on your own, these companies wouldn't have much success charging $$$ for these products.
There is also a support pack released in the past 2 years that offers exits to capture this type of info. But it requires outages to implement and while I have never personally used it, I imagine it might be tedious to pore through all the data and make sense of it in a busy system with many QMs involved. The vendor products you pay for help by providing very specific filtering capabilities to limit how much data you collect, and then are very good about presenting the data that was collected in a more digestible format than raw logs.
In big shops, the (true) cost of good tools is zero. Properly utilized, the amount of time and money they can save in the long run far out weighs the upfront costs.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Tue May 17, 2011 10:27 am; edited 1 time in total |
|
| Back to top |
|
|
| fedux |
| Posted: Tue May 17, 2011 9:32 am Post subject: |
|
|
Novice
Joined: 12 Jan 2007
Posts: 20
|
ok, thanks for your time.
i use the trace tool.
bye |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue May 17, 2011 9:59 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
In big shops, the (true) cost of good tools is zero. Properly utilized, the amount of time and money they can save in the long run far out weighs the upfront costs. |
In really big shops (mainframe z/OS), WMQ can capture SMF accounting and statistics data which can be used to meet this requirement.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 17, 2011 8:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Also note that depending on volume, I have seen multiple channels between a zOS qmgr and a distributed qmgr work better for throughput than if you were using a single channel.
This also avoids one full queue to slow down everything else on the (only) channel between the 2 qmgrs, that is if the full queue is only fed by one channel. If it is fed by both channels they will both be equally impacted.
This also means you have to select which traffic to send through which channel (and try to keep them equally busy at peak time...).
You simply need to have enough resources to keep the application queues nicely drained at all times, and have enough storage and qdepth to avoid ever having a queue full condition.
Have fun 
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
