Breezy is designed to be able to handle any volume of printing, from tens of documents to millions. Individual components have certain throughput limitations, but the system can scale horizontally as your usage grows. This article describes the throughput expected from each component, in order to help you plan your deployment.
To vastly oversimplify, and assuming sufficient bandwidth:
- Cloud deployments have no significant performance limitations.
- Hybrid and On-Premise deployments can process about 5-10 documents per minute, per Rendering Engine.
The above is an estimate, so please read on for much more detail.
Connector (All deployment models)
The Connector itself has no theoretical limit on the number of printers it can support. The Connector splits large printer lists into batches when providing updates to the Controller, and takes advantage whenever possible of redundancies in printer data (for instance, if two printers share the same driver information, the Connector will send that data only once). That said, Windows imposes certain constraints that vary significantly with the type and variety of printer drivers, the amount of traffic through the server, whether the Connector host is also serving as a general-case print server for the organization, etc.
We have seen many deployments with hundreds of printers per Connector with no issues at all and some customers with several thousand printers in production use on a single Connector. Your specific case will vary, but as a rule of thumb we would recommend that you not exceed 5,000 printers per Connector.
There are a number of factors that can affect Windows print server performance in general, and we customers to consider Microsoft's guidance here when capacity planning. Two useful links:
Connectors fetch and print each job asynchronously, and can currently handle up to 10 jobs at one time (this limit may be changed in the future). Most jobs are processed by the Connector (meaning downloaded, decrypted, and sent to the Windows print spooler) in under five seconds., which means that a single Connector can typically handle an average of ten documents every five seconds if operating at full capacity.
Most of the time, this capability is not needed, because sustained print volumes of that level are very rare even in large deployments. In other words, you may have fifteen print jobs appear at a Connector all within one second -- but if that happens, the probable-case scenario is that the first 10 print within 5 seconds, the remaining 5 have to wait 5 more seconds for the Connector to process them, and while those are being processed the Connector still has capacity to process additional jobs should they arise.
We have had clients operating in large production environments for years without a single "collision" of this type, but if you begin to experience performance bottlenecks due to document collision at the Connector, you can address them by simply adding another Connector.
(Incidentally, if you have two or more Connectors configured in a cluster anyway for high availability, the throughput described above is effectively multiplied by the number of Connectors in the cluster.)
Rendering Engine (Hybrid and On-Premise only)
Unlike the Connector, the Rendering Engine can only process a single document at a time, due to threading limitations in the underlying applications (Office, Acrobat Reader, etc.) called by the Rendering Engine service. Moreover, most jobs take between 5 and 10 seconds each to render.
What this means in practice is that for each Rendering Engine in a cluster, the cluster can typically process 6-10 documents per minute. The Rendering Engine is the principal limitation on throughput in most deployments.
Processing Engine (Optional for Hybrid; required for On-Premise)
The Processing Engine is not currently multithreaded, but can process jobs faster than the Rendering Engine can, so it is not likely to be a bottleneck. You can expect a single Processing Engine to take only 2-5 seconds for a typical job.
Other Components (Hybrid and/or On-Premise Only)
All remaining components (Controller, Buffer, Queuing Service, Dashboard) are deployed as IIS web services and automatically benefit from the multithreading capabilities of the web farm into which they are deployed. The throughput of the system is wholly dependent on the resources allocated to it by the IIS container into which it is deployed.
Breezy can accommodate any volume of print requests; it's just a matter of deploying the right number of nodes to suit your needs. Fortunately, since you can add new nodes to any cluster at any time, you can start small and add more if you find that you're hitting performance bottlenecks -- and of course, we're always happy to help you find ways to improve performance across your deployment.