SAP R3 Buffer

Buffer Analysis:
Buffers are used to store the frequently accessed and rarely modified data based on parameter settings in RZ10
and table technical settings in SE13. Buffers reside in memory and completely lost when the instance is restarted.
Buffers contain screens, menus, programs, tables, common user attributes, calendar, table field and table definitions etc…
The buffers are organized in the memory in the form of directories.
Each directory consumes space, so buffers are organized by number of directories and space in KB
Buffer Mechanism:
1. User submits the request.
2. The request goes to the database and fetches the content into application server.
3. The content is checked for its eligibility to store in buffer (RZ10/SE13),
if it is eligible to store then it occupies directory along with some space,
if a relative directory is available then uses the same directory with some space (memory).
4. If the directories are not sufficient the directory overflow occurs and directories are swapped out along with content.
5. If sufficient directories are available and if space is not sufficient then the buffer entries are swapped out and marked in RED in ST02.
SWAP: The content is swapped if there are no free directories or space based on LRU (Least Recently Used content)
. I.e. the content which is older and not accessed (based on time stamp) will be swapped out. Buffer swaps are recorded in ST02. The buffer hit ratio of R3buffer should be more than 98%.
ST02 analysis:
It displays following:
1. Buffer content name, Buffer Hit Ratio (BFHR), allocated space, free space%, allocated directories, free directories, free directories %, swaps, and database access. Click on parameters to display the parameters.
2. The parameter abap/buffer_size is used to configure the size for abap programs which can be configured up to max of 1500MB (1.5 GB). It is initially set to 300MB (default is 150MB).
Click on Detailed analysis menu >click on buffering criteria >to display the parameters and buffered objects.
Buffer Hit Ratio = (Number of buffer hits / Total no of requests) * 100%
Table Buffering:
The SAP tables and their content are buffered in R3 buffer based on table technical settings in SE13. By default the following options are provided in SE13.
1. No Buffering:
The tables which are large, frequently updated, transactional data tables are not eligible for buffering (buffering is not allowed).
2. Buffering allowed:
Full buffering: The tables which are small, frequently accessed, around 30kb in size and very rarely changed (modified) are eligible for full (100%) buffering.
Ex: T000, TACT tables
Single record buffering: The tables which are relatively large, frequently accessed should be between 100 to 200 kb in size, and very rarely modified is buffered based on single key.
Ex: Table USR02 and key is username (BNAME)
Generic record buffering: The tables which are large and more frequently accessed and less frequently changed are eligible to buffer based on certain columns or fields. Ex: T001
3. Buffering allowed but switched off:
The table buffering is allowed for these tables but it is switched off in DEV&QAS for technical reasons, which can be enabled by the customer in SE13.
Note: Do not change SAP settings, which will impact your buffer performance.
Buffer synchronization:
Buffering:

1. It improves the response time of the instance by caching the frequently accessed
   content.
2. When more than one application server (instance) is configured, then the buffering between the instances need to be synchronized, else it is possible to get different responses from the instances.
3. The parameter rdisp/bufreftime = 60sec defines the frequency at which the buffers are synchronized (refreshed) between instances.
4. The parameter rdisp/bufrefmode = sendon, exeauto is used to set the buffer synchronize
   mode.
5. The default is “sendon”, “exeauto” means that the buffer synchronization is activated.
6. “sendon” means that changes to buffered objects are logged in the table DDLOG.
7. “exeauto” means that the local buffer is brought up to the newest state by cyclical processing of the new DDLOG records.
8. “sendoff”, “exeoff” deactivates the buffer synchronization.

Recommendations for buffer:
>Do not consider the initial response times of the system and ensure that there are at least 20000 hits before considering the transaction is expensive.
Example: A transaction is executed in 10 min for the first time (10*60sec) of the first hit is to database it consumes more time and the subsequent hits will be below 1sec and some times it is few milliseconds.
The same transaction is executed for 20,000 times with an average response time of 300 milliseconds i.e. ,
it took 600000 milliseconds for first step and next 20,000 dialog steps consumed 60,00,000 milliseconds.
The total time taken for 20001 dialog steps is 6,00,000+60,00,000=66,00,000. The average response time comes to 330ms
(additional 30milliseconds is coming from first request).
Check the buffer swaps, If they are too high then consider increasing the parameters based on recommendations by SAP (For 32/64 bit and OS).
If the swaps are more, than we can consider the following.
1. Support packages are applied and SGEN is not run (Run transaction SGEN to compile programs).
2. System is restarted.
3. Add on applied/support packages are applied and SGEN is not run.( Run transaction SGEN to compile programs).
4. Users increased due to a new module implementation.
5. Users are routed to this instance due to failure of other instance.
6. New developments or customizing and subsequent transports are imported. (Buffers get invalidated and reloaded into buffer when it accessed again).
7. The buffer space or directories are not sufficient for programs and tables. Conceder the threshold values in RZ10 before making changes to the parameter values. If required deploy more instances and configure load balancing.