you can configure more than one spool work process for each instance. During the configuration of the R/3 server landscape, the question arises as to how many spool work processes should be configured for each server.
The spool work processes have different tasks: Up to (exclusively) 4.0A, the spool work process is responsible for processing print requests and transferring them to a host spool system. Furthermore it is responsible for demanding the job statuses in the host spool systems and scanning the spool database for requests lost through queue overflows. In Release 4.0A, it is also in charge of reassigning output requests during a spool server shutdown. In addition, a separate (printer-independent) link check for host spool systems (access method U and S) is carried out in Release 4.0B.
As of Release 4.6A, a spool work process also conducts the deletion of obsolete spool requests (as an option, you can configure this in Transaction SPAD via spool-settings).
Thus, the tasks of a spool service can be divided into three classes:
- Processing of output requests
- Local management actions
Requesting the host spool
Link check
- Global management actions
Scanning for lost requests
Reassigning requests
Deleting obsolete requests
The global management tasks are carried out throughout the system by a maximum of one spool work process. In the case of several configured spool work processes, the local management tasks are carried out for each instance exclusively by one spool work process. As a result, the spool service of an instance cannot be blocked by parallel processing of the same management tasks. In this way the spool service cannot, for example, be crippled by hanging or lengthy host spool demands if a minimum of two spool work processes is configured. Only the further demand is delayed until the current demand process is completed.
Configure one spool work process more on a spool server than there are parallel management tasks. This way, the server can process output requests even in the case of maximum load with all management tasks. As of Release 4.0B, for example, at least one spool work process out of four is available for the exclusive processing of output requests:
- a maximum of one work process for global management tasks
- a maximum of 2 work processes for local management tasks
a maximum of one work process for the host spool demand
a maximum of one work process for the link check
- and a minimum of one work process for output
As of Release 4.6A, frontend print requests are no longer processed by the spool service via dialog work processes. As a result an additional spool service load arises. By default the number of spool work processes useful for the frontend print is limited to 1 (can be changed via the profile parameter rdisp/wp_no_spo_Fro_max). To have the same service available to process the usual output requests, as existed prior to Release 4.6A, the number of spool work processes must be raised by 1 (or the value of the profile parameter rdisp/wp_no_spo_Fro_max). As a result at least one spool work process is exclusively available to process output requests as of 5 work processes.
- a maximum of 1 work process for global task management
- a maximum of 2 work processes for local task management
a maximum of 1 work process for host spool demand
a maximum of 1 work process for the link check
and a minimum of 2 work processes for the output
a maximum of 1 work process for frontend output requests
- and a minimum of 1 work process for outputting normal requests
The following information will help you avoid misunderstandings: Of course outputting may occur with fewer spool work processes. The examples used here only illustrate as of how many work processes at least one spool work process can process output requests. Because the management tasks do not come up regularly and must be performed, the spool work processes specified in the list are available for the rest of the time to process output requests. But even only then if no similar actions are to be executed. With fewer work processes it may occur that, in extreme cases, no output requests may be processed for a certain time. This is only then possible if at least one of the listed management actions no longer needs a work processes owing to the selected interval and the length of the action.
The option of configuring several spool work processes for each instance causes problems concerning processing of output requests of a device in accordance with the set sequence. If you want to utilize maximum parallel processing, it must also be possible to process several requests of a device in parallel. However, requests of one device can overtake each other due to different processing and process assignment times (through the operating system) so that processing in accordance with a set sequence is no longer possible. This is not always required. Therefore, as of Release 4.0A, you must decide separately for each R/3 output device whether processing in accordance with a set sequence is required. When upgrading an older system, this option is selected automatically to achieve compatible behavior. New devices are created by default as not in accordance with a set sequence.
Processing in accordance with the set sequence restricts the possibility to carry out several processes in parallel. It can only be achieved if processing is still carried out by a maximum of one spool work process. When you process requests for output devices in accordance with a set sequence, work processes are therefore exclusively reserved. This reservation is carried out dynamically and does not need a separate configuration.
Since requests can principally be dealt with by all work processes, a separate incoming queue is used for every reserved spool work process. If a spool work process receives a request for a device for which a work process has already been reserved, this request is not edited by the further work process, but simply put in its queue. If, on the other hand, no such reserved spool work process exists, the current process is reserved for the corresponding device and only processes its own input queue from this time onwards. Only if all requests in this queue are processed, does it participate again in the request dispatching and give up its reservation.
Due to the dynamic reservation it cannot happen that requests to (too many) sequence devices cripple a spool server and that other requests can no longer be processed since a once-reserved spool work process accepts no more global requests until its internal queue is processed. However, at this time its reservation is cancelled again so that it can also process requests from other devices. If all spool work processes are reserved, no more requests are distributed to the internal queues so that at least one spool work process must give up its reservation before new requests can be received.
Since the requests of a device which follow a set sequence can only be processed by one spool work process, a performance bottleneck of a spool server caused by an excessively high load cannot be solved by increasing the number of the spool work processes.
The problem can only be solved by not adhering to the sequence. In the case of devices which follow the sequence, only a performance bottleneck caused by too many requests to different devices can be solved by increasing the work process number.
With the dynamic reservation, it is not necessary to increase the number of spool work processes by changing the setting of the sequence.