6. Ambiguous Capacity Testing requirements and goals

Symptoms: I have been to many projects where performance, volume, stress testing are an after through and only marginally considered during the final prep phase. Companies neglect to draft consistent, necessary, complete, and thorough testable requirements for conducting capacity testing during the requirements gathering phase (blueprint).  

Other issues surrounding capacity testing that I have seen at other projects include unclear goals and objectives such as “the system should run as fast as possible”, “the system should handle as many concurrent end users as possible”, “conduct a capacity system in a non production box and extrapolate results”, etc.  

Suggestions: Determine within the blueprint phase of your SAP implementation

the type of traffic, and business volumes that you are likely to see in your production environment. Leverage off statistics from your existing legacy systems, expected number of named users in production, and service level agreements (SLAs).  

Draft testable requirements that support your business needs for instance merely stating “I need to have average response times of 3 seconds per screen to complete a sales order” is unclear in contrast the statement “under a 500 user load in addition to batch jobs, all screens related to sales order creation will not exceed an average response time of 4 seconds per screen 95% of the time when accessed via corporate LAN under the web enabled interface” is a much more robust requirement.  

The project should document SAP user community profiles, along with expected system throughput from functional users, jobs running in the background and foreground, reports, batch jobs, RFCs, etc. The idea is to create distribution diagrams that show the system’s peak usage under a typical day, peak hours of the day, end of the month activities, end of the quarter activities, and seasonality. Armed with these diagrams the performance engineer can develop the necessary automated scenarios to identify your applications bottlenecks and degradation points, while verifying all of your capacity requirements.  

No matter how thorough your capacity requirements are there will always be unaccounted traffic that is not emulated since capacity testing is not exact science. To make up for this short coming verify that your system will successfully meet SLAs under a seasonality load, and then proceed to run tests with a load that is 125% greater than the maximum expected production load.