You may have been part of commerce implementation cycles where the functional stability pushes the timelines for the performance iterations. In such scenarios, the project teams may decide to start some level of application diagnosis while waiting for the isolated performance system with stable functional build.
The lower testing environments like SIT (System Integration) and UAT (User Acceptance) can make good platforms for the solution implementation and development team to do analysis on the application performance. These are some of the factors you would like to consider when you would like to use them for diagnosis and consider them in your analysis factor.
a) What is their deployment topology with respect to the production
b) What is the level in terms of the cumulative fixes, APARs wrt the production
c) What is the data load sizes with respect to the production
d) What are the management center business rules, activities, search rules present
e) What are the eSpots and promotions available
f) Can you get some isolated time slot to conduct your single user and some trivial load tests
g) What is the state of the integration systems like order management, payment, and others and how do you isolate your diagnosis
There are several monitoring tools that I have covered in my other blogs that can aid in your analysis. You may not have an APM (Application Performance Management) tool installed on these environments’, however you do have access to the Health Center tool which is packaged with WebSphere Application Server (WAS). I will use this specific article to focus on one of the IBM Monitoring and Diagnostic Tools, Health Center, which is an agent-based diagnostic tool for monitoring the status of a running Java applications.
The Health Center agent libraries are included with the WAS server Java SDK (Health Center 3.0 or later is required for WebSphere Commerce). This makes it an easy-to-use tool available on these environments which can be used by the developers, architects and performance analysts. The Health Center tool can be as easily used in the toolkit development environment to allow developers code for performance. It will show them the time spent and the thread stack. It is prescribed that all developers profile their code and make it performing prior during the implementation phase and work on the 80-20 rule, where if you are able to optimize the highest consumers, you will gain performance. When the code is in the SIT and UAT, the focus should be more from an integration perspective. However, I must admit, we often end up doing application level code tuning based on analysis till much later in the cycles.
Configuration, Setup and Running Health Center
1 – Check the version
2 - Enabling the Health Center agent in profile or headless mode
In the headless mode, the agent starts collecting data immediately, and stores the data in files called healthcenterpid.hcd, where pid is the process ID of the agent. You can load this file into the client at a later date, to view the data. Headless mode is useful for systems where you cannot connect a client to the agent.
I am going to use the health center tool in the full mode for this article. The agent starts collecting data immediately and then you have to launch the client and connect to the server process for viewing the data.
3 – HealthCenter Settings
The Health Center agent can be configured as the JVM properties. Please refer to the KnowldegeCenter documentation for the configuration.
Property (use -D for JVM arguments)
Use this format with the -Xhealthcenter option of the Java command when you start the agent and the application at the same time
Sets the JMX port number. For JMX client-agent connections (the default), the client uses port 1972 by default for communicating with the agent. If the client cannot use port 1972, it increments the port number and tries again, for up to 100 attempts. You can override the first port number that the agent tries to use.
Set to on to enable the client to communicate with the agent by using a JMX connection. This property is set to on by default.
Specifies headless mode. The agent starts collecting data immediately, and stores the data in files rather than sending it to the client. When the application ends, the agent creates a file called healthcenterpid.hcd, where pid is the process ID of the agent. You can load this file into the client at a later date, to view the data.
If headless mode is used, you can specify multiple other settings
4 – Restart the server
Restart the WebSphere Commerce Server you are profiling. Confirm that the healthcenter agent shows up on the server. You will find the directory <healthcenter> created under the application server logs
Installing the Health Center Client to View Data
Using a Health Center Client to View Data
1 – Connect the Health Center to the port mentioned while starting the application server.
The connection will start and you will be able to see the following data using the left navigation.
Example of a Profiling View for com.ibm.commerce.rest* filter:
You can use filters to view the classes and methods that you are watching. You can then turn on the trace for the method you want to drill. In Health Center, you have to enable method tracing when you start your application, as it cannot be enabled at run time. Enabling method tracing is intensive and negatively impacts application performance, so you want to do it based on what you are drilling.
Using health center profiler for your debugging
I am showing a few screenshots to help you see the traces for some of the commerce use-cases.
If your storefront has created extension to the Wish List and written custom code around it, you are looking to profile the user actions around adding to wish list, sharing the list and viewing it. You can chose a filter com.ibm.commerce.giftcenter.* and then look at the Invocation paths.
You may use the “Reset Data” button on the toolbar to get data for the current flow only. The second button from the right.
Search based operations:
IBM Health Center allows the commerce developers to monitor and profile their application in development and testing environments with an ease, no additional skill and resource required to install and use monitoring tools. The tool comes pre-installed with WAS and has a simple configuration to be setup in both profiling mode and headless mode.
The tool provides data like CPU usage, GC, I/O, Network, however the focus I have provided in this article is the profiling of live application, and using the method traces. This enables a developer to review the invocations and get into the details of the hot methods and drilling further to locate and then work on them. It will allow the analyst/architect/developer to analyze the path taken for a cold, not-warmed page versus and cached page. The developer can extract nuggets of information from the flows, which help with both troubleshooting functional issues, and performance issues.
When do you exercise load on the environment, the Health Center will allow you to view the system metrics and JVM metrics like the threads information. The Web Container threads are most valuable in understanding the behavior of application under load. I will come back to discuss the thread analysis topic again. If you are interested in some specific monitoring methodology or tool, feel free to talk about it using the comments section.