Learn effective strategies to boost background job performance and optimize your application’s efficiency. Discover key tips and best practices in this comprehensive guide
Performance Factors for Background Jobs
Background jobs occupy a large part of the system resources. Therefore, they can have a negative effect on the online system performance. However, background jobs don’t have a higher priority than dialog work processes; that is, they aren’t assigned more system resources. There are various methods for optimizing sys-
tem performance during the execution of background jobs. Online users benefit from these methods, and background jobs can be executed more efficiently. To reduce the influence of background jobs on the system, you can run batch jobs on a standalone batch application instance or batch application server. For a small central instance with only 10 users, two batch jobs can already significantly impair the system performance. For small installations, it can therefore also be necessary to use additional application servers to isolate the batch processing from the central instance. The instance profile for this application server would
then rather aim at background jobs than at the dialog (online) performance (e.g., five background work processes and only two dialog work processes).
Number of Available Background Processes
As a rule of thumb, the number of background processes shouldn’t be larger than twice the CPU number. You can determine whether your system has enough batch work processes if all processes of type BTC in the process overview (Transaction SM50) have long CPU times. This means that the processes are used almost to their full extent, and only a little capacity is left in the system. At least one BTC process should have a very low CPU time (depending on the last system start; value <1 minute).
However, the definition of a target host can lead to problems. If you specify the target host, the system doesn’t perform load balancing. So it’s possible that the maximum number of batch work processes is occupied on the batch application server, but other applications aren’t used at all. If you define that the job is supposed to be executed on the batch application server, you prevent it from being executed on another application server that is available. The job then waits until a batch work process on the specified batch application server is available.
When you schedule jobs, you should bear the following in mind:
► Consider the time of the execution
Schedule background jobs so that they aren’t executed during peak times, that is, preferably overnight or during lunch. If no users are logged on to the system, it’s no problem if the system performance decreases.
► Minimize job conflicts
Two background jobs that run at the same time might access the same files or even data records, which may lead to a cancellation of the jobs. You can avoid this conflict by coordinating these background jobs (e.g., two reports on due payments should not run simultaneously). For time reasons, the reports should run in succession in such cases.
► Consider the local time for the respective users in case of global jobs
For example, if a resource-intensive background jobs is scheduled for 10am local time in Germany (9am GMT), this corresponds to a local time of 1am in California. The time is advantageous in California because it’s in the middle of the night, but in Germany, the job would be executed during working time. For certain
jobs, for example, backups of files at the operating system level, the execution time is very critical for the following reasons:
• A backup of these files may require that the files aren’t changed or used during the backup process because the backup fails otherwise.
• Programs that try to change a specific file are canceled because the file is locked due to the backup process.
Background Jobs for Multiple Time Zones
List the respective local times for all affected global locations. This way you can easily determine the local time in the affected locations when scheduling a job.
You should also define an enterprise timer (e.g., a specific server) or an enterprise time for organizations with locations in different time zones. You have several options here, for example:
► As the enterprise time, you use the time zone in which the enterprise is head quartered.
- For SAP in Walldorf, Germany, this is CET (Central European Time)
- For United Airlines in Chicago, Illinois, this is CST (Central Standard Time).
►UTC (Coordinated Universal Time) is used as the enterprise time, previously known as GMT (Greenwich Mean Time). This time is used by global organizations, such as airlines.
For daylight savings time, you have to consider the days at which the clocks change:
► Beginning of daylight savings time
The clocks are adjusted forward one hour. Jobs that were scheduled for this hour aren’t executed or are executed with a delay. Tasks that are carried out after the clock shift and that depend on a job that should have been executed in the missing hour need to be checked.
► End of daylight-saving time
At the end of daylight-saving time, a problem occurs because an hour is “repeated.” For example, if the clock is adjusted backward from 3am to 2am, the hour exists twice for the system. You can avoid these clock shift difficulties by using UTC (GMT) as the enterprise timer.
Standard Time and Daylight Saving Time
Clocks don’t shift at the same time in all countries, which may result in time differences during this phase.