This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
PMT : How to Analyze Execution Stacks
In my previous article, I showed how you could use the lightweight performance measurement tool (PMT) to find slow requests. Now, that you found them, you probably want to know what could be done to improve things.
In this article, I will describe how to use the execution stack reports to narrow down the source of performance problems by analyzing where execution time is distributed.
Execution stack analysis is usually done with trace logs or java profiling utilities. Those tools usually provide a very large amount of information about execution which can be difficult to navigate. The new performance profiler generates information only at the most important application layers. This enables us to generate execution stack reports that can quickly narrow down performance problems and remain small enough to read quickly.
The stack reports
After generating performance reports, you might notice that some of the reports include links to execution stacks.
For operation performance reports, the stack link will lead you to an XML file containing 3 sample execution stack of that operation by using the fastest, slowest and average request execution time.
For execution performance reports, the stack link will lead you to an XML file containing the execution stack of that particular operation.
Using a web browser XML visualisation plugin
To view the execution stack XML files, I recommend to either use a good XML file editor or to install a XML visualisation plugin in your web browser.
In this article, I will use the "XV - XML Viewer" plugin on Google Chrome with a 150% zoom.
I've also experienced good results using "Notepad++" for which I start by using the "View - Fold All" menu and by disabling word wrap. Once that's done, I can expand the execution stack to focus on the parts that interest me. Typically, they are the parts that have the longest execution duration time.
How to read a stack report
Stack reports will show you where time was spent during a request execution. To narrow down that time, you have to navigate the XML file by focusing on the source of time consumption.
In the example below, my CategoryDisplay request takes 720 ms to complete. Of that time, 592 ms are consumed by the SubCategoryPage.jsp. By expanding the XML content, I can dig in the execution tree until I find the most important source of time consumption.
What are the "delta" nodes?
Delta nodes can be generated by various factors such as:
· CPU intensive algorithms.
· Operations that wait for a lock.
· Operations that wait for Input / Output.
· Operations that have been preempted by other threads.
· Operations that aren't instrumented to capture execution statistics.
Tracking requests across servers
Execution stacks can even show where time was spent between the boundaries of different servers. For example, on WebSphere Commerce, it is possible to track the execution of a request between the page rendering servlet and the search server.
This is done through the OperationID header inserted in the search server request.
To generate reports that include both servers, just ensure that the trace log files of both the commerce and the search server are used to generate the performance reports.
This is done by adjusting the property file used during report generation.
For instance, the following configuration is used on runtime server:
logFileToLoadList= /opt/WebSphere/AppServer/profiles/demo/logs/server1/trace.log | /opt/WebSphere/AppServer/profiles/demo_solr/logs/solrServer/trace.log
In the example below, the "REST Tag" is executed on the commerce server while the "REST : GET" part is executed on the search server.
As we saw, the execution stacks can quickly narrow down the source of performance issues and speed up investigations.
In my next post, I'll describe how to get JDBC queries to show up in the stack reports.