SAP Note No.

19706
09.09.2003
Page 1
________________________________________________________________________
Number
Version
Status
Set on

19706
15 from 09.05.2001
Released for Customer
08.05.2001

Language
Master language
Short text

EN
DE
Tuning the Spooler

Responsible
Component

SAP AG
BC-CCM-PRN-SPO
Spool System
________________________________________________________________________
Long text
Symptom
The speed of response/throughput of the R/3 spooler is found to be
unsatisfactory.
Additional key words
Cause and prerequisites
The spooler configuration is often inappropriately set.
Solution
Date: 9 May 2001
This note contains recommendations and measures for R/3 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, as a
result, internal alternative routes, as well as protection and recovery
measures, become necessary which can 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. Assess them by
required response time and volumes.
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.
Examples: Goods receipt/issue sheets, delivery notes, patient entry
sheets,...
Page 2

Group 2 (Mass printer):

Printers with large volumes.
Examples: Analyses, monthly lists, direct mailing...
Group 3:
Printers with small and moderate volumes, and without severe time
demands.
Examples: Small lists printed at the workstation...
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. A spool server may NOT serve several groups. Group 1
devices should NEVER be defined with access type 'U', 'S' or 'F'.
With two spool servers in the system, Group 1 must receive its own spool
server. Access type 'U', 'S' or 'F' 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 'F'.
Number of spool work processes
The following rule applies up to and including Releases 2.1J and 2.2D:
A maximum of one spool work process per computer.
From Release 2.1K, 2.2E and 3.0A, the following rules applies:
A maximum of one spool work process per instance. It is therefore
possible to raise the number of spool work processes indirectly via new
instances (with new instances numbers ("SAPSYSTEM=01"..).
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 und 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.
Access type 'N': Still exists for compatibility reasons. From 2.0A, it
Page 3

works the same as 'L'.

Access type 'C': Procedure calls are used to communicate with the host
spooler on the computer. UNIX spoolers, though, generally do not have an
API. The time conditions are the same as those for 'L'. This access type
is only available under Windows/NT and AS/400.
Access type '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 type 'S': A different protocol is used on the TCP/IP connection.
Timing problems, however, are about the same as for 'U'.
Refer to Note 114426 for instructions on how to use access type 'F'.
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 type 'U', access type '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 cannot avoid using a network
connection, you should use access type 'U' (SAPLPD can be driven with
either of the access types 'U' or 'S'. Device type SAPWIN can also be
used with access type 'U' from Release 3.0 onwards).
Printers with a fast response (Group 1): Conditions
The 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', 'N' 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. (Spool version 4.2 is required for SNI.)
See also note 19615.
Avoidance of access types 'U' and 'S' has particular importance for
Releases 2.1A-2.1J and 2.2A-2.2D as error processing can build up here
after connection problems. (2.1E and 2.1F are particularly affected.)
Build-up will no longer occur from 2.1K and 2.2E, although problems with
direct TCP connection will continue to slow down the system.
See also note 12195.
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.
Page 4

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 from certain volume levels, data transfer
comes to a standstill and the spool WP practically has to wait for the
printer to finish printing. (Comparison: A PC with SAPLPD, but also
printers such as QMS-Crown, receive everything immediately and buffer it
on magnetic disk.)
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 (note
9419). 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).
The build-up of internal recovery measures, as described in note 12195,
can also be avoided by generating spool requests without the addition of
'Delete after output'. However, in this case, schedule report RSPO0041
every night in order to delete the requests that have already been
printed. This measure should only be implemented for pre-3.0A releases.
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.
Some spooler tables can be buffered subsequently:
TSP03, TSP03C, TSP0A, TSP06 (as of Release 3.1G in the standard system)
This makes many transactions quicker, both before and during spool
request generation. IMPORTANT: If you then implement changes in the
SPAD, the SAP buffers must be reset. Therefore, only implement this
measure with great care.
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
Page 5

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
Note
Note
Note
Note
Note
Note
Note
Note
Note
Note
Note
Note
Note

65109: Long delays when printing during overload

53047: Warning: Queries to print requests are too slow
12195: Spool work process runs very slowly
19615: Measures for increasing the throughput when printng
19632: (Old version of this note)
16083: Reorganization jobs
16307: Processing times when printing
11214: SPAD: Changes have no effect
15594: Deactivating frame printing and color
11070: Space requirements of TemSe and spooler
10551: Table TST03 (tablespace PSAPPROTD) size increasing
07140: Problem printing very large lists
108799: How many spool work processes per instance
118057: Flexible structure of the R/3 spool service

Hypertext 'PRINTERINST' (and 'PRINTERDIAG')

Spooler chapter in the R/3 System Administration documentation.
Online help at many places in transaction SPAD.
Source code corrections
________________________________________________________________________
Note is release independent
________________________________________________________________________
Reference to related Notes
Number
Short text
____________________________________________________________
19632
Measures for increasing throughput when printng until Rel. 3
7140
Problem printing very large lists
39412
How many work processes to configure
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
65109
Long delays when printing during overload
53047
Warning: Queries to print requests are too slow
________________________________________________________________________