** Credit SAPPRESS http://www.sap-press.de/katalog/buecher/htmlleseproben/gp/htmlprobID-256?GalileoSession=99857992A4.XM0.tnSY#ueberschrift4
RFC server group
You can only prevent this kind of overloading by limiting the number of dialog work processes that the inbound queue scheduler is allowed to occupy. For this purpose, the inbound queue scheduler is assigned to an RFC server group. You create and maintain RFC server groups in Transaction RZ12. Figure shows a CRM system with three RFC server groups. The first group (without a name) is the standard group. This group is always used if there is no explicit assignment to a group. The other two groups, Queue_Scheduler and parallel_generators, were created manually and one instance each was assigned to both groups. In principle, several instances can also be assigned to a group. In such cases, when a user logs on, the instance with the best response times is determined automatically and the user is logged on to this instance.
To create an RFC server group, start Transaction RZ12, and click the New button (Edit N Create assignment menu option). To display the resource assignment of an instance or to change it, double-click the corresponding row. A Change Assignment dialog window appears with the RFC parameter values of the instance.
Figure RFC Server Groups (Transaction RZ12)
Parameters of the RFC server group
The parameters are used as follows:
- Activated (0 or 1) Switch for activating the determination of resources. This should always have the default value 1 (= active).
- Max. Requests in Queue (%) Quote for the number of maximum pending requests in the dialog waiting queue of the dispatcher, which is proportionate to the maximum length of the dispatcher request queue. The default value is 5.
- Max. No. of Logons (%) This value specifies the maximum percentage of logons allowed to this instance by asynchronous RFCs (the total number of logons is contained in the rdisp/tm_max_no parameter). The remaining percentage continues to be reserved for dialog and HTTP users, i.e., if the number of logons exceeds this value, the caller will not be assigned any resources. The default value is 90.
- Maximum No. Separate Logons (%) This value specifies the maximum percentage of logons allowed to this instance by asynchronous RFCs of a user (the total number of logons is contained in the rdisp/tm_max_no parameter). If the number of separate logons exceeds this value, the user is not assigned any further resources. Ideally, this value should not be greater than the Max. No. of Logons (%) parameter. The default value is 25.
- Max. Number of WPs Used (%) Quote for the number of dialog work processes that a user is allowed to use. If the number of dialog work processes used exceeds this value, the caller is not assigned any further dialog work processes. This quote prevents all dialog work processes from being occupied by a user’s RFCs. The default value is 75.
The system doesn’t check the user name, which means that, if a user logs on to the system several times, each logon is viewed as a separate user, even though the user name is the same.
- Minimum Number of Free WPs Quote for the number of dialog work processes that must be reserved for other users. If the number of free dialog work processes is less than the number specified in the quote, the caller is not assigned any dialog work processes. The default value is 1.
The value must always be smaller than the number of dialog work processes (rdisp/wp_no_dia parameter); otherwise, an RFC request cannot be processed.
- Max. No. of Comm. Entries (%) Quote for the maximum number of communication entries of an instance that may be used by parallel RFCs (the total value of the communication entries is contained in the rdisp/max_comm_entries parameter). If the number of entries used exceeds this value, the caller is not assigned any resources. The default value is 90.
- Max. wait time Maximum number in seconds that a work process can “remain in idle mode” if it doesn’t receive any resources after the load on the system has been checked. The actual wait time is determined from the available resources. The fewer resources available, the longer the wait time.
Profile parameters of RFC server group
All settings that you implement in Transaction RZ12 are immediately active, however, they are only saved up until the next time when you restart the instance. After you restart the instance, the settings are lost and the old values are active again. To save the values permanently, you must save them as profile parameters. Table contains the names of the profile parameters for the individual values in Transaction RZ12.
Assigning an RFC server group
You assign the inbound queue scheduler to an RFC server group in Transaction SMQR. You select the menu option Edit N Change AS group and enter the name of the RFC server group.
Figure shows that the Name of AS Group (DEFAULT = All) parameter no longer has the “DEFAULT” value; it now has the “Queue_Scheduler” value instead.
Figure Assigning the RFC Server Group (Transaction SMQR)
Optimum setting for the RFC server group
The optimum setup of RFC server groups depends on the available hardware, volume of data and scenarios used. If you use a pure mobile sales scenario, online or Internet sales users must not be considered when the system is being optimized. In this case, almost all work processes can be made available to the RFC. In all other cases, you must limit the resources for the RFC in such a way that the users will still be able to continue using the system, even if the RFC load is high. If the CRM system has more than one application server, you may find it useful to set up the RFC server groups in such a way that the RFC processing is restricted to the resources of one application server, while the online users use a different application server. By adopting this approach, you can ensure that the users and the RFC will not disturb one another. This holds true especially if data is transferred from the backend, or from/to the mobile clients and the CRM application is used intensively (i.e., both scenarios occur concurrently). The disadvantage of this setup is that the RFC is restricted to one server if the RFC load is high (e.g., if you implement a mass change), even though resources are available on another server (e.g., during the night).
If there is only one application server, it is critical that you optimize the parameters of the RFC server group. The distribution of resources should reflect the actual load distribution — RFC load versus online load — in each case.
To prevent the inbound queue scheduler from using all work processes of the CRM system, you must set the Max. Number of WPs Used (%) and Minimum Number of Free WPsparameters correctly. The Minimum Number of Free WPs parameter determines how many work processes are available for the RFC and the Max. Number of WPs Used (%)parameter specifies how many work processes one RFC user is allowed to use.
If the system has sufficient dialog work processes, the Minimum Number of Free WPs parameter should have the value 3, rather than the default value 1. This ensures that you can still log on to this instance through the SAPGUI, even if the load on the system is very high. This recommendation applies only to a pure mobile sales scenario or a pure RFC instance. In all other cases, the value should be greater, and should also be based on the number of simultaneously active (“concurrent”) online users.
When determining the Max. Number of WPs Used (%) parameter, remember that the RFC is used not only by the inbound queue scheduler, but by other users as well (replication & realignment, outbound queue scheduler, external systems, and especially mobile clients through the DCOM station/.NET Connector). If you select a value that is too high, although the inbound queues will be processed quickly, the data will accumulate in other areas of the CRM Middleware because resources will not be available there. You can only achieve an optimum processing speed if all the system’s components have sufficient resources. We discuss these dependencies in the CRM Middleware in more detail in Chapter 13, Performing Optimized Mass Changes .
Detailed documentation about configuring the system resources for parallel RFCs, tRFCs, and qRFCs is available under SAP NetWeaver in the SAP Help Portal (http://help.sap.com). Click Search Documentation. As Search string, enter “Configuration of System Resources for Parallel RFCs tRFC qRFC”. Choose SAP NetWeaver and the release and language that you want, and click Search.
Analysis transactions
Except for the Message Flow Statistics (Transaction SMWMFLOW) and the Middleware Trace (Transaction SMWT), which we’ll discuss in further detail, the analysis transactions are “standard” (i.e., not CRM-specific transactions that are found in every SAP system). Detailed descriptions about these transactions and the most suitable way that you can use them are already available; therefore, we don’t want to repeat them here. [We recommend that you refer to the book, SAP Performance Optimization Guide: Analyzing and Tuning SAP Systems, by Thomas Schneider, published by SAP PRESS (4th edition, 2005). ]
However, we would like to point out how the performance analysis of CRM Middleware differs from the performance analysis in other SAP systems. The user who executes a transaction often acts as a filter for the performance analysis, in order to find the correct statistical data records or trace a particular action in the system. The “user” is not always identified very easily in CRM Middleware. For example, you will only be able to clearly establish which user is processing an inbound queue if a logical destination has been maintained. Otherwise, the queue processing is performed under the user ID that is currently processing a registered queue (this does not have to be the same queue).
Therefore, a queue entry is not necessarily processed further by the user ID that has written it into the queue; instead, it can be processed using a different user ID. If both of these users have different rights, a user with insufficient rights may try to process the queue entries of another user. The resulting errors are very difficult to analyze because, generally, they rarely occur and can seldom be reproduced
Parallel Processing of Jobs with Asynchronous RFC
For some R/3 reports, the nights are getting too short. Especially at customers with large volumes of data, some R/3 reports that customarily run in the background processing system (such as material planning runs) have run times of many hours. It can be difficult to finish such jobs runs in the "night-time" that is available, especially if dialog users are spread across several time zones.
With Release 3.1, R/3 offers a solution to the "short nights" problem: parallel-processed background jobs. Long-running R/3 reports can now implement parallel processing, which lets themABAP parcel out the work to be done to available work processes in the R/3 System and then collect and synchronize the results.
In parallel processing, a job step is started as usual in a background processing work process. If the program that runs in the job step is so programmed, it can use a special variant of asynchronous RFC to have portions of the data that is to be processed run in parallel in other work processes. You can recognize such a program because it uses the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP instruction to start the function modules that process the data.
While the job itself runs in a background process, the parallel processing tasks that it starts run in dialog work processes. Such dialog work processes may be located in any of the servers of your R/3 System.
Parallel processing has been implemented in some R/3 applications that have long-running reports. Check the application documentation for information on such reports. The parallel processing interface is also available to customers.
Automatic Protection Against Resource Overuse
The asynchronous remote function call (RFC) system contains built-in safeguards against the possibility that a parallel processing job may take too many resources and affect the overall performance of your R/3 System.
A parallel-processed job may use the dialog work processes of an R/3 server only if the following are true:
- The server in question has at least three free dialog work processes. This restriction means that at least two dialog work processes remain free for other work in any server that is used by a parallel processing job. The job can start a task in a dialog work process only if two other dialog work processes are currently free in the application server in question.
- The dispatching queue of the server in question is less than 10 percent full. This restriction prevents a parallel processing job from using a server that is already quite busy.
Performance testing at SAP suggests that the built-in safeguards allow significantly faster execution of background jobs without unduly affecting R/3 System performance as a whole. However, if parallel-processed jobs may compete for the same resources, or if parallel-processed jobs may share the R/3 System with time-critical applications or a full complement of interactive users, then we recommend that you use RFC groups to control which resources a parallel-processed job uses.
Managing Resources with RFC Groups
By default, the "group" of servers eligible for use for parallel processing is all qualifiying servers in your R/3 System. However, you can use the "group" specification in a parallel-processing program to control precisely which resources may be used by a parallel processing job.
A group specifies the set of R/3 application servers that can be used for executing a particular job in parallel. The "default" group (CALL FUNCTION STARTING NEW TASK with the argument DESTINATION IN GROUP DEFAULT), is all qualifying servers. But you can also create your own more limited groups. You can view and maintain groups with transaction RZ12 (Tools ® Administration ® Administration ® Network ® RFC destinations and then RFC ® RFC groups).
Monitoring
At this time, parallel processing jobs are not specially marked in the tools for monitoring background processing. However, a monitoring capability is expected to be added in coming releases of the R/3 System.
RFC server group
You can only prevent this kind of overloading by limiting the number of dialog work processes that the inbound queue scheduler is allowed to occupy. For this purpose, the inbound queue scheduler is assigned to an RFC server group. You create and maintain RFC server groups in Transaction RZ12. Figure shows a CRM system with three RFC server groups. The first group (without a name) is the standard group. This group is always used if there is no explicit assignment to a group. The other two groups, Queue_Scheduler and parallel_generators, were created manually and one instance each was assigned to both groups. In principle, several instances can also be assigned to a group. In such cases, when a user logs on, the instance with the best response times is determined automatically and the user is logged on to this instance. To create an RFC server group, start Transaction RZ12, and click the New button (Edit N Create assignment menu option). To display the resource assignment of an instance or to change it, double-click the corresponding row. A Change Assignment dialog window appears with the RFC parameter values of the instance.
Figure RFC Server Groups (Transaction RZ12)
Parameters of the RFC server group
The parameters are used as follows:
- Activated (0 or 1) Switch for activating the determination of resources. This should always have the default value 1 (= active).
- Max. Requests in Queue (%) Quote for the number of maximum pending requests in the dialog waiting queue of the dispatcher, which is proportionate to the maximum length of the dispatcher request queue. The default value is 5.
- Max. No. of Logons (%) This value specifies the maximum percentage of logons allowed to this instance by asynchronous RFCs (the total number of logons is contained in the rdisp/tm_max_no parameter). The remaining percentage continues to be reserved for dialog and HTTP users, i.e., if the number of logons exceeds this value, the caller will not be assigned any resources. The default value is 90.
- Maximum No. Separate Logons (%) This value specifies the maximum percentage of logons allowed to this instance by asynchronous RFCs of a user (the total number of logons is contained in the rdisp/tm_max_no parameter). If the number of separate logons exceeds this value, the user is not assigned any further resources. Ideally, this value should not be greater than the Max. No. of Logons (%) parameter. The default value is 25.
- Max. Number of WPs Used (%) Quote for the number of dialog work processes that a user is allowed to use. If the number of dialog work processes used exceeds this value, the caller is not assigned any further dialog work processes. This quote prevents all dialog work processes from being occupied by a user’s RFCs. The default value is 75.
The system doesn’t check the user name, which means that, if a user logs on to the system several times, each logon is viewed as a separate user, even though the user name is the same.
- Minimum Number of Free WPs Quote for the number of dialog work processes that must be reserved for other users. If the number of free dialog work processes is less than the number specified in the quote, the caller is not assigned any dialog work processes. The default value is 1.
The value must always be smaller than the number of dialog work processes (rdisp/wp_no_dia parameter); otherwise, an RFC request cannot be processed.
- Max. No. of Comm. Entries (%) Quote for the maximum number of communication entries of an instance that may be used by parallel RFCs (the total value of the communication entries is contained in the rdisp/max_comm_entries parameter). If the number of entries used exceeds this value, the caller is not assigned any resources. The default value is 90.
- Max. wait time Maximum number in seconds that a work process can “remain in idle mode” if it doesn’t receive any resources after the load on the system has been checked. The actual wait time is determined from the available resources. The fewer resources available, the longer the wait time.
Profile parameters of RFC server group
All settings that you implement in Transaction RZ12 are immediately active, however, they are only saved up until the next time when you restart the instance. After you restart the instance, the settings are lost and the old values are active again. To save the values permanently, you must save them as profile parameters. Table contains the names of the profile parameters for the individual values in Transaction RZ12.
| Table Names of Profile Parameters RZ12 | Profile Pparameters |
| Activated (0 or 1) | rdisp/rfc_use_quotas |
| Max. Requests in Queue (%) | rdisp/rfc_max_queue |
| Max. No. of Logons (%) | rdisp/rfc_max_login |
| Maximum No. of Separate Logons (%) | rdisp/rfc_max_own_login |
| Max. Number of WPs Used (%) | rdisp/rfc_max_own_used_wp |
| Minimum Number of Free WPs | rdisp/rfc_min_wait_dia_wp |
| Max. No. of Comm. Entries (%) | rdisp/rfc_max_comm_entries |
| Max. wait time | rdisp/rfc_max_wait_time |
Assigning an RFC server group
You assign the inbound queue scheduler to an RFC server group in Transaction SMQR. You select the menu option Edit N Change AS group and enter the name of the RFC server group.
Figure shows that the Name of AS Group (DEFAULT = All) parameter no longer has the “DEFAULT” value; it now has the “Queue_Scheduler” value instead.
Figure Assigning the RFC Server Group (Transaction SMQR)
Optimum setting for the RFC server group
The optimum setup of RFC server groups depends on the available hardware, volume of data and scenarios used. If you use a pure mobile sales scenario, online or Internet sales users must not be considered when the system is being optimized. In this case, almost all work processes can be made available to the RFC. In all other cases, you must limit the resources for the RFC in such a way that the users will still be able to continue using the system, even if the RFC load is high. If the CRM system has more than one application server, you may find it useful to set up the RFC server groups in such a way that the RFC processing is restricted to the resources of one application server, while the online users use a different application server. By adopting this approach, you can ensure that the users and the RFC will not disturb one another. This holds true especially if data is transferred from the backend, or from/to the mobile clients and the CRM application is used intensively (i.e., both scenarios occur concurrently). The disadvantage of this setup is that the RFC is restricted to one server if the RFC load is high (e.g., if you implement a mass change), even though resources are available on another server (e.g., during the night).
If there is only one application server, it is critical that you optimize the parameters of the RFC server group. The distribution of resources should reflect the actual load distribution — RFC load versus online load — in each case.
To prevent the inbound queue scheduler from using all work processes of the CRM system, you must set the Max. Number of WPs Used (%) and Minimum Number of Free WPsparameters correctly. The Minimum Number of Free WPs parameter determines how many work processes are available for the RFC and the Max. Number of WPs Used (%)parameter specifies how many work processes one RFC user is allowed to use.
If the system has sufficient dialog work processes, the Minimum Number of Free WPs parameter should have the value 3, rather than the default value 1. This ensures that you can still log on to this instance through the SAPGUI, even if the load on the system is very high. This recommendation applies only to a pure mobile sales scenario or a pure RFC instance. In all other cases, the value should be greater, and should also be based on the number of simultaneously active (“concurrent”) online users.
When determining the Max. Number of WPs Used (%) parameter, remember that the RFC is used not only by the inbound queue scheduler, but by other users as well (replication & realignment, outbound queue scheduler, external systems, and especially mobile clients through the DCOM station/.NET Connector). If you select a value that is too high, although the inbound queues will be processed quickly, the data will accumulate in other areas of the CRM Middleware because resources will not be available there. You can only achieve an optimum processing speed if all the system’s components have sufficient resources. We discuss these dependencies in the CRM Middleware in more detail in Chapter 13, Performing Optimized Mass Changes .
Detailed documentation about configuring the system resources for parallel RFCs, tRFCs, and qRFCs is available under SAP NetWeaver in the SAP Help Portal (http://help.sap.com). Click Search Documentation. As Search string, enter “Configuration of System Resources for Parallel RFCs tRFC qRFC”. Choose SAP NetWeaver and the release and language that you want, and click Search.
Performance Analysis for Processing Single Records
SAP provides an entire range of statistical information and trace options for a performance analysis. Some of these are listed in Table| Table Performance Analysis Transactions Transaction | Description |
| ST03N | Workload Monitor |
| STAD | Statistical Records |
| ST12 | Single Transaction Trace |
| SE30 | Runtime Analysis (ABAP Trace) |
| ST04 | Database Performance Analysis |
| DB02 | Database Performance: Tables and Indices |
| ST10 | Table Call Statistics |
| ST05 | Performance Analysis (SQL Trace) |
| SQLR | SQL Trace Interpreter |
| SMWMFLOW | Message Flow Statistics |
| SMWT | Middleware Trace |
Except for the Message Flow Statistics (Transaction SMWMFLOW) and the Middleware Trace (Transaction SMWT), which we’ll discuss in further detail, the analysis transactions are “standard” (i.e., not CRM-specific transactions that are found in every SAP system). Detailed descriptions about these transactions and the most suitable way that you can use them are already available; therefore, we don’t want to repeat them here. [We recommend that you refer to the book, SAP Performance Optimization Guide: Analyzing and Tuning SAP Systems, by Thomas Schneider, published by SAP PRESS (4th edition, 2005). ]
However, we would like to point out how the performance analysis of CRM Middleware differs from the performance analysis in other SAP systems. The user who executes a transaction often acts as a filter for the performance analysis, in order to find the correct statistical data records or trace a particular action in the system. The “user” is not always identified very easily in CRM Middleware. For example, you will only be able to clearly establish which user is processing an inbound queue if a logical destination has been maintained. Otherwise, the queue processing is performed under the user ID that is currently processing a registered queue (this does not have to be the same queue).
Therefore, a queue entry is not necessarily processed further by the user ID that has written it into the queue; instead, it can be processed using a different user ID. If both of these users have different rights, a user with insufficient rights may try to process the queue entries of another user. The resulting errors are very difficult to analyze because, generally, they rarely occur and can seldom be reproduced
Parallel Processing of Jobs with Asynchronous RFC
For some R/3 reports, the nights are getting too short. Especially at customers with large volumes of data, some R/3 reports that customarily run in the background processing system (such as material planning runs) have run times of many hours. It can be difficult to finish such jobs runs in the "night-time" that is available, especially if dialog users are spread across several time zones.
With Release 3.1, R/3 offers a solution to the "short nights" problem: parallel-processed background jobs. Long-running R/3 reports can now implement parallel processing, which lets themABAP parcel out the work to be done to available work processes in the R/3 System and then collect and synchronize the results.
In parallel processing, a job step is started as usual in a background processing work process. If the program that runs in the job step is so programmed, it can use a special variant of asynchronous RFC to have portions of the data that is to be processed run in parallel in other work processes. You can recognize such a program because it uses the CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP instruction to start the function modules that process the data.
While the job itself runs in a background process, the parallel processing tasks that it starts run in dialog work processes. Such dialog work processes may be located in any of the servers of your R/3 System.
Parallel processing has been implemented in some R/3 applications that have long-running reports. Check the application documentation for information on such reports. The parallel processing interface is also available to customers.
Automatic Protection Against Resource Overuse
The asynchronous remote function call (RFC) system contains built-in safeguards against the possibility that a parallel processing job may take too many resources and affect the overall performance of your R/3 System.
A parallel-processed job may use the dialog work processes of an R/3 server only if the following are true:
- The server in question has at least three free dialog work processes. This restriction means that at least two dialog work processes remain free for other work in any server that is used by a parallel processing job. The job can start a task in a dialog work process only if two other dialog work processes are currently free in the application server in question.
- The dispatching queue of the server in question is less than 10 percent full. This restriction prevents a parallel processing job from using a server that is already quite busy.
Performance testing at SAP suggests that the built-in safeguards allow significantly faster execution of background jobs without unduly affecting R/3 System performance as a whole. However, if parallel-processed jobs may compete for the same resources, or if parallel-processed jobs may share the R/3 System with time-critical applications or a full complement of interactive users, then we recommend that you use RFC groups to control which resources a parallel-processed job uses.
Managing Resources with RFC Groups
By default, the "group" of servers eligible for use for parallel processing is all qualifiying servers in your R/3 System. However, you can use the "group" specification in a parallel-processing program to control precisely which resources may be used by a parallel processing job.
A group specifies the set of R/3 application servers that can be used for executing a particular job in parallel. The "default" group (CALL FUNCTION STARTING NEW TASK with the argument DESTINATION IN GROUP DEFAULT), is all qualifying servers. But you can also create your own more limited groups. You can view and maintain groups with transaction RZ12 (Tools ® Administration ® Administration ® Network ® RFC destinations and then RFC ® RFC groups).
Monitoring
At this time, parallel processing jobs are not specially marked in the tools for monitoring background processing. However, a monitoring capability is expected to be added in coming releases of the R/3 System.
3 comments:
Wow Very nice Blog Post! Your site has given the best information. This is excellent information. It is amazing and wonderful to visit your site. If you are looking for Unity 3d training institute in Hyderabad
Hey,
I noticed your Article. I just loved it.
Experience one of the finest Unity 3d training in Hyderabad. Take your carrier to next level.
If you like it feel free and share it.
Cheers,
Varsha.
I’m not that much of a internet reader to be honest but your blogs really nice, keep it up! I’ll go ahead and bookmark your website to come back down the roadsap training institutes in hyderabad
Post a Comment