- Overview: What's a Mix?
- Real-World Low-Level Technology Stack Test Input and Mixes
- Testing and Tuning for Daily System Loads
- Testing and Tuning for Business Peaks
- Identifying Key Transactions and Business Processes
- Real-World Access Method Limitations
- Best Practices for Assembling Test Packages
- SAP Component and Other Cross-Application Test Mix Challenges
- Tools and Approaches
This chapter is from the book
This chapter is from the book
This chapter is from the book
9.5 Identifying Key Transactions and Business Processes
As I said before, there are many ways to identify the key transactions and business processes representative of a particular condition, event, or state. The opinions and experience of the end-user community that actually conducts much of this work is an obvious source of knowledge, albeit an imperfect and not necessarily holistic source. Regardless, I still recommend that you speak with your business representatives and functional experts. Indeed, for systems that have not gone "live" yet, there's really no alternative. But for precise and historically accurate information that reflects the load borne by your production systems day in and day out, week after week, month after month, I strongly encourage you to leverage the abundance of transactional and performance data sitting in CCMS. In this way, you can have insight into the whole picture—the most popular online transactions, the heaviest batch processing jobs and execution windows, visibility into the mundane repetitive tasks collectively responsible for much of the load, and so on. Month-end closes, seasonal peaks, and other high-water loads can be clearly understood in this way, and beyond this, how all of the various functions intertwine and come together to create the lifeblood of an SAP system—its workload—becomes clear as well.
Prior to following the steps outlined in the sections that follow, you need to determine the scope—typically by looking at an entire collection of application servers servicing an SAP system—and then the timeframe you wish to analyze. That is, SAP CCMS will allow you to look at the last "X" minutes or, probably more applicable for our purposes, a particular time period. I often start with analyzing the load of what I'm told is a "typical week" by plugging in start and end dates that reflect 7 full days (usually Sunday at 3 a.m. until the next Sunday at 2:59 a.m., though the timeframe you select may be different). I like somewhere around 3 a.m. because it's often the quietest time of the evening—backups are usually completed, the system is back up and available, but scheduled early-morning batch processes have not yet commenced, and few online users tend to be on the system. I try to avoid capturing only a partial business process or workload—as much as possible, I want to capture the entire week's work the moment it begins, without cutting anything off in the beginning or the end.
From this starting point, I then work to identify peak days within the week, and even peak hours within particular days. The term peak is subjective, of course, but most often involves first uncovering and sorting the quantity of transactions executed. Next, I'll change tack and look at all the transactions sorted by database load, CPU load, and so on. In this way, I can begin to understand the load placed on the various hardware components that underpin SAP. After this detailed analysis, I'll often take a look at an entire month's worth of data as well, just to be sure I didn't miss a particular processing peak not easily seen otherwise. And, in some cases, I might even drill down into a particular application or batch server, especially if capacity planning is one of the goals of the stress testing. In the sections that follow, we will walk through the exact steps necessary to uncover the specifics that come together to create your workload. To help you apply this process to all SAP systems, I will only draw on CCMS, as opposed to SAP Solution Manager or third-party systems-management applications and other tool sets which you may or may not have at your disposal.
9.5.1 Online User Transactions
To determine the mix of your peak online user transactions and how they interplay to create a load on your SAP system's hardware components, log on with a user ID capable of executing core basis transactions to the system being tested, and perform the following steps (if you prefer the newer ST03N, keep in mind that a certain amount of modification to the listed steps will be required. The changes are quite intuitive, fortunately, and for experienced SAP administrators or Basis consultants will present few problems, if any):
-
Execute transaction /nST03 (the Workload Analysis screen is displayed).
-
Click the "Performance Database" button.
-
Select timeframe.
-
Select the "dialog" button—in this way, only online transactions are analyze.
-
Select "detailed analysis."
-
Select a column to sort by, such as CPU, and double-click it. Transactions will now be sorted by those that consume the most CPU time. Record the top 40 transactions.
9.5.2 Batch Processing and Reporting
Follow a process similar to that outlined previously, though changed to reflect batch processes:
-
Execute transaction /nST03 (the Workload Analysis screen is displayed).
-
Click the "Performance Database" button.
-
Select timeframe.
-
Select the "background" button—in this way, only batch processes are analyzed.
-
Select "detailed analysis."
-
Select a column to sort by, such as database response time, and double-click it. Transactions will now be sorted by those that are most disk-intensive. Record the top 40 transactions.
9.5.3 Most Popular Transactions and Other Workloads
Using ST03, the process to identify the most popular transactions (i.e., those that aren't necessarily the hardest hitting but represent the bulk of activities performed on the system) is as follows:
-
Execute transaction /nST03 (the Workload Analysis screen is displayed).
-
Click the "Performance Database" button.
-
Select timeframe.
-
Select the "total" button—in this way, all transactions are analyzed.
-
Select "detailed analysis."
-
Select a column to sort by, such as CPU, and double-click it. Transactions will now be sorted by those that consume the most CPU time. Record the top 40 transactions.
9.5.4 Mixed-Bag Testing
With the step-by-step processes outlined previously, you should now have an understanding of the key online, batch, and noise transactions hosted by your system. At this point, you need to bring this knowledge together to create a "mixed-bag" workload—in effect, your workload to be emulated through scripting. Your workload mix will vary based on the goals of your test. For example, if you wish to test the benefits of a new server platform, you'll probably want to focus on the transactions that drive the heaviest CPU load. Similarly, if an updated disk configuration or brand-new virtual SAN is potentially in your future, you'll probably wish to create a workload that beats up the disk subsystem in the most representative manner.
Refrain from only focusing on a single type of transaction, though, if time and budget allow. Variety should be your mantra. For example, when it comes to disk subsystem testing, I suggest that you combine a number of hard-hitting online transactions and reports along with key batch processes, rather than simply going with easily scripted batch loads (easy because once you do one type, others tend to follow similar patterns or allow for cookie-cutter scripting approaches). In this way, different disk access patterns will be represented, which in the end will also best represent the real world. And I suggest tossing in a few noise scripts as well simply to keep a certain level of constant activity in the background, again representing the real world of most SAP enterprise solutions. At the end of the day, a mix of perhaps 50% batch processes to 25% online transactions and reports and 25% scripted noise activities will serve you well in stress testing and tuning your SAP disk subsystem. And the same argument can be made for testing other subsystems or technology stack layers, too—variety is desirable as long as your budget can absorb the incremental time necessary to perform the requisite business process scripting.