Corrupted PurePaths and BTs
Hello,
Is it possible to have corrupted purepaths included in the results of a BusinessTransaction?
My customer has a problem transaction. The purepaths are becoming corrupt due to the duration of the transaction, but my customer would like to be able to determine the invocation count of the corrupted purepaths.
Thanks,
Joel B
Copying and pasting the BT from one system profile to another would be easy to do especially since you could keep the same name. Then copying and pasting the chart and changing the source for each dashlet would give you the data for different system profiles.
Hey Daniel,
Have you considered charting the response time for the agents instead? It is possible to simply include the agents that you consider to be your backend within a business transaction and chart the response time of the business transaction. This will exclude the asynchronous calls as well as the purepath timeouts. Would that work for your environment?
This could be a possible solution; however this will becoming challenging in terms of set-up. This would work for a single profile; however, we created a dashboard which would work with multiple system profiles. This solution would require a set-up of a different Business Transaction for every system profile.
I had a discussion with one of our architects. We came up with the following idea - if you think thats what you need please create an RFE Forum Post:
If the Web Request and Web Service Response Time Measures would have an option to say "Show Client Time" or "Show Server-Time" then you could easily measure the Resopnse Time of every "Service" call as perceived by the Caller (=Show Client Time") and the Server-Implementation (=Show Server Time). As this measure can be split by Agent you should be able to chart Response Time of every "Service" per Agent. As "Response Time" will not include any async behavior this should do the trick.
Thoughts?
Thank you for coming up with that idea! Yes. That would indeed be one possible solution as long as the measures for client and server time are also available in the tagged web requests.
Wouldn't the only difference to the tier subpath time measures be the fact that it uses response time rather than duration?
What is the reason we're using duration over response time in the tier subpath time measures?
To give you some historical background: The Tier Subpath Measure was implemented for a dashlet (that unfortunately never made it into the product) which was supposed to display time spent on a type of tier. Thats why Duration is used as we wanted to show actual time spent on a tier
If you like that idea please go ahead and create a forum post in the Product Feedback and Enhancement Requests forum
When Pure Paths contain asynchronous calls but only received a response for part of the transactions, pure paths time out with a state of Complete (timeout) and are Realtime Analyzed, meaning that measures and Business Transactions will still be processed.
When charting metrics such as Time Backend, the metric charted is duration for pure paths. In timed out pure paths the duration metric is the time-out value (in our case 10 minutes). With timed-out pure paths of 10 minutes duration, the chart indicates transactions are taking 10 minutes to complete. I understand that these transactions are showing up because the path is asynchronous, but shouldn't the metric charted be response time rather than the duration?
As there is currently no way to exclude metrics of timed-out asynchronous pure paths, our charts are displaying a high response time when in fact the cause is a timed-out pure path rather than an application performance challenge.
I experienced the same problem and opened an RFE for this. It's up to 6 votes. Please vote it up so we can get this resolved. No Incidents fire if PurePath is Corrupt!!!!!!
we have the same problem: i created an RFE for a more general solution. Analyse Corrupted and TimedOut Purepathes
I don't believe this is possible, because as I understand it, BT's are processed by the Real Time Analyzer at the completion of the PP. If the PP is corrupt, it is not sent to the Real Time Analyzer Queue to be processed.
I hope that helps.
Steve
