Filter Purepath dashlet on response time
Hi,
Is it possible to filter the Purepath dashlet on response time?
I would like to only display slow purepaths without having to create a BT for it.
This is especially useful for displaying historic data.
I cannot find the setting in the dashlet filter settings.
Cheers,
Kristof
You can use the TopX Filter on the dashlet, e.g: Top 10 based on Response Time
Hi Andi,
I had tried that, but there is a hard limit of 100 (I think, don't have access to a client at this point) which is not sufficient. The client I am working at has 10000s of transactions and we want to filter on all that take longer than for example 10seconds. We could create a BT, but that would only work for new purepaths so we would have to plan ahead for this. It would be great if we could actively filter on this. Maybe an Idea for the next release?
Cheers,
Kristof
You are correct - 100 is the limit right now. So - the BT is the only option you have in the moment.
But - let me please better understand the use case here. What would you do with 10k+ PurePaths that take longer than 10s? Would you really look at them in the PP Dashlet?
The customer is having a weird performance issue pattern.
All day their 6 JVMs are humming about at around 350-400 threads and all is good. Then all of the sudden one JVM starts slowly ramping up in thread count to about 1500 and eventually dies. Shortly after that, all the other JVMs will spike immediately to 1500 threads and die as well.
I am looking at stored sessions and live session alike to find a pattern as to why this happens. So I look at transactions in the PP dashlet to find those patterns
In this case I assume that there is a deadlock or other sync problem in the "regular" worker threads. Once these are blocked from execution new requests that come in will spawn the additional threads that you see until your app reaches the point where it simply dies.
Now - instead of looking at PurePaths and filter them by slow duration I would rather use the Response Time Hotspot Dashlet. Set it to the timeframe where you start seeing that problem and also filter it by e.g: Slowest 10% (there is an option in the top right of this dashlet to do so). I assume that you will see lots of Sync/Wait or Suspension time in one of your Tiers or APIs. From there drill to the Methods Hotspot Dashlet. Identify the methods that are blocking - and from there drill to the PurePath
THIS IS THE WAY to analyze Hotspots in PurePaths. We have built those "Hotspot" Dashlets exactly for these scenarios where you have a large set of PurePaths and you want to locate the Hotspot
Give it a try and let me know
I had this exact situation last week at a client. I took a different approach. Like you, there was a known "steady state" number of threads (yours is around 400) and a "bad state" where if you are there, you are in trouble (yours is 1500). I set a threshold on thread active count to be up at that bad level, and had the action of the incident be to fire a thread dump. That pointed me immediately at the blocked/blocking threads, and also let me see that the blocking resource was a SynchronizedMap. That gave me the "what".
The hotspots (as Andi suggests) showed the "where", because I could see massive SYNC time. For me, it was antique IBM jsp processing code that ultimately was getting blocked on that SynchronizedMap construct.
