Skip to Content
author's profile photo Former Member
Former Member

How to take the max advantage of ST03 transaction.

Hi friends,

How to use the T code ST03 in an efficient manner to tune the response time, and Performance Isuue. we have identified some tables that are getting max hits and sequential reading. And moreover DBtime of BackgroundProcesses is > 90 % of the Response time.

how to identify the max respose time taking transactions / reports / progr.s

how to tune this situation....

can any body help me in this ...

Thank u.

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Dec 04, 2007 at 02:24 PM


    i am sending a doccument i hope that it will be helpfull to you.

    System statistics are written to the R/3 kernel and can be displayed using the workload monitor (Transaction ST03N). They provide system administrators with varied and detailed information on CPU time, numbers of database changes, roll out times and so on.

    The table below defines the most important workload statistics:

    - Average CPU time

    - Average CPU time used in the work process.

    During a dialog step, the CPU of the application server is used for processing (loading, generating, database request processing, ABAP processing and so on). The CPU time is determined by the operating system. At the end of a transaction step, the R/3 work process queries the CPU time from the operating system. The CPU time is therefore not an additive component of the response time, unlike the wait, roll-in, load and database time.

    Average response time - The average response time of a dialog step is the average time measured from the time a dialog sends a request to the dispatcher work process through the processing of the dialog up to the time the dialog is completed and the data is passed to the presentation layer. The response time between the SAP GUI and the dispatcher is not included in this value.

    The response time does NOT include the time taken to transfer data from the R/3 frontend to the application server. For networks with low performance, this can create a highly subjective response time. The transfer time is contained in the GUI network time.

    Response time is usually split into wait time plus dispatch time. The SAP response time is composed of the following components:

    - Response time = wait time + dispatched time

    - Dispatched time = Generation time during runtime

    - Load time for programs, screens and CUA interfaces

    - Roll times to roll-in work data

    - ABAP processing time

    - Database time

    - Enqueue time for logical SAP lock procedures

    - CPIC/RFC time

    - Roll wait time (apart from task types RFC/CPIC/ALE).

    The CPU time is not an additive component of the response time, but the sum of the CPU time that is used by the individual components. The CPU time therefore provides additional, independent information on the response time.

    Average wait time - The time an unprocessed dialog step waits in the dispatcher queue for a free work process. Under normal conditions, the dispatcher work process should pass a dialog step to the application process immediately after receiving the request from the dialog step. Under these conditions, the average wait time would be a few milliseconds. A heavy load on the application server or on the entire system causes queues at the dispatcher queue.

    Average load time - The time needed to load and generate objects such as ABAP source code and screen information from the database.

    Database calls - The number of parsed requests sent to the database.

    Database requests - The number of logical ABAP requests for data in the database. These requests are passed through the R/3 database interface and parsed into individual database calls. The proportion of database calls to database requests is important. If access to information in a table is buffered in the SAP buffers, database calls to the database server are not required. Therefore, the ratio of calls/requests gives an overall indication of the efficiency of table buffering. A good ratio would be 1:10.

    GUI time - The GUI time is measured in the work process and is the response time between the dispatcher and the GUI.

    Roll ins - Number of rolled-in user contexts.

    Roll outs - Number of rolled-out user contexts.

    Roll in time - Processing time for roll ins.

    Roll out time - Processing time for roll outs.

    Roll wait time - Queue time in the roll area. When synchronous RFCs are called, the work process executes a roll out and may have to wait for the end of the RFC in the roll area, even if the dialog step is not yet completed. In the roll area, RFC server programs can also wait for other RFCs sent to them.

    Average time per logical DB call - Average response time for all commands sent to the database system (in milliseconds). The time depends on the CPU capacity of the database server, network, buffering, and on the input/output capabilities of the database server. Access times for buffered tables are many magnitudes faster and are not considered in the measurement.

    The following times give you an overview of optimal response times in your SAP System. Use the workload monitor to display the current workload statistics in your system.

    Performance Data Time

    - Average response time - approx. 1 second (dialog), <1 second (update)

    - Average CPU time - approx. 40% of average response time

    - Average wait time - <1% of average response time

    - Average load time - <10% of average response time

    - Average DB request time - approx. 40% of average response time

    Database Requests Time

    - Direct reads - <10 ms

    - Sequential reads - <40 ms

    - Changes - >25 ms

    High Values for Reason

    - DB req. (Change/Comm.)

    - Database or index problems?

    - Load time

    - Buffer problems?

    - Wait time

    - Not enough work processes?

    - Locked tasks?

    - Long-running transactions?

    The times for direct reads and changes should not exceed 10 milliseconds in a healthy database system. The sequential reads time should not exceed 30-40 milliseconds.

    You can use the workload monitor (Transaction ST03N) to analyze the workload statistics for each task type (for example for background processing, dialog processing, update processing, ALE, and RFC) for the application servers in your SAP System.

    You can use the workload monitor to display and compare the time profiles. A time profile displays the workload for a specific task type over a specific period of time.

    You can display the workload of the instances that are configured in your SAP System, not just the instance that you have logged on to. You can also switch easily between the information for these instances.

    You can display and analyze the time profile for one individual task type, or for all task types. You can display the workload for the following parameters:

    - Times

    - Database

    - Proportion of response time

    - GUI times

    - All data.

    You can use the workload monitor to display the number of users working on an application server. You can display the number of dialog steps that each user has executed, and check that application server response times are acceptable.




    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.