Updated: 18 October 2022
Please note this document and all other documents it links to are living documents so will evolve over time as new things are discovered, new functionality is provided, best practises adjusted and/or when I get time to add content; so please make sure you come back and visit this source document often.
Contents
Performance tuning your Sage X3 system: Print Server
General blogs, KB articles, etc.
Introduction
The Print Server component is quite interesting as it sits in it’s own world and normally just does what it’s designed to do, however there are a few places where it can get “clogged up” and sometimes not print as quickly as you would like, or expect.
The basic steps on how print server work are described in the online help “Print Server Presentation and Operation Guide”, but essentially X3 creates a print request and sends it to the X3 Print Servers queue. The X3 Print Server processes the reports in its queue in order, downloading a copy of the X3 report if it doesn’t already have it, then the X3 Print Server sends the generated report to the Windows Print Server. The reasons for slowness can therefore be rooted in one of three main areas, X3 report request generation, X3 Print Server report generation or Windows Print Server.
Many of the steps you can take to identify where the report is slow and how to run traces, etc. is already covered in my blog Illustrated guide to tracing/debugging Sage X3 Report Server so take a look at that to see if that helps.
Purge X3 tables
Set the purge job "ATMP" (Temporary tables) to run regularly in order that the AREPORTM table is regularly purged. This can impact certain reports when this table gets too big.
Tuning X3 Print Server
In the X3 Console you will find there are some configuration parameters that can influence performance. Use the “Expert mode” button to see all parameters:
General Settings
|
Max pending print requests |
all.processsrv.nbmaxjobs |
Maximum number of Print requests that an instance of the Print Server will be allowed to manage in its print queue. Default value 200. A large number of active print requests will take more memory, up to 1000 should be OK with 4GB RAM available. |
Print processes
|
Variable coefficient for size of the shared memory |
print.jobs.vpallocbyjob
|
Maximum size in Kb of the shared memory segments used to store the variable parameters. Not normally an issue but can be increased if error messages being seen in this area. |
|
Maximum number of concurrent printing processes |
print.processes.nbmaxproc
|
Maximum number of concurrent (parallel) report/print jobs serving the queue. Too big value may be counter productive. Recommended rule of thumb value: not more than 2 jobs per logical CPU |
|
print.processes.nbminproc |
print.processes.nbminproc |
Minimum number of printing processes. This can reduce startup time of the print server requests by having a pool of print server processes ready to go. |
|
Time before killing processus (Minutes) |
print.processes.killtimeproc
|
Maximum duration before deletion of a blocked print process (expressed in minutes) Useful as a safeguard against runaway processes. |
|
Maximum successive jobs by a process |
print.processes.maxjobsbyprocess
|
The maximum number of jobs that a print process “AdxImpNet” will process before automatically being killed. Having processes refreshed in this way helps to reduce likelihood of process memory not being released properly. |
Windows specific
I don’t have many notes of Windows specific setup, but there are some things you can do generally.
Windows Event viewer
Check the Windows Event Viewer for any relevant error or warning messages. We have seen in the past where there were lots of “The printer name is invalid” recorded in the event log which ended up pointing to an issue with the network causing performance slowdown.
Print Server/Printer setup
1. In general it is best to keep the X3 Print Servers printer drivers up to date with the latest printer drivers from the appropriate Manufacturers web site, which normally give best performance and stability.
2. Sometimes larger reports seem to take a long time to start printing once sent to the Windows Print Server. In this case, on the X3 Print Server you could potentially set the windows spooler settings in the Print Driver, Advanced tab to "Start printing after the last page has spooled" rather than “Start printing immediately” Also selecting “Print spooled documents first” often gives best performance in this case.
3. You could consider enabling more detailed Windows Event logging. You can find this in your Windows documentation, for example "Troubleshooting Windows Server 2012 Printing" includes a section on enabling "PrintService Event Log Channel", which could give additional clues to printing issues generally.
General blogs, KB articles, etc.
Illustrated guide to tracing/debugging Sage X3 Report Server (Blog)
Print Server Presentation and Operation Guide (Online help)
Print Server on Windows Includes hardware requirements (Online help)