| Testing PeopleSoft Performance |
|
| Tuesday, 10 October 2006 | |
|
Even with a modern packaged application like PeopleSoft, it's possible (and actually quite likely) that performance problems exist and won't show up until after go-live when all of your production users are actively hitting the application. Why? The reasons have less to do with poorly written software (PS/Oracle usually writes relatively efficient code), and more to do with the complexities of the application architecture. In a typical implementation, IBM HTTP Server handles all HTML traffic and hands off the work to IBM WebSphere. WebSphere manages sessions and communicates with the BEA Tuxedo Application Server which handles the business logic layer and communicates with the database server. The Operating System(s), system hardware, SAN's, load balancers, clustering software, network, etc., all play a part in performance. Each component has its own tuning parameters and if any one of these components are not tuned appropriately performance suffers across the board. That's why it's a good idea to test your performance. Fortunately, performance testing doesn't have to be a long, drawn out ordeal nor does it have to be expensive. It just requires a plan, a performance testing tool, the right people on the performance testing team, and a way to capture performance data for each component. The performance testing plan should provide the framework and scope of the testing effort. It should outline the purpose of the testing, define basic terms like "Concurrent User", and include what tests will be conducted, what will be measured, and how you'll know if you're successful. I generally like to name team members in the plan along with contact information just so there's no confusion about what will be expected. I've used Segue's Silk Performer in the past and it works very nicely for PeopleSoft performance testing. But if you don't have a commercial tool, Jakarta JMeter from the Apache Software Foundation (http://jakarta.apache.org/jmeter/) is an open source tool that has all of the features you'll need. When you're writing the performance testing scripts, don't try to write a script for every system component. Keep it to just the most commonly used on-line activities. Also, don't try to test the "worst case". Performance testing tools can generate way more transactions than a person could ever enter. Be sure your performance testing tool at its peak won't generate more transactions than you'll find on a busy day in the database. A few quick queries should show if you're in the ballpark. I have heard that PeopleSoft benchmark reports define a concurrent user for Financials as someone who enters one transaction every 5 minutes. In my opinion, that's one very busy person. Assembling the performance testing team is generally a matter of talking with the folks that already support your application. In addition to your PeopleSoft Application Administrator, you'll want to have a System Administrator to monitor the OS and the Kernel; a DBA to monitor the database; and a Network Engineer to monitor the network. If you feel like you're weak in a particular area, go find someone in your organization that can help. Or if you think you can cover multiple areas, the team can be smaller. Capturing performance data doesn't have to be a huge deal either. If you're running on UNIX or Linux, it's easy to redirect VMSTAT or SAR output to a file during the test for memory and CPU info. Windows provides a way to capture performance data to a file as well. I have some scripts that use TMADMIN to track # of users logged on, # of Tuxedo request, and whether or not queuing is happening. I generally use WebLogic console to watch threads and JVM heap info as the test is running. On the database, TKPROF is a great way to measure many things in an Oracle database, and SQL Profiler has a lot of functionality for SQL Server. I generally divide my tests up so that we start with 1/3 of the target load, then 2/3rds for the next test, and finally the full load. While each test is running, I have the performance testing team on a conference call so we can discuss what's happening in real time. I've found that a 20-minute test seems to provide good information, but I don't mind cutting it short especially if problems become obvious. While the test is running, I like to log on to the system and navigate around, just to get a human's opinion of performance. I keep a performance testing narrative document up to date with the "play-by-play" info which always includes at least the time the test started, what memory, CPU, threads and JVM Heap were doing at various times in the test. This narrative also helps me make sense of all of the data the team members will be sending at the end of the test. The narrative also includes any changes that were made between tests so we can tell what worked, and what didn't. Once we're sure the system will work at the required load, and if time allows, I like to do a stress test to find exactly at what load the system will break down. This gives an idea of the overall system capacity which is a great statistic to know for planning purposes down the road. Anyway, that's more or less how I approach performance testing. If you have any other ideas or approaches, please share. |
|
| Last Updated ( Tuesday, 10 October 2006 ) |
| < Prev | Next > |
|---|