The tests that generated these numbers were performed according to the guidelines and tools specified in the Terminal Services Capacity and Scaling white paper, in the Test Environment and Testing Tools section. This document can be found at:
Note: The information in this white paper is meant to provide additional detail about a specific area of Terminal Services, and is not meant to replace the use of the Terminal Services Capacity and Scaling white paper as a guide for scaling.
The SMClient scripts were customized to add the printing requirements to the test. Each script was run for 30 minutes per session.
The tests for this section were performed using the following equipment and settings:
In our test runs on this hardware and setup, we saw relatively little degradation in terms of scalability, as defined in the Terminal Server Scaling and Capacity Planning white paper, caused by enabling printer redirection.
Overall, you can expect to see a 10% degradation of your maximum scale by using printer redirection on your terminal server. This figure is an average and may fluctuate higher or lower in a given scenario depending on usage patterns, applications used, and type and size of data printed.
Explanation of Scalability Performance Results
These numbers generally correlate with the scalability numbers specified in the Terminal Services Capacity and Scaling white paper for Knowledge Worker class users, with the added global loss of total server scale by the cumulative load of printing.
As noted, in the above tests LaserJet class printers were used. Some printer models can have a limiting effect on printer redirection scale; most of these devices fall into the consumer inkjet category. Their device architecture provides only the basic capabilities necessary to position the carriage over the paper. Therefore, all of the rendering work that would be handled by a LaserJet–class printer must be handled by the host computer.
In the situation where one of these devices is redirected, the Terminal Server becomes the host, and additional loads may be seen in the way of incremental CPU or memory loads during printing. How much load they introduce to your environment depends on the complexity of the print jobs submitted to them. Documents with large numbers of graphics or complex combinations of typefaces will increase the load. If you have these devices in your deployment, create a testing methodology to understand the tradeoff between using these devices and your impact on scale as a result of using them.
An explanation of these devices from HP, one of the manufacturers of such devices can be found by searching on “PPA (Printing Performance Architecture)” on their site, or visiting the following link:
3. For each client printer and printer port (COM or LPT), RDPDR.SYS creates a new dynamic printer port with the help of USBMON.DLL (details below).
4. RDPDR.SYS notifies WLNOTIFY.DLL of the new printers and ports.
5. WLNOTIFY.DLL uses Spooler APIs to create a new print queue for each new printer. The naming convention for these queues is as follows:
[queue name]/[client machine name]/[session number]
Local Printer Queue Name/CLIENT1/Session 1
The steps for transferring print data from an application to a remote printer are as follows:
1. Printer output is formatted for a specific printer by GDI and an associated KERNEL-mode or USER-mode (Windows 2000 drivers only) graphics printer driver.
2. The printer output is sent to the Terminal Server’s Spooler (this may require spooling to disk).
3. The server-side Spooler may perform additional processing on the print output, with the help of other USER-mode printer drivers.
4. In the case of a printer output for a TS port, the Spooler next sends the output to the dynamic port monitor (USBMON.DLL).
5. USBMON.DLL forwards the printer output to RDPDR.SYS, which sends the RAW data to the appropriate TS client machine.
6. The TS client machine sends the RAW printer output it has received to the locally attached printer.