The R/3 System has a three-tier client/server architecture with a presentation layer, an application layer and a database layer. The presentation layer and the application layer are scalable. This means that if there is a hardware bottleneck, you can extend the system by adding more frontends and application servers. The database - as the central data repository - is not scalable in terms of simply adding more databases.
ABAP performance analysis has two main areas of focus. One goal is to reduce the run time of programs on the application server, thereby reducing the CPU load. Another goal is to reduce the database load. Reducing the database load is particularly important since the database is a central resource.
If the required data is located in the R/3 buffers on the application server, accessing this data requires approximately 0.1 milliseconds per data record. If the data records are read from the database buffer, around 1 millisecond is required. When the data is read from the disk, this requires approximately 10 milliseconds per data record.
An R/3 work process allocates around 5 megabytes (MB) of memory. The R/3 table buffers allocate approximately 120 MB (40 MB for single record buffers, 80 MB for generic table buffers). The data buffers of the database use around 500 MB of memory. The database on the disks can reach a size of several terabytes.
Data transfer between frontend and application server occurs in blocks of 2 kilobytes (KB). The transfer between application server and database server occurs in blocks of typically 32 KB.
The database work processes are a service offered by the data management team (DBMS). This service is used by the R/3 work processes. With Oracle, exactly one database work process is assigned to each R/3 work process. There are different database services for different purposes (for example, starting communications, changing database tables, locking mechanism, and archiving).
In addition, the database allocates an area of the shared memory, which contains the data buffer, the DB SQL cache, the redo log information, and so on. The database files are on the hard disk and are usually administered by a file system.
You can measure the performance of a database server by monitoring the physical I/O (read and write access to database files), memory consumption, CPU consumption, and network communication (which is negligible on the central instance). To do this, you can use various tools in the R/3 System (see Unit 5, R/3 System Analysis). The performance of a well configured R/3 System is largely determined by the physical I/O.
RELATED POST
No comments:
Post a Comment