In the first weblog BSP Performance: Measuring Roundtrip Latency, we look at a technique to measure the HTTP roundtrip latency from the browser to the server and back again. We saw that in some cases the actual network latency itself can be relatively large (especially when working from home!) and that these numbers do not reflect the actualtime the server is involved.
The actual processing time of the server is important to get a better estimate of the true load that the server can handle. For this weblog, we will use statistic records to get a true feeling of the processing time of one HTTP request on the server.
Activating Statistic Records
Statistic records are by default not enabled for HTTP access to the R/3 system. They can either be enabled with the profile parameter rdisp/no_statistic or with the ABAP program RSSTATISTIC (see transaction SE38).
After statistic records have been enabled, execute a few test BSP pages. Important: the BSP pages must be on the application server where the statistic records have been activated. Again execute the tests a number of times to first have a warm-up phase.
Looking at the Data
To see the statistic records, use the ABAP program RSSTAT20 (see transaction SE38). Set time filter around time of test, limit to program SAPMHTTP and user name used in the tests. It is very important to increase the number of records searched.
When the program is started, a list of statistic records according to the filter criteria is shown. Already one can see that the first hit takes much longer than the following hits on the same page. For the first run, the ABAP load for the BSP page has to be fetched from the database and loaded into the program execution buffer. This hit includes a large database overhead. All subsequent hits on the same test page have no database overhead.
Looking at these records, we see that each page hit took 17ms of server time. This is inline with our measurements of HTTP roundtrip latency of 23ms when in the office.
The statistic records reflect the complete ABAP runtime, but do not include the ICM time (part of kernel) for processing the incoming request or the outgoing response (in ICM). This additional time will explain a difference of a few milliseconds between the static records (ABAP runtime) and the HTTP roundtrip latency. The remaining time difference must be attributed to network latency and inaccuracies in the complete process.
This weblog has added one more tool to the performance toolbox. This is important both in verifying the HTTP roundtrip latency measurements made previously, and understanding true server workload versus network latency.
Again, as a first step one must compute baseline numbers for the BSP runtime and a Hello World page for the specific environment (serve configuration and network capabilities). Once these numbers stand, repeat the measurements for the real application.