How to tune ALUI Portal apps for performance?
Raymond Gao's Blog |
April 19, 2008 4:11 PM
|
Comments (0)
Recently, I have been involved in an ALUI portal performance turning project. In this project, the customer felt their portal application's response time was sluggish. To help them diagnosing the performance bottleneck, I performed a thorough and systematic analysis of their entire application stack. Now, I will summarize what I did.
Some people think that performance tuning an application or a portal is an art rather than an exact science. There is certain truth to that saying because there are often many moving parts needs to be examined. Correctly deciding on which components should be examined often requires previous experience.
At the same time, the experience of having had multiple projects experience showed me that there is a certain pattern or reusable methodology. That methodology is similar to pilot's checklist. For pass the FAA certified test and stay alive, an experience pilot will always do a pre-flight checklist, e.g. engine, gas, structure, etc.
During my engagement, I will do the following:
- 1. Examine high-level system architecture, e.g. component & deployment diagram, network infrastructure, etc.
- 2. Get the performance report and stress-test results
- 3. Performed a detailed analysis of each subsystem
- 4. And, a time-series sequential comparison of the system performance from 2 & 3.
I begin my analysis using metrics gathered from the Performance Stress Test. In my case, it was from the HP (Mercury Interactive) Load Runner performance report. Using this report, I was able to figure out the maximum system capacity (number of simultaneous users), system thorough-put, hit per seconds, and response time. Using those reports and diagrams, I can quickly identify correlation between the load (number of virtual users) and the threshold in the reduction in the overall system's response time, number of errors, etc. The result from the original (unmodified system) will also form the baseline of the report. Future results will be gauged against those initial results.
Next, I will examine individual system components. In my case, I used the Windows Perfmon tool to gather the system metrics during the stress-test. Those data allows me to make a judgment whether the ALUI portal has sufficient capacity to accommodate the number of expected hits. Those metrics include traffic on each Ethernet Card, CPU utilization, number of paged memory, Disk I/O, etc. Those reports tell me if the portal servers have been correctly sized, whether we need to add more portal servers or if it is sufficient.
Then, I will examine the remote portlet servers. In my last project, the remote portlets were hosted in application servers on Unix based machine. On Unix based machine, there are many powerful tools for gathering infrastructure level performance data, e.g. "iostat", "cpustat", "vmstat", "top", "sar", to name a few, ... Those results are similar to windows' Perfmon, and it shows you the infrastructure metrics - cpu utilization, network bandwidth consumed, etc.
Because portlets are hosted within application servers, I also examine the app servers as well. For example, you can attach JMX monitor to your Java application servers to get performance results and manage the application. Similar tools also exist for the IIS servers.
To dig even deeper, I recommend people using application profilers in the development environment and to optimize the portlet code. For example, lacking of caching can cause poor application performance problems. Such a tool allows you to review your portlet application from both high (package) and low (line-by-line) level and identify repeatable performance problems. The Eclipse IDE already offers the Eclipse Test & Performance Tools Platform (TPTP) Project. It allows you to address the entire test and performance lifecycle, from developer testing through production monitoring. It has application profiling, application monitoring and application tracing capabilities - http://www.eclipse.org/tptp/ . Similar tools are also integrated with Netbeans IDE and MS Visual Studio.
Furthermore, the server and application configuration files should be also examined. Examples include web.config, web.xml, portlet.xml, resources.xml, jdbc pool parameters(connection timeout, max number of connections), etc.
Another area of consideration is to review the backend database and optimize SQL packages. Properly tuning the database will also help the application performance. Modern database also offer many performance metrics allowing you to see the health of the database server, e.g. memory used, network traffic, cpu utilization, number of worker threads, etc.
Based on those results, you can identify the bottleneck(s) and make suggestion for system improvement. And, you should realize that system is only as good as the weakest link, whether it is the network, application logic (e.g. caching, patterns), database, ... Sometimes, other things influence the system performance, e.g. system back window, anti-virus scanning, and other security policies.
Example Diagram and Report.
1. 
Stress Test - User Load
2. 
Stress Test - ThoroughPut
3. 
Stress Test - Hits Per Second
4. 
Stress Test - Response Time
5. 
Perform Result
6. 
Portlet Server CPU Utilization
7. 
Network Traffic of the Database Server
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
|
