Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
In previous versions of Windows, clients with remote connections would often initiate network traffic to retrieve remote information from a print server, resulting in a resource-consuming call to the server. This behavior was more significant when Client Side Rendering (CSR) was used that caused increased communication with the remote server. Many applications use certain APIs to query the print spooler for print information at startup, at document creation time, and when displaying available fonts. This often resulted in visible delays or hangs in the applications from the user’s perspective. In Windows 7 and Windows Server 2008 R2, the performance of many spooler API calls has been improved through more aggressive caching that will reduce the remote server calls and improve end user performance.
In general, the intent of the enhancements has been to decouple applications that use client print APIs (winspool.drv) from the print server to avoid application UI delays. Some of the APIs that are used by major client applications such as the print dialog and Microsoft Office have had their caching behavior improved. OpenPrinter, EnumJobs, and some forms of GetPrinterDriver are the main APIs that will see caching improvements.
The CSR provider maintains a cache of print connection data for remote connections. This cache is persisted in the registry and loaded at provider startup. The cache follows a “pull” model and in general operates asynchronously. Calls requesting remote connection data are serviced from the local cache immediately where possible, and an asynchronous work item is queued that will synchronize with the remote server if necessary. Only in the case where the remote data is not cached locally will the call go over the network synchronously. The asynchronous synchronization with the remote server is done only periodically; most cache entries have an expiry time of 120 seconds. Cache coherency is enforced by checking Change IDs associated with both the local cache and the remote connection. If a request is made for cached data last accessed over 120 seconds ago, the remote Change ID will be compared to the local one, incurring a single RPC call of overhead. If they differ the cache will be updated from the remote server, incurring one or more RPC calls.
The table below shows the caching characteristics of common print APIs. The cache refresh interval for each caching mode is described in the next section.
Caching behavior of key print APIs
Changed from previous versions ?
Cached. Client spooler still initiates network traffic for “Set” API calls and opens the remote printer handle when absolutely necessary. OpenPrinter learns the server response per access mask; this it may block while populating the cache with results for masks it hasn't seen before.
Cached. Certain operations, like creating a job, cause an update of the EnumJobs cache.
Cached when there is a printer connection to the target server.
Yes, but only for level 8 calls
Cached for both server and printer handles when there is at least one printer connection to the target server. Not cached otherwise.
Cached when there is a printer connection to the target server. Not cached otherwise.
Cached for Level 4. Level 4 only returns data when there are print connections.
Cached based on flag. Calls with ‘NO_CACHE’ flag will not be cached. Calls without the ‘NO_CACHED’ flag will be cached.
Two registry key values control the cache refresh behavior for print APIs. Caching mode “Normal” is controlled by the following registry key value and defaults to 120 seconds:
Caching mode “Volatile” is controlled by the following registry key value and defaults to 0 seconds: