Tuning on a Budget (Part 2)
Use these Delivered Tools to Keep your Apps Humming
Posted on 4/19/2007
by Mark Saucier
This is the second half of a two-part article focused on performance tuning on a tight budget. The first article dealt with using a free tool that can be downloaded from Microsoft called Web Application Stress tool (WAS). I covered setup, recording and play back of a stress test. The goal of that article was to show you how a free tool could be used in performance tuning activities.
This article will continue with the theme of performance tuning on the cheap by showing you how to use delivered tools to monitor the health of the application while stress testing. I will also share with you a handful of configuration changes that should help most installations achieve better performance. What I hope you can do is take the 2 part series and be able to implement some form of performance tuning into your next project. Whether it's an upgrade to the next version of PeopleSoft, tools upgrade, or next module rollout.
While the results from the web application stress tool provide useful information, it can only tell a very small story about the health of the architecture. To get the other sides of the story you need a set of monitoring tools to gather performance measures from all tier's of the PeopleSoft architecture while the WAS test script is running. There are plenty of monitoring tools on the market but why spend when you can use something you already have. Performance monitoring tools collect information and present it to you in one location. Time needs to be dedicated to the installation configuration and training of one of these tools. This all amounts up to a cost that most projects do not plan for, and if they do then the money and time usually are reallocated somewhere else. Most installations do not need such an elaborate approach to monitoring and can achieve optimal performance by taking a light weight approach to monitoring during stress testing like the one used in this article.
As part of PeopleSoft's Total Ownership Experience TOE initiative, PeopleSoft introduced a set of tools aimed at assisting customers in getting the most out of the product. As a result 2 key tools were introduced PsPing and Performance Monitor. Performance monitor was released with PeopleTools 8.44 and PsPing with PeopleTools 8.19. For this article I will stick with WAS as my stress test tool and a combo of PsPing, PsAdmin and a hand full of key Operating system measures to monitor the health of the architecture. (
See Table 1 - Microsoft Window Performance Monitor Values)
Goal of Performance Tuning
What is the goal of performance tuning? I'll tell you what my main goal is. To achieve the best possible response times between all the tiers of the architecture. While this may seem very general, there are some other things I am after. Validate the architecture configuration and make recommendations. Determine the breaking point of the architecture to plan for future growth. Often future plans do not take into account a performance impacts and while it's great you plan to rollout more functionality. That new module might lead to more users or different types of transactions and although you have some powerful hardware behind those users the configuration may not be optimal.
What is PeopleSoft Ping (PsPing)?
PsPing allows you to measure the response times of a PeopleCode simulated transaction. While this does not directly measure the response time of the WAS stress test it does provide critical data that is needed. The PsPing page repeats the transaction after the interval specified. An animated GIF clock and a counter provide a visual clue the page is running. While the WAS stress test is hitting PeopleSoft with concurrent users all doing the same transaction, PeopleSoft ping is traversing the layers and gathering response times. If the results of ping show high times at any of the layers you can focus attention there. I have to say that with a bit of caution because it is important to look at each piece and understand how a change will impact the next link in the architecture chain. You may have a properly configured database server with processing power capable of handling the most demanding of users but without a WebServer capable of letting the traffic in, the database will be only as good as the weakest link in the chain and in this case it is the WebServer
Prior to PeopleSoft ping I would configure each server to produce detailed log files that would show the timing of transactions within the layer. I would run the test script then gather the log files from each server. Take the results and create a csv file then import that into excel to analyze. This process was very time consuming and requires changes to the servers that you will not easily find in delivered documentation.
PsPing will show us how quick the servers are responding to a transaction. While this information is important, I also use Bea tuxedo monitoring tool PsAdmin and Web logic's console to view the health of the application server and WebServer. Primary focus of the article will be on using PSPing and PsAdmin while running a WAS script.
To continue reading this article you must have a current VP1 Subscription.
