My Experience Tuning the SAP Spooler Note 19706

SAP SPOOLER

I’ve seen cases where the SAP spooler response speed or throughput was unsatisfactory. This usually showed up as delays between starting a transaction and the actual paper output.

Root Causes

In my experience, poor spooler performance often comes down to configuration issues. The spooler is designed to be flexible and robust, able to reach printers in many ways and handle unreliable host spoolers. But this flexibility introduces overhead — alternative routes, recovery measures, and protection mechanisms can conflict with performance.

Organizing Printers into Groups

One of the most effective steps I’ve taken is grouping printers by usage:

• Group 1 (Productive printers) → Fast response devices like goods receipt sheets, delivery notes, patient entry sheets.

• Group 2 (Mass printers) → High‑volume devices for analyses, monthly lists, direct mailings.

• Group 3 (General printers) → Small/moderate volume printers without strict time demands.

If multiple spool servers exist, each group should be assigned to its own server. Group 1 printers must never use access types ‘U’, ‘S’, or ‘G’ — they should be defined with ‘L’ or ‘C’.

Number of Spool Work Processes

Distribute groups across multiple spool work processes, especially Group 1. Bottlenecks can be reduced by dedicating instances to spool functionality. Since Release 4.0A, there are no restrictions on the number of spool WPs per instance, which allows flexible scaling.

Access Types

Here’s how I’ve seen access types affect performance:

• Access type L → Uses commands like lp or lpr. Fast if queues don’t overflow.

• Access type C → Procedure calls; available under Windows/NT and AS/400.

• Access type U → TCP/IP connection to host spooler (usually a PC). Often unreliable; spool WP waits for responses.

• Access type S → Similar to U but with handshake protocol; slower over WAN.

• Access type G → Special protocol; see Notes 128105 and 821519.

For fast printers (Group 1), I always stick to L or C. Using U or S can cause one faulty printer to block others.

Host Spooler Inquiries

Commands like lpq or lpstat can slow things down if PCs don’t respond. I disable host spooler inquiries in SPAD for problematic printers. The trade‑off: R/3 considers spool requests “finished” once handed to the host spooler.

Network Printers

Small network printers with access type U are performance killers. They often lack buffer capacity, forcing the spool WP to wait. I prefer defining them via a local host spool system and addressing them with L or C.

Other Measures I Use

• Store spool request data in files instead of table TST03 (rspo/store_location parameter).

• Keep the spooler database lean — use RSPO0041 to delete old requests.

• Encourage users to select “Delete after printing” to reduce simultaneous requests.

• Generate fewer, larger spool requests instead of many small ones to reduce overhead.

Reports & Notes I Rely On

• RSPO0041 / RSPO1041 → Delete outdated spool requests

• RSBTCDEL → Clean up job logs

• RSPO1043 → Background spool consistency checks

• Notes 11070, 10551, 20176 → Storage and TST03 growth

• Notes 108799, 118057 → Flexible spool WP configuration

• Note 16307 → Printing time analysis

Lessons Learned

• Printer grouping is critical: Mixing fast and slow devices in one spool WP leads to bottlenecks.

• Avoid U/S for critical printers: They’re too dependent on network stability.

• Consistency checks matter: Regular cleanup and monitoring prevent spooler overload.

• Application design impacts performance: Fewer, larger spool requests are always better.