Note 19706 - Tuning the Spooler

Note Language: English Version: 21 Validity: Valid Since 13.04.2010
Summary
Symptom
The response speed or throughput of the SAP spooler is unsatisfactory.
Other terms
..
Reason and Prerequisites
The spooler configuration is often inappropriately set.
Solution
This note contains recommendations and measures for SAP Systems in which
spooler performance is particularly important.
The reason for this note is that the R/3 spooler can be configured and
implemented in a large variety of ways. Because it aims to offer
convenience and robustness, it can reach printers in all sorts of ways and
can also serve unstable or unreliable host spoolers. However, this means
that internal alternative routes and protection and recovery measures
become necessary, and these may conflict with performance.
Organizational measures, coupled with care in making settings, are
necessary for systems with high demands placed on spooler throughput and/or
spooler runtimes.
Note 16307 explains where specific times are used during printing. Focus
your attention on the time interval between transaction start and paper
output.
Allocation of printers to spool work processes
The first step is to examine your output devices. Evaluate them according
to required response time and volume.
Now divide your printers into three groups. Place printers of the same type
in the same group.
Group 1 (Productive printer):
All printers with the shortest possible response time.
For example: Goods receipt/issue sheets, delivery notes, patient entry
sheets,...
Group 2 (Mass printer):
Printers with large volumes.
For example: Analyses, monthly lists, direct mailing...
Group 3:
Printers with small and moderate volumes, and without severe time demands.
For example: Small lists printed at the workstation...
26.04.2012 Page 2 of 5
SAP Note 19706 - Tuning the Spooler
If you have distributed your SAP System across several computers, you
should provide the spool service on each computer.
If you have three or more spool servers, assign each group to one or more
spool server. No spool work process may serve several groups. Group 1
devices should NEVER be defined with access type 'U', 'S' or 'G' ('F' in
old releases).
If there are two spool servers in the system, Group 1 must receive its own
spool server. Access type 'U', 'S' or 'G' must not be used in it. This
should also be avoided in the spool servers for the other two groups.
With only one spool WP, that is, a central instance without other
application servers, all requests inevitably have to be processed by one
spool server.
. Likewise, this must NOT use access type 'U', 'S' or 'G'.
Number of spool work processes
These groups should be distributed on more than one spool work process,
depending on the size of the group and the required response time. This is
particularly important for group 1. If you find that there are bottlenecks
in your system, it can be a good idea to set up instances on a host which
only deal with spool functionality (remember you need two dialog work
processes as well as the spool work process).
As of Release 4.0A, there are no more restrictions concerning the number of
spool work processes per instance. This enables a much more flexible
structure for the spool service. Please also see Notes 108799 and 118057 in
this regard.
Access types
Access type 'L': The spool work process uses a command (such as 'lp',
'lpr',..) to pass spool requests to the host spooler of its own machine.
These commands are quick, providing the host spooler queues do not
overflow. However, they normally copy the data around again. A command
(such as 'lpq', 'lpstat',..) is used to query the host spooler. With
network problems, these commands become slow because they (aim to)
determine the current status. If the runtimes become two long, you can use
the print configuration of Transaction SPAD to deactivate the queries.
Access type 'C': Procedure calls are used to communicate with the host
spooler on the computer. However, UNIX spoolers generally do not have an
API. The time conditions are the same as those for 'L'. This access method
is only available under Windows/NT and AS/400. Access method 'U':
A TCP/IP connection to the host spooler is set up. The host spooler
normally runs on a PC. Experience has shown that, with normal operation, it
is impossible to ensure that all printer PCs always accept/respond to data
as soon as the spool WP wants to talk with them. Thus, the spool WP is
forced to wait again and again.
Access method 'S': A different protocol is used on the TCP/IP connection.
Timing problems, however, are about the same as for 'U'.
26.04.2012 Page 3 of 5
SAP Note 19706 - Tuning the Spooler
Refer to Notes 128105 an 821519 for instructions on how to use access type
'G'.
A characteristic of network access types 'U' and 'S' is that any network
problems lead directly to the spool work process being interrupted. This
interferes with the processing of print requests, with the consequence that
printers which are not driven by a network access type but still linked to
the same spool work process are also affected. If network connections are
established via a WAN, you cannot expect a fast response to print requests,
and the spool work process is slowed down further. Unlike access method
'U', access method 'S' uses a handshake procedure. The result of this is
that the response time over a WAN is at least twice as long as for access
type 'S'. If you you need to use a network access method, we recommend that
you use access method 'U'. (SAPSprint can be run with access method 'U' as
well as with access method 'S').
Printers with a fast response (Group 1):
Devices with short response times must NEVER be defined with access type
'U' or 'S'. When a problem occurs (e.g. network problems, PC is switched
off etc.), a single printer linked to a work process by access type 'U'
disturbs all the connected printers. All printers in this group MUST be
linked with access type 'L' or 'C' (depending on the operating system). If
they are not linked to the server, they must be defined in the host spooler
as "remote printers" and forwarded via the the host spooler.
Host spooler inquiries
If host spooler inquiries take a long time - perhaps because the 'lpq' or
'lpstat' command is slow or because PCs are not responding - the spool WP
can lose A LOT of time. To avoid this problem, use transaction SPAD to
deactivate "Host spooler enquiries" for all printers which are giving
problems.
Disadvantage: In R/3, spool requests are considered "finished" the moment
they are successfully handed over to the host spooler.
Network printers
A printer is converted into a network printer when a small network node
processor is installed, either as a plugin card or small peripheral device.
A small network node processor of this type usually implements a TCP/IP
protocol stack and a Berkeley-compatible "lpd". (Example of a product of
this type currently on the market: The HP-Jet-direct-cards.)
Advantage of conversion: The network node processor is always active (when
the printer is switched on).
Disadvantage of conversion: Normally these printers do not have a large
buffer (1 MB max.), so that, beyond certain volume levels, data transfer
comes to a standstill and the spoolWP practically has to wait for the
printer to finish printing. In the worst cases, large print tasks may cause
connection problems, as SpoolWP will not wait long enough for the printer.
(for comparison: a PC with SAPLPD and also printers such as the QMS Crown
immediately accept everything and buffer it on the magnetic disk.)
26.04.2012 Page 4 of 5
SAP Note 19706 - Tuning the Spooler
Small network printers linked to the spool WP with access type 'U' are
performance killers! Wherever possible, you should define them via a local
host spool system which you can then address via access types 'L' or 'C'.
Other measures
In general, spool request data is written and read much quicker if it is
stored in files rather than in database table TST03. The advantages and
disadvantages are described in Notes 11070, 10551 and 20176. Profile
parameter: "rspo/store_location".
Make sure that the spooler database does not become too full. Program
RSPO0041 is described in Notes 16083 and 41547.
Quite a few printers can be slow in various emulation modes. It may be
worthwhile abandoning continuous lines (note 15594). (See Note 15594).
As of Release 3.0A, all users should use the
Option: 'Delete after printing' if possible, to keep the number of
simultaneous spool requests in the system to a minimum.
Regardless of the configuration of the R/3 spool system, you can improve
spool performance to a certain extent by the way in which you generate
spool requests in applications. Performance is better if you create a few
large spool requests instead of several smaller ones. The amount of data
transferred and the overheads involved with establishing links to the
external spool system are reduced. If you can configure your applications
in this way (for example, via message control), this should improve the
performance of your spooler system.
Additional reading
Note 65109: Long delays when printing during load
Note 53047: Warning: Queries to print requests are too slow
Note 16083: Reorganization jobs
Note 16307: Processing times when printing
Note 11214: SPAD: Changes have no effect
Note 11070: Space requirements of TemSe and spooler
Note 10551: Table TST03 (tablespace PSAPPROTD) size increasing
Note 07140: Problem printing very large lists
Note 108799: How many spool work processes per instance
Note 118057: Flexible structure of the R/3 spool service
Spooler chapter in the SAP System Administration documentation.
Online help at many places in transaction SPAD.
Header Data
Release Status: Released for Customer
Released on: 13.04.2010 08:51:22
Master Language: German
Priority: Recommendations/additional info
Category: Help for error analysis
26.04.2012 Page 5 of 5
SAP Note 19706 - Tuning the Spooler
Primary Component: BC-CCM-PRN-SPO Spool System
The Note is release-independent
Related Notes
Number Short Text
504952 Composite note regarding spooling and printing
68511 How does an output request get to the spool work process
65109 Long delays when printing during overload
53047 Warning: Queries to print requests are too slow
39412 How many work processes should be configured?
16307 Processing times when printing
16083 Standard jobs, reorganization jobs
11214 Print problems: Changes SPAD/RSTXCRP/RSTXCPAG
11070 Space requirements of TemSe and spooler
10551 Table TST03 grows
7140 Problem printing very large lists