Testing PaperCut in a realistic way can be quite difficult. There are a number of layers in the application that get exercised when a print job is processed. Any practical load testing needs to excise all layers. Here are a few tips and tools:
Printing Load Testing
A good way of load testing printing is to use a simple “batch printing” script across multiple systems. Here is an example batch file for Windows:
FOR /L %%A IN (1,1,100) DO (copy /B testdoc.ps "\\print-server\Test Printer" && ping -n 2 localhost)
This will print 100 jobs of a representative PostScript test document to the server with a small delay between jobs. It’s suggested that you run this script in parallel on at least 10 workstations.
The test file can be simply generated using the Windows “Print to File” feature.
Client Load Testing
You can test client load and activity with a special command-line option on the standard PaperCut client software. Running
pc-client.exe on the client with the following option will simulate the client load of 100 workstations:
pc-client.exe --stress-test ServerIP NumClients
\\print-server\PCClient\win\pc-client.exe --stress-test 10.1.1.44 100
To simulate a real network environment we’d recommend running this command on at least 10 separate workstations in different parts of the network (different latency profiles). Hence this will simulate 1,000 clients.
During load testing we’d recommend checking:
- That all jobs sent are accounted for and logged as expected
- The clients don’t raise any disconnection errors during the activity
- Check the PaperCut Application Log for any error events
- Check the database system for any error or warning events
- Check the server OS system logs for any error events
CPU and Memory logging is of limited value and is more useful for comparison reasons rather than “gaining knowledge”. As you’d expect under a stress test like this, usually CPU will hit 100% while jobs are being processed.
Keywords: stress testing, performance profile, performance testing, monitoring