CXO Accent

Developing benchmarks and fine-tuning a SAP application

H Krishnan

Server response can be improved in an existing set-up with intelligent tinkering. Here’s how they did it at Rajashree Cements

System performance means different things to different people. For a system administrator it may be the combination of CPU utilisation, server uptime, memory utilisation and so forth all measured by metrics such as swap area usage, disk space occupied, average record read-write time, etc.

For an application programmer, it is how fast a programme executes. For the end-user it is how fast the screen changes from one data field to another, or how quickly a query executes and displays the results on screen. In the case of a typical SAP application, as data entry and reports are run all the time, we needed one simple benchmark of performance.

Generally, OLTP systems have a thumb rule that if on-screen response is less than five seconds it is considered to be very good, 5-10 seconds is considered to be OK, and greater than 10 seconds is considered to be slow. This can differ from set-up to set-up based on what users are accustomed to. With changing technology and demanding users, such measures may be dated.

Creating a benchmark for gauging the response time of a SAP system is akin to the process of establishing records in cricket. It is highly installation-specific, and hence practically useless elsewhere. We therefore decided to develop a benchmark for our set-up consisting of a Proliant 7000 server with twin CPU, six 9.1 GB SCSI hard disks in RAID 5, and 1 GB RAM. All modules of SAP were implemented, except S&D, with 50 users.

In SAP, processes or threads are called Dialog, Update, Batch, SPOOL and ENQuiry. In total, there are 18-20 processes. The SAP application collects DB statistics and generates reports of daily, weekly and monthly averages. A number of standard SAP programmes are available such as STUN (which gives the number of users whose average response time exceeded a given value), ST02 (Hit ratio), ST06-OS snapshot, and so on. After seeing all these values we settled on ST03 (performance, SAP statistics, workload) as a reasonably good indicator of performance for our site. This programme provides process-wise average performance in terms of milliseconds. Since the sys admin can modify the process profile and hence the resources consumed by these processes, this was a good working indicator. Next we needed a benchmark value. We decided to develop a fresh one for our installation.

We went by the user’s perception (though it is subjective), since user satisfaction was the ultimate purpose of the IT system. We noted down the instantaneous value of server response time (total = dialog + update) whenever any user telephoned or e-mailed to complain “system is slow.” We collected this data over a period of three months. We also collated the number of complaints and server response on that day.

Since the load on the system varies throughout the day, and furthermore it increases at the beginning or end of the month due to report generation, it was arbitrarily decided to aim for a tolerable range (1,000-1,200) ms.

Fine-tuning the server

By studying the CPU load and memory usage statistics, it was observed that memory usage was peaking at 90-95 percent within one hour of business commencing, and it remained so till about 11.30 am. There was a lull up to 2.30 pm, and usage again peaked between 3.00-4.30 pm.

During this time CPU utilisation was also high (greater than 90 percent). On analysing vide (SM50-process monitor), it was noted that all dialog processes were engaged in query reports, and in many cases the same person was firing identical queries in different sessions.

Since memory usage was very high, to confirm our diagnosis, we temporarily added 512 MB RAM. We found that the response time improved significantly. On a typical day, response time, which was in the 1,200-1,500 ms range, would plummet to 1,000 ms. Hence the need for a memory upgrade was confirmed.

Even after memory upgradation, the response time was not in the comfort zone. We examined the memory allocation between the OS, SAP kernel and RDBMS. We experimented with configuration files of the RDBMS and the SAP application server (using RZ10), and tried out various combinations of memory distribution (40 percent SAP, 30 percent RDBMS, 30 percent OS. Other percentages too—40 - 40 - 20 and 50 - 30 - 20). With more memory, SAP R/3 data entry was facilitated, but reports and updates took more time. Finally we arrived at an optimal ratio of 40 percent, 40 percent and 20 percent (SAP, RDBMS and OS).

Finally, the clincher was process profiling. The three process profiles were Data entry (8 am-11 am), Queries (11 am-6 pm) and Reports (6 pm-8 am) in which the composition of batch, dialog and update processes is slightly tweaked.

The dialog process increased in the 8 am-11 am slot (to help data entry, queries), while the number of batch processes (used for running reports in the background) reduced.

After 6 pm, an additional batch process ran to enable the background processing of reports, and the good old ‘danda’ of system administration was brought to bear. No long reports were permitted in the 8 am-11 am slot except for the daily production report, and no reports were allowed to run through the dialog process.

Long time-consuming reports were optimised using KAIZEN.(see earlier article at www.expresscomputeronline.com/20050228/management03.shtml)

With all of the above being implemented, server performance improved as shown below.

Conclusion: Server response can be improved in an existing set-up with intelligent tinkering.

PS: Having achieved the benchmark figure of less than 1,200 milliseconds, the Proliant 7000 server was upgraded to a HP ML 570G2, memory increased from 1 GB to 4 GB, the Application server and Database server were separated into two separate servers (standard three-tier architecture as recommended by SAP) in August 2004. (Considering the future growth, obsolescence of the server, etc.)