Overview
Over the last few months we went live with a Global Available-To-Promise (ATP) project, moving application logic for back order processing from our SAP R/3 transaction system to a new Supply Chain Management (SCM) system. In my capacity planning role, I helped size the SCM landscape, and have also consulted on performance tuning in the R/3 system over the last few years, and recently in the SCM system.
We have seen that sales order management is a significant portion of the total R/3 workload, and expected that moving the processing from R/3 to SCM would free up resources on the R/3 side. Adding SCM hardware and software is a significant investment, so measuring the workload impact is an important task for infrastructure management.
While we've only been live for a couple months, more projects are in the pipeline, as well as possible version upgrades (both R/3 and SCM), so we needed to do a delta sizing exercise. I got advice from Bill Adams of SAP, and spoke to our hardware partner, at Tech Ed in Las Vegas. I also spoke to Frank Lukens from SAP about scalability and performance of Live Cache.
While Quick Sizer should generate capacity requirement for SCM, no one had a good method to measure what load SCM is causing in R/3.
Detailed Analytic Process
I spend a lot of time poring over ST03, the Workload report, or Workload Monitor. Here are screen shots showing how I got to the base data for this analysis.
When ST03 is first started, it shows the Administrator view:
Switching modes from Administrator to Expert gives this view, now titled Workload Monitor:
Drilling down by time shows Days, Weeks and Months. I'll look at the month of October here:
The top section will show the period on the left, and start/end times on the right (cropped off here).
Switching the view from ALV grid to Excel spreadsheet is an easy way to move the useful data into the analysis tool.
This gives us the "total" workload in the system, although it is reported by category such as Background, Dialog and RFC.
Now, on to the external system portion.
Switch to a different Analysis View by clicking on Load From External System. The period should remain the same as before unless you navigate elsewhere in the meantime.
Once again, switch the display view to Excel in order to copy the relevant data.
We now have total workload and external workload.
I'll gloss over spreadsheet mechanics to show the final product.
| Task Type | Number of Steps | T RESP - CALC | Ø Response Time (ms) | T CPU - CALC | Ø CPU Time T | DB - CALC | Ø DB Time (ms) |
|---|---|---|---|---|---|---|---|
| ALE | 148 | 142 | 956.1 | 5 | 36.2 | 69 | 468.6 |
| AutoABAP | 13,769 | 15,005 | 1,089.80 | 7,897 | 573.5 | 1,655 | 120.2 |
| Background | 230,936 | 192,139 | 832 | 44,247 | 191.6 | 75,170 | 325.5 |
| Batch Input | 1,629 | 579 | 355.2 | 175 | 107.5 | 244 | 149.7 |
| Buffer synchr. | 44,348 | 284 | 6.4 | 9 | 0.2 | 200 | 4.5 |
| Dialog | 360,830 | 165,116 | 457.6 | 47,305 | 131.1 | 47,305 | 131.1 |
| HTTP | 37 | 143 | 3,878.10 | 3 | 88.6 | 71 | 1,922.20 |
| Others | 141,122 | 1,496 | 10.6 | 268 | 1.9 | 635 | 4.5 |
| RFC | 111,788 | 76,418 | 683.6 | 13,582 | 121.5 | 29,613 | 264.9 |
| Spool | 267 | 936 | 3,504.50 | 11 | 41.1 | 45 | 169.3 |
| Update | 152,500 | 8,632 | 56.6 | 3,096 | 20.3 | 3,416 | 22.4 |
| Update2 | 25,053 | 3,104 | 123.9 | 466 | 18.6 | 624 | 24.9 |
| * TOTALS * | 1,082,427 | 463,993 | 117,064 | 159,046 | |||
| System ID | Number of Steps | T Response Time (s) | Ø Response Time (ms) | T CPU Time (s) | Ø CPU Time (ms) | T Database Time (s) | Ø DB Time (ms) |
| SCD | 59,987 | 25,864 | 431.2 | 3,688 | 61.5 | 6,724 | 112.1 |
| Calculations | 5.5% | 5.6% | 3.2% | 4.2% | |||
Findings
External RFC load > 5% of total time (development)
External RFC load about 1/3 of all RFCs.
In production, we've seen SCM load up to 10% of the total CPU in R/3.
Next steps
Compare R/3 total load before and after ATP go live.
