The response speed or throughput of the SAP spooler is unsatisfactory.
The spooler configuration is often inappropriately set.
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.
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...
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'.
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 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'.
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').
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.
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.
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.)
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'.
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.
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.
No comments:
Post a Comment