Print Server Scalability and Capacity Planning
Applies To: Windows Server 2012 R2, Windows Server 2012
This guide describes the Microsoft best practices approach for estimating scalability and capacity for Print Server in Windows Server 2012 R2 or Windows Server 2012. It provides an in-depth description of the contributing factors that affect the scalability and performance of Print Server, such as the hardware specifications, network latency, and the content of the print job, and it includes best practices and recommendations for deploying this solution correctly.
This guide contains the following information:
Analysis of the key factors affecting performance, scalability, and capacity planning
Case study of a Print Server reference system
Print Server deployment best practices and recommendations
This guide is intended for readers including administrators and architects who are responsible for creating the architecture and design of Print Server within the enterprise. It assumes that the reader has knowledge of Print Server, Windows Server 2012 R2 and Windows Server 2012, and related Microsoft products and technologies.
What this guide includes
Factors that influence Print Server performance
The following contributing factors are presented in order from those that have the greatest, to those that have the least, effect on the scalability and performance of Print Server.
Number of clients
The number of clients that are connected to a print server can causes a large drain on system resources. System resources are allocated and ready for use immediately when a connection is established between the client and the server. The connection to a Print Server is established each time a client invokes spooler activity, such as when querying for status or submitting a print job.
Depending on the application that the client uses to establish the connection to the print server, and then to print, the client may inadvertently hold connections open, for example, when the user does not terminate the application on their workstation. In this case, the connection might remain open for hours, or even days in extreme cases. In fact, a print server can become constrained either due to the number of clients that are connected actively when printing, or passively when the client holds the connection open.
Administrators generally find that the total number of users connected to a print server shows light activity at beginning of the workday, an increasing server load and peak during midday, and a gradual decrease at the end of the day.
Client-side rendering or server-side rendering
Print Server in Windows Server 2012 R2 or Windows Server 2012 can be configured to render documents to the device-ready page description language (PDL) format either on the client or on the server. In client-side rendering, the print system on the client translates the document to a printer-specific PDL before it sends the data stream to the print server.
When the queue is configured to use server-side rendering, or the client is not capable of using client-side rendering, the client print system sends the document directly to Print Server. Print Server then renders the document to a printer-specific PDL locally.
To maximize server capacity, we recommend using client-side rendering when possible.
Operating system of the print clients
Depending on the enterprise ecosystem and the mixture of supported clients, the performance of Print Server might vary due to its feature capabilities. For example, in an environment that uses Windows 7 clients and v4 printer drivers on the printing shared resource, server-side rendering is used. Effectively, every print job that is generated by these clients requires processing on the server. Therefore, when there are more simultaneous jobs, the workload on the server increases.
As another example, if Branch Office Direct Printing is turned on in Windows Server 2012, and there is a heavy mixture of Windows 8 clients, performance is improved. Windows 8 performs client-side rendering that offloads the processing to the client instead of to the server. Then it routes the job directly to printer, instead of passing it through a centralized print server, which reduces network traffic.
For more information, see Branch Office Direct Printing Technical Details.
The default rendering options that are used by Windows Server 2012 R2 and Windows Server 2012 are described in the following table.
V3 printer driver |
V4 printer driver |
V4 printer driver (Branch Office) |
|
|---|---|---|---|
Windows 8.1 |
Client-side |
Client-side |
Client-side |
Windows 8 |
Client-side |
Client-side |
Client-side |
Windows 7 |
Client-side |
Server-side |
Client-side |
Because of the various advantages of the v4 printer driver, administrators are encouraged to promote a client mixture that uses Windows 8.1 or Windows 8 with Windows Server 2012 R2 or Windows Server 2012. In situations where the enterprise has a large number of Windows 7 users, the effect of server-side rendering could require additional benchmarking to ensure acceptable performance.
For client devices that run on ARM processor architecture, we encourage the use of v4 printer drivers to take advantage of the various benefits of the Print and Document Services architecture.
For more information, see Print and Document Services Architecture.
Mix of drivers hosted on print server (v4 or v3 printer drivers)
In Windows 8 and Windows Server 2012, Microsoft introduced a new iteration of the printer driver model, called the v4 printer driver. This driver model addresses gaps in the previous version and it offers a wide range of advantages. Because the v4 printer driver model has fewer components that cause heavy server processing, there is a lower server load when a v4 printer driver is used with Windows 8.1 and Windows 8 clients. Because Windows 7 clients always use server-side rendering with the v4 printer drivers, more processing occurs on the server.
For more information, see V4 Printer Driver.
Types of print jobs
When server-side rendering is used, the server handles the conversion of the job to device-ready PDL. The amount of processing for each print job is hard to predict because it depends on the content of each print job. For complex jobs, such as documents with extensive graphics, documents in PDF format, or documents with multiple types of fonts, more CPU processing is required, as compared to a simple text document.
If client-side rendering is used, the processing occurs on the client-side, and it does not present additional workload to the server. Given the computing capabilities of devices in the market, we recommend using the client-side rendering configuration when possible.
Printer hardware
Printers that support the Open XML Paper Specification (also called XPS or OpenXPS) require only minimal server support, even when the server is configured to use server-side rendering. Printers that support PCL6 or PostScript are less efficient than XPS because they are vector formats. They require fewer resources than a printer that uses a low-end raster-based image editor.
High-end printers generally have built-in hard disk drives and memory. This allows them to process a print job without a protracted spooling process and the associated disk utilization. In contrast, less expensive printers generally have less processing power and internal memory, and they require more processing and disk space on the print server. It is the administrator’s responsibility to gather organizational requirements and analyze the tradeoff between device capabilities and cost.
Printing related factors
The network bandwidth and storage for Print Server can be affected by printing related factors including the number, size, and frequency of print jobs. For example, using Print Server with high-frequency smaller jobs has a different storage requirement than using Print Server with large print jobs. If Print Server is configured to save print jobs after printing, additional storage is required and this requirement needs to be considered for the deployment.
System hardware configuration
As with any computing environment, more cores on a processor and more memory enables more computing output. Depending on enterprise requirement and the budget that is available, this is an important factor that administrators should consider when making decisions about deployment.
With the trend toward server consolidation using virtualization, it is common to see print servers running in a virtualization environment. Although there is no functional difference between a print server on a virtual machine and a physical print server, there can be a significant difference in the scalability factor based on the hardware requirements and specifications.
Performance needs to be evaluated based on the allocated number of cores and memory. On physical print servers, the print job offloads processing to the GPU to expedite completion when it uses a v4 printer driver and supports the XPS rasterization service. On virtual machines, this behavior does not occur due to the absence of a GPU.
To verify if a particular v4 printer driver supports the XPS rasterization service, administrators can check the manifest file for the driver package. Specifically, you need to check the filter pipeline configuration XML file.
For more information, see Filter Pipeline Configuration File.
In addition, administrators need to verify that the FilterServiceProvider element contains XpsRasterService.dll. You might also review the details on the XPS rasterization service usage tree.
For more information, see:
Administrators can also add failover clustering to their print service by using the standard clustering strategy. For more information, see:
Clustering and High Availability, Creating a Windows Server 2012 Failover Cluster
Failover Clustering Hardware Requirements and Storage Options
Storage and spool directory
A print server typically performs many I/O operations, while accepting and processing print jobs. Depending on the state of Print Server, excessive page fault can occur due to memory paging during high print activities. The combination of concurrent I/O operations and page fault might cause Print Server performance to degrade.
To minimize this issue, we recommend that administrators store the print spool folder on a drive that is separate from the drive that hosts the operating system and page files. Having this separate I/O channel reduces server activity and workload.
For more information, see HOW TO: Move the Print Spool Folder in Windows 2000.
Non-Microsoft software
Some non-Microsoft software can affect server scalability. For example, if Print Server uses a non-Microsoft accounting package that runs as a system service and tracks print usage information, it would likely consume CPU. Non-Microsoft port monitors may provide similar effects. Depending on their implementation and interaction with the system, this type of software could create additional workload that reduces performance.
Diagnostic and performance analysis
Because there are many factors that affect the sizing of a print server, the best way to effectively estimate server size is to monitor performance for an existing print server over a period of time in order to identify bottlenecks, and to understand the investment. Because the server load varies over the course of a day or week, we recommend monitoring the print server for at least a day to identify peak resource utilization. This section describes some of the performance counters that are useful for print server analysis.
To review these performance counters, Performance Monitor is provided in Windows Server 2012 R2 and Windows Server 2012. For a complete list of all performance counters, see Using Performance Monitor.
Print-specific counters
The print-specific counters for monitoring performance are described in the following table.
Counter name |
Description |
||
|---|---|---|---|
Add Network Printer Calls |
Total number of calls from other print servers to add shared network printers to this server since the last restart. |
||
Bytes Printed/Sec |
Number of bytes printed per second in the print queue. This provides a rough indication of the extent of time that the printer is busy. This counter can be used for bottleneck detection. |
||
Enumerate Network Printer Calls |
Total number of calls received from clients to this print server to request network browse lists since the last restart. |
||
Job Errors |
Total number of job errors in a print queue since the last restart. Job errors can occur if the connection to the printer has errors due to network issues. |
||
Jobs |
Current number of jobs in a print queue. Use this counter to identify excessive use. |
||
Jobs Spooling |
Current number of spooling jobs (incoming or incomplete) in a print queue. |
||
Max Jobs Spooling |
Maximum number of spooling jobs (incoming or incomplete) in a print queue since the last restart. |
||
Max References |
Peak number of references (open handles) to this printer. |
||
Not Ready Errors |
Total number of printer-not-ready errors in a print queue since the last restart. |
||
Out of Paper Errors |
Total number of out-of-paper errors in a print queue since the last restart. |
||
References |
Current number of references to a print queue. A reference can be a user or a program that is connecting to a printer and opening a print queue. |
||
Total Jobs Printed |
Total number of jobs printed from a print queue since the last restart. Note that the counter reports the total number of jobs spooled. In the event a job has not successfully despooled, it is still accounted for by using this counter. |
||
Total Pages Printed |
Total number of pages that have printed through the Graphics Device Interface (GDI) in a print queue since the last restart.
|
.jpeg)
NoteProcess-specific counters
The process-specific counters for monitoring performance are described in the following table. In addition, to monitor the performance of a Print Server operation, check the following processes, since they provide the most useful information regarding print activities:
Spoolsv.exe
Printfilterpipelinesvc.exe
Printisolationhost.exe
Counter name |
Description |
|---|---|
% Processor Time |
The percentage of elapsed time that all process threads use to run instructions. An instruction is the basic unit of run time for a computer, a thread is the object that runs instructions, and a process is the object that is created when a program is run. This count includes code that is run to handle some hardware interrupts and trap conditions. |
Handle Count |
The total number of handles that are currently open by this process. This number is equal to the sum of the handles that are currently open by each thread in this process. |
Virtual Bytes |
The current size of the virtual address space for the process in bytes. Use of virtual address space does not necessarily imply a corresponding use of disk space or main memory pages. However, virtual address space is finite, and the process can limit the ability of the virtual space to load libraries when it uses too much of it. |
Virtual Bytes Peak |
The maximum size of virtual address space that the process has used at any one time in bytes. Use of virtual address space does not necessarily imply corresponding use of disk space or main memory pages. However, virtual address space is finite, and the process can limit the ability of the virtual space to load libraries when it uses too much of it. |
Pool Paged Bytes |
The size of the paged pool in bytes. This is an area of system memory (physical memory that is used by the operating system) for objects that can be written to disk when they are not in use. Memory\\Pool Paged Bytes is calculated differently than Process\\Pool Paged Bytes, and it might not equal Process\\Pool Paged Bytes\\_Total. This counter displays the last observed value only; it is not an average. |
Pool Nonpaged Bytes |
The size of the nonpaged pool in bytes. This is an area of system memory (physical memory that is used by the operating system) for objects that cannot be written to disk, but must remain in physical memory as long as they are allocated. Memory\\Pool Nonpaged Bytes is calculated differently than Process\\Pool Nonpaged Bytes, and it might not equal Process\\Pool Nonpaged Bytes\\_Total. This counter displays the last observed value only; it is not an average. |
Working Set |
The current size of the working set of the process in bytes. The working set is the set of memory pages that were recently touched by threads in the process. If free memory in the computer is above a certain threshold, pages are left in the working set of the process, even when not in use. When free memory falls below a certain threshold, pages are trimmed from the working sets. If needed, the pages are then soft-faulted back into the working set before leaving main memory. |
Working Set Peak |
The maximum size in the working set of the process in bytes at any point in time. If free memory in the computer is above a certain threshold, pages are left in the working set of the process, even when not in use. When free memory falls below a certain threshold, pages are trimmed from the working sets. If needed, the pages are then soft-faulted back into the working set before leaving main memory. |
Disk-specific counters
The disk-specific counters for monitoring performance are described in the following table.
Counter name |
Description |
|---|---|
% Disk Time |
Percentage of elapsed time during which the selected drive was busy servicing Read and Write requests. |
Avg Disk Queue Length |
Average number of Read and Write requests that were queued for the selected disk during the sample interval. |
Memory-specific counters
The memory-specific counters for monitoring performance are described in the following table.
Counter name |
Description |
|---|---|
Available Mbytes |
Amount of physical memory in megabytes. This value is immediately available for allocation to a process or for system use. It is equal to the sum of memory assigned to the standby (cached), free, and zero page lists. |
% Committed Bytes in Use |
In Use Ratio of Memory\\Committed Bytes to the Memory\\Commit Limit. Committed memory is the physical memory in use for which space has been reserved in the paging file, in the event that it needs to be written to disk. The commit limit is determined by the size of the paging file. If the paging file is enlarged, the commit limit increases and the ratio is reduced. This counter displays the current percentage value only; it is not an average. |
CPU-specific counters
The CPU-specific counters for monitoring performance are described in the following table.
Counter name |
Description |
|---|---|
% Idle Time |
Percentage of time that the processor is idle during the sample interval. |
% Processor Time |
Percentage of elapsed time that the processor spends executing a non-idle thread. This value is equal to the percentage of time the processor spends executing the idle thread, subtracted from 100 percent. (Each processor has an idle thread that consumes cycles when no other threads are ready to run). This counter is the primary indicator of processor activity. It displays the average percentage of busy time that is observed during the sample interval. The calculation used to determine whether the processor is idle is performed by using an internal sampling interval with the system clock (10 milliseconds). On today’s faster processors, % Processor Time can underestimate the processor utilization because the processor may be spending time servicing threads between the sampling intervals. Workload-based timer applications are one example of applications that are more likely to be measured inaccurately because timers are signaled directly after the sample is taken. |
Bandwidth-specific Counters
On the Network Adapter menu, select the network adapter from which the administrator want to monitor bandwidth.
Counter name |
Description |
|---|---|
Bytes Received/Sec |
Rate at which bytes are received over each network adapter including the framing characters. Network Interface\Bytes Received/Sec is a subset of Network Interface\Bytes Total/Sec. |
Bytes Sent/Sec |
Rate at which bytes are sent over each network adapter including the framing characters. The Network Interface\Bytes Sent/Sec is a subset of Network Interface\Bytes Total/Sec. |
Reference systems case study
Estimating the capacity of Print Server is difficult and it does not adhere to a specific formula. To give administrator’s a starting point, this case study describes two reference systems that have been successfully deployed and tested by Microsoft.
Note
These case studies are for reference only. Using them will not guarantee performance. We recommend that you perform benchmarking to understand the system’s capabilities in the intended environment as the best practice for estimating the capacity of Print Server.
Reference system 1
Reference system 1 is a standalone physical server running Windows Server 2012 R2. It services approximately 1,300 users across 1,000 queues. These queues host high-end, enterprise-level printers.
Note
The Print Server performance data section later in this guide provides performance data for Reference system 1 during a five-day interval, to provide a performance system overview for memory and processor time.
Name |
Description |
|---|---|
System manufacturer |
Hewlett Packard |
System model |
ProLiant DL585 G2 |
System type |
x64-based computer |
Processor |
Dual-core AMD Opteron(tm) processor 8212 |
BIOS version/date |
HP A07, 6/27/2008 |
Total physical memory |
4.0 GB |
Total virtual memory |
4.69 GB |
Available virtual memory |
2.23 GB |
Network adapters |
Two network adapters installed |
Broadcom |
BCM5706C NetXtreme II GigE (NDIS VBD Client) |
Reference system 2
Reference system 2 is a large-scale virtual machine that is running on Windows Server 2012 R2. It covers approximately 8,000 users across 130 queues. These queues host high-end enterprise level printers.
Name |
Description |
|---|---|
System manufacturer |
Microsoft |
System model |
Virtual machine |
System type |
x64-based PC |
Processor |
Intel Xeon processor L5640 2.27 GHz 4 cores 4 logical |
BIOS version and date |
American Megatrends, Inc. 090006, 5/23/2012 |
Total physical memory |
8.0 GB |
Total virtual memory |
20 GB |
Available virtual memory |
15 GB |
Network adapters |
One Microsoft Hyper-V network adapter installed [01] |
Recommendations for deployment
The best practices recommendations that follow are based on the factors described in the previous sections, to help you achieve Print Server scalability, maximize your hardware investment, and provide the best performance.
Locate Print Server on a Hyper-V-hosted virtual machine to allow the hardware capacity to be adjusted on demand, and to provide failover clustering as needed. For more information, see System hardware configuration earlier in this guide.
Use v4 printer drivers with Print Server, and make the same drivers available in Windows Server Update Services (WSUS) or as part of the default operating system image.
Note
If the organization has a large number of Windows 7 clients, use v3 printer drivers with client-side rendering enabled for high-volume queues.
Enable Branch Office Direct Printing if feasible within the organization.
For more information, including the limitations of this feature, see Branch Office Direct Printing Technical Details.
Standardize printer models across deployments for easier set up and manageability.
Deploy printers that have been signed by Microsoft and certified by the Windows Logo Program.
For high-volume servers, consider moving the spool directory to another physical drive.
Use Performance Monitor to conduct a performance analysis on an existing Print Server to identify usage trends and bottlenecks.
Administrators can use the information in the following table as a starting point when planning deployments.
Condition |
Options |
Impact |
Suggested action |
|---|---|---|---|
Volume of print jobs |
Low/Medium/High |
High |
Review the effect of the print job, characteristics of the print job, and spool activity. For more information, see: Printing related factors |
Maximum concurrent users |
1-50, 51-200, or more than 200 |
High |
Review the effect of the client load. For more information, see: Number of clients |
Mixed client operating systems |
Windows 8.1, Windows 8, and Windows 7 |
Medium |
Review the effect of mixed client operating systems. For more information, see: Operating system of the print clients |
Hosted drivers |
Mostly v4 or mostly v3 |
Medium |
Review the effect of mixed drivers. For more information, see: Mix of drivers hosted on print server (v4 or v3 printer drivers) |
Number of printers available |
1 to 50, 51 to 200, or more than 200 |
Low |
Review the effect of the printer queue. For more information, see: Non-Microsoft software |
Print Server performance data
The following images show Print Server performance data for Reference system 1 during a five-day interval. These figures provide a performance system overview for memory and processor time.
Figure 1: Print server performance over a five-day interval
.jpeg)
Figure 2: Print server performance showing processor time
.jpeg)
See also
The following resources provide additional information about deploying Print Server.
Infrastructure Planning and Design Guide Series (Print Server for Windows)
Note
Although this guide describes Print Server for Windows Server 2008 R2, the general deployment methodology remains applicable for Windows Server 2012 R2 and Windows Server 2012.
Print and Document Services Overview (for Windows Server 2012)
Microsoft Support article, HOW TO: Move the Print Spool Folder in Windows 2000
Clustering and High Availability, Creating a Windows Server 2012 Failover Cluster
Failover Clustering Hardware Requirements and Storage Options