• Forums
    • Public Forums
      • Community Connect
      • Dynatrace
        • Dynatrace Open Q&A
      • Application Monitoring & UEM
        • AppMon & UEM Open Q&A
      • Network Application Monitoring
        • NAM Open Q&A
  • Home
  • Public Forums
  • Network Application Monitoring
  • NAM Open Q&A
avatar image
Question by Nathan M. · Apr 17, 2015 at 06:37 PM ·

Operation Time Explanation

Hello,

I have a customer who is posing a question about the operation time we are seeing for some mq requests coming into a server like so:
 

He is stating that these operation times are unrealistic based on the response times he is gathering for the associated Brokers internally which average about 100 ms . My theory is that the metrics he is grabbing and the metrics dcrum are reporting are from represent different sets of measurements. So my question is from a DCRUM perspective what does this operation time represent? From my understanding it represents the time it takes to send the mq message from server A to request que B and does not take into account any of the broker work that is processed once that message is on the request que  Am i right in my assumption?  Let me know if i can clarify anything. Thanks for looking into this.

Comment

People who like this

0 Show 0
10 |2000000 characters needed characters left characters exceeded
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

1 Reply

  • Sort: 
  • Most voted
  • Newest
  • Oldest
avatar image

Answer by Ulf T. · Apr 20, 2015 at 07:27 AM

Hi

My understanding that this is on a TCP level (in all message protocol decodes) and a message level. That is that we check the delivery of the message against a queue and the ACK of that message from the target queue on a message level (not necessarily the destination). But we don't know if this is the "end" queue so that the message is to be processed here, or if it's just a queue "hop" by the  message. In theory, you can have an endless number of "hops" by a message and we wouldn't necessarily know which one is the final.

AFAIK, the internal channel protocol of WMQ isn't freely available and hence, our decode can't decode that.

But it all relates to what you hint to yourself - what is he comparing the measures to?

Comment

People who like this

0 Show 0 · Share
10 |2000000 characters needed characters left characters exceeded
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

How to get started

First steps in the forum
Read Community User Guide
Best practices of using forum

NAM 2019 SP5 is available


Check the RHEL support added in the latest NAM service pack.

Learn more

LIVE WEBINAR

"Performance Clinic - Monitoring as a Self Service with Dynatrace"


JANUARY 15, 3:00 PM GMT / 10:00 AM ET

Register here

Follow this Question

Answers Answers and Comments

1 Person is following this question.

avatar image

Forum Tags

esm siebel Dynatrace Managed license nam probe wan citrix dna rest api configuration mq alerting NAM 2018 dashboard dcrumadvisory reports css nam universal decode database mobileapp RUM ads sap nam console scripting nam server sequence transactions nam 2019 upgrade
  • Forums
  • Public Forums
    • Community Connect
    • Dynatrace
      • Dynatrace Open Q&A
    • Application Monitoring & UEM
      • AppMon & UEM Open Q&A
    • Network Application Monitoring
      • NAM Open Q&A