3794579 - Performance optimization of Run Revenue Recognition application

This article, which is primarily intended for business users, focuses on performance aspects. It takes a deep dive into best practices, so that the user can thoroughly plan and schedule recurring Event Based Revenue Recognition activities to fit their business needs.

It provides general guidance on how to leverage various options with regards to system resources utilization. Further details for technical users can be found in KBA 2980435 - Performance optimization of Run Revenue Recognition application - technical details.

The topic of parallel processing discussed below might sound too technical. You do not need to understand the technical details to use it effectively, but knowing a few key settings will help you to get the best results.

Let us briefly introduce Application Jobs - a system framework that allows for scheduling, processing and monitoring long-running activities. These activities are usually recurring. Find more details here: Application Jobs.

Application Jobs apps are designed to support large data volume processing.

This is also the case for Run Revenue Recognition apps in Event Based Revenue Recognition area (for Projects, Sales Orders, Service Documents etc.), which are implemented as application jobs. Run Revenue Recognition apps are further referred to as EBRR Jobs.

Parallel processing

EBRR Jobs internally leverage the SHDB Parallelization Framework (PFW). Leveraging PFW allows for internal splitting of the data volume into smaller packages. Those packages are then internally processed in parallel. This reduces the overall runtime of EBRR Jobs.

A running SAP system can be considered a set of valuable assets called System resources (CPU, memory, storage, running system processes of different types, etc.). Those assets are shared by all users logged on to the system at any moment. Therefore, the common goal is to consume them in the most effective way.

The resource we need to focus on here is 'running system processes of different types', or simply 'processes'. The use of PFW makes EBRR Jobs somewhat special compared to ordinary Application Jobs apps:

• Ordinary Application Jobs apps usually consume only non-critical processes
• EBRR Jobs consume also critical processes on top of non-critical ones, due to PFW usage

Remark: Whether the process is considered critical or not depends on its purpose. If the purpose of the process (defined by the process type) is to serve the requests of interactive users, it is considered critical, as maintaining satisfactory response times for interactive users is essential. We will refer to critical processes simply as Processes below. The non-critical processes are out of scope here.

Since EBRR Jobs compete for the same resource (Processes) as interactive users, special attention is needed when EBRR Jobs are scheduled.

Remark: There can be also other Application Jobs from other areas, leveraging PFW and therefore adding up to the consumption of Processes.

To support parallel processing in EBRR Jobs, there are two extra parameters available on top of general selection parameters:

• Parallel Processing
• Max. Number of Parallel Tasks
  
  

Parallel Processing:

• OFF: Parallel processing does not take place

• ON (together with Max. Number of Parallel Tasks: 2-5): Parallel processing may take place

  • If the data set (determined based on selection criteria) does not qualify for parallel processing due to the small number of items to be processed, the parallel processing does not take place even if switched ON and if the number of required parallel tasks was specified. This evaluation is performed internally by the program and cannot be affected by the user.

  • In other cases, parallel processing takes place, using up to specified number of max parallel tasks. In runtime, 1 parallel task equals 1 Process.

  • As mentioned earlier, EBRR Jobs and processing of interactive user requests compete for the same valuable system asset: the Processes. When it comes to Process assignment, the interactive user requests (high-prio) are prioritised over EBRR Jobs requests (low-prio).

  • On top of that, system measures are in place to safeguard availability of Processes for processing high-prio requests: only a certain amount of all Processes can be used by low-prio requests, including EBRR Jobs. This quota is part of system configuration and cannot be changed by the user.

  • For the total number of Processes and for the value of quota configured in your system, reach out to your system administrator.

• Example setup:

  • Let us consider a system with 100 Processes and quota of 70%. The low-prio requests could then use up to 70 Processes while it's guaranteed that at least 30 Processes are always available for high-prio requests.

  • The quota (here: 70%) is the maximum number of Processes that may be assigned to low-prio requests. However, if there is a high number of high-prio requests from other users at the same time, processes from the low-priority quota would be reassigned to serve those high-priority requests. The actual quota would then be temporarily lower than configured. This is yet another reason why it's recommended to schedule EBRR Jobs for low activity periods.

• Example 1:

  • The user schedules 3 EBRR Jobs to be started at the same time, each with parallel processing active with 5 parallel tasks.

  • This would result in demand for 15 Processes.

  • Since 15 is well below 70, all parallel tasks should be assigned and processed with no delay.

• Example 2:

  • The user schedules 20 EBRR Jobs to be started at the same time, each with parallel processing active with 5 parallel tasks.

  • This would result in demand for 100 Processes.

  • Since only pool of 70 Processes at maximum is available according to quota, it should not be expected that each of those EBRR Jobs would actually be served with 5 Processes as requested.

  • Instead, up to 5 Processes will be dynamically allocated for each EBRR Job, if available. The number of assigned Processes can change from 1 to N (here: 5) throughout the EBRR Job runtime based on resource availability at a particular point in time.

  • The scheduling used in this example is not optimal and should be adjusted. Lower total number of required parallel tasks could be achieved by lowering the number of parallel tasks per EBRR Job or by reducing the number of EBRR Jobs scheduled for the same time.

Recommendations

The ultimate goal is to achieve optimal runtime of EBRR Jobs and minimize the effort needed for their maintenance. At the same time, system responsiveness for interactive users must not be compromised. Even though the system takes care of the latter, reasonably scheduled EBRR Jobs can contribute here, too.

Remark: The data to be processed via EBRR Job and its volume depend on customer business needs and reflect customer-specific settings. Therefore only general guidance can be provided.

1. Schedule EBRR Jobs for low-activity periods. This is a general recommendation for any Application Job and it applies to EBRR Jobs, too.

2. Get an overview of other EBRR Jobs that are scheduled for the same period. Then the potential resource bottlenecks can be mitigated with reasonable scheduling well ahead. This is especially true during period-end closing when multiple EBRR Jobs tend to run at the same time.

3. Use reasonable selection criteria of the EBRR Job to form well-defined and business-relevant data sets of the items to be processed. Multiple ledgers and/or company codes can be specified for the particular EBRR Job. That provides flexibility to find the right balance between number of EBRR Jobs and desired runtime. The bigger the data set volume, the longer the runtime. Split the data sets on ledger and/or company code level to reach higher granularity, if needed.
   
   Remark: with the upgrade to 2608, the new feature 'Dynamic Period' will be delivered. With that, there will no longer be a need for scheduling multiple EBRR Jobs when the Fiscal Year Variant is different for company code in different ledgers. A single EBRR Job would then be sufficient in such scenario. That would allow for scheduling fewer jobs overall, but the data volume of that single EBRR Job might be larger.

4. Use Complete Output only when necessary. It is strongly recommended not to use Complete Output (default: OFF) for normal, large-volume EBRR Jobs running on a regular basis. When used, it generates a detailed output with all calculated amounts. However, this comes with high calculation effort which results in significantly increased runtime. This is why it should be used only when very few items (better: single item) need to be analysed in detail.

5. Parallel Processing:

   1. Start with low number of parallel tasks and increase the number only when needed. Reaching the optimal setup and finding the right balance usually takes several iterations. Monitor runtimes after each scheduling change, evaluate and adjust the number of used parallel tasks gradually.

   2. Keep number of parallel tasks well below the system limit. Make sure the combined number of parallel tasks across all simultaneously running EBRR Jobs stays well below the quota for low-prio tasks. For example, on a server with 100 Processes and a 70% quota, keep the total number of parallel tasks across all running EBRR Jobs below 70.

   3. Consider the number of requested tasks for parallel processing a maximum number, not a guaranteed number. This should be acknowledged when scheduling EBRR Jobs and specifying the number of requested parallel tasks.

   4. There is no silver bullet for number of parallel tasks. Using 5 parallel tasks right from the start for many EBRR Jobs might bring no real positive effect as the quota would still safeguard the availability of high-prio requests. In short, asking for more parallel tasks does not necessarily result in reduced runtime.

   5. Spend Processes wisely as consuming 'too much' may result in reduced system availability for tasks in other areas.

6. The jobs should be scheduled out of the system upgrade windows due to reduced system availability during this time. Please, refer to Upgrade & Maintenance Schedule for respective landscape:
   2-System Landscape Upgrade & Maintenance Schedule
   3-System Landscape Upgrade & Maintenance Schedule