Note:Update dispatching as described here is the standard solution for all applications. Only in special cases and on the express recommendation of SAP should you use the methods local updates or update multiplexing. These methods are not explained in this book.
Update Tables VBMOD, VBHDR, and VBDATA
The update tables VBMOD, VBHDR, and VBDATA are among the most frequently changed tables in the R/3 System.
If bottlenecks arise when accessing these tables on the hard disk, it may be useful to perform partitioning—that is, to distribute these tables over several hard disks.
For some database systems, it may be useful to change the sequence of the key fields in these tables. However, this should be performed only by people with experience in tuning the database and R/3, or following the specific instructions of SAP.
See the R/3 Online Documentation and R/3 Notes relating to the R/3 profile parameter rdisp/vb_key_comp.
Multiple R/3 Instances per Server
For UNIX servers with more than four CPUs and 2GB of main memory, there are several good reasons why you should set up more than one R/3 instance on each server:
• Experience shows that performance bottlenecks may arise on servers with more than four processors, but only one R/3 instance with a large number of work processes.
These bottlenecks particularly affect the dispatcher, roll in and roll out, and buffer management.
• The physical main memory cannot be used optimally due to operating-system limits affecting address space, global memory, and so on. For details, see Chapter 5,
“Configuring R/3 Memory Areas.”
• In R/3 Release 3.x, it was common to set up additional instances, because only one spool work process could be set up on each R/3 instance. This is no longer necessary with R/3 Release 4.x.
As a rule of thumb, however, you should avoid setting up more instances than are strictly necessary, since with each additional instance, you increase the amount of required administrative and monitoring work.
Summary
The most important means of optimizing workload distribution in an R/3 System is to properly set up R/3 work processes. The number of work processes to be set up depends on the demands placed on the R/3 System and on the available CPU resources. Is the system to be used mainly for OLTP (online transaction processing) applications or for OLAP (online analytical processing) applications? Will there be more dialog processing or more background processing?
When configuring the number and type of work processes, use the following guidelines:
• Around 10% to 30% of the CPU needs of the entire R/3 System are consumed by the database service. Ensure that any R/3 instances that reside on the database server do not consume too much CPU capacity. Too many R/3 work processes on the database server can cause a CPU bottleneck that in turn leads to increased database times, and thus inconveniences all users.
• Around 10% to 20% of the CPU needs and also 10% to 20% of the R/3 work processes of the entire R/3 System are typically consumed by the R/3 update service.
The following guidelines should be observed when distributing the work processes on the instances:
• The message, enqueue, and ATP services should be on one R/3 instance (known as the central R/3 instance), which should have at least five dialog work processes. For small- and medium-sized installations, this central R/3 instance is located on the database server. For large installations, the central instance may require a dedicated application server.
• The dialog, background, update, and spool work processes should be evenly distributed across the remaining application servers in a symmetrical manner (equal numbers and types of each work process on each R/3 instance). The work process configuration should be appropriate for the CPU capacity of each instance. If you configure an update service on one R/3 instance, at least two update work processes should be configured there.
Additional techniques for R/3 System load management include:
•
Central update servers and dedicated background servers
•
Logon groups for dynamic user distribution
•
Local updates and update multiplexing (these are not discussed in this book) Note that these additional techniques increase administration and monitoring effort.
Aside from these techniques, the general rule is to configure the work processes in the R/3 System as symmetrically as possible and as asymmetrically as necessary.
Symmetrical distribution in this context means having equal numbers of each type of work process on each R/3 instance.
There is no hard rule as to how many R/3 work processes should be configured per processor. A guideline value is around 5 to 10 work processes per processor. R/3 administrators and consultants sometimes make the error of automatically increasing the numbers of work processes, regardless of the type of performance problem. This rarely leads to a performance improvement—in some cases, it even reduces performance.
Important Terms in This Chapter
After reading this chapter, you should be familiar with the following terms:
•
Workload distribution
•
Logon groups
•
Distributed update
Review Questions
1.
Where should background work processes be configured?
A.Background work processes should always be located on the database server.
Otherwise, the runtime of background programs will be negatively affected by network problems between the database server and the application server.
B.If background work processes are not located on the database server, they must all be set up on a dedicated application server known as the background server.
C.Background work processes can be distributed evenly over all the application servers.
2.
How should you configure and monitor the dynamic user distribution?
A.
By setting the appropriate R/3 profile parameter—for example, rdisp/wp_no_dia.
B.
By using Transaction SM04, User Overview.
C.By using Transaction SMLG, Maintain Logon Groups.
Chapter 7: R/3 Table Buffering
Overview
Every R/3 instance has various buffers, including table buffers, in which data is stored that is needed by users at runtime. When the data is in the buffer, it does not have to be obtained from the database, because buffers enable direct reads from the main memory of the application server. There are two advantages in accessing a buffer for data rather than accessing the database:
• Buffer accesses are normally between 10 and 100 times faster than accesses to the database.
• Database load is reduced, a fact that becomes increasingly important as your system grows in size.
For each table defined in the ABAP Dictionary, you can decide whether and how the table will be buffered. To enable the buffering of these tables, each R/3 instance has two table buffers: the single record table buffer (TABLP) and the generic table buffer (TABL).
When your R/3 System is delivered, all tables already have default buffering settings.
However, to optimize runtime performance, you may need to change some of these settings depending on the usage of your R/3 System. For customer-created tables, the responsible developer configures the buffering settings.
When Should You Read This Chapter?
You should read this chapter to help you:
•
Learn about table buffering options in R/3.
•
Monitor and optimize the efficiency of your buffering of R/3 tables at regular intervals.
•
Decide whether to buffer customer-created database tables.
• Decide whether to buffer the condition tables created during Customizing for central SAP functions such as price determination or output determination.
To better understand this chapter, you should have some familiarity with ABAP programming and SQL programming.