Scaling your Web Print environment

When using Sandbox mode, we recommend a minimum of two Web Print servers. Using only one Web Print server causes a single point of failure and potential bottlenecks. Best practices in server management recommend building redundancy into your network and monitoring the health of your environment.

However, two Web Print Servers might not be enough for sites that see very high Web Print throughput. While you can simply continue to add Web Print Servers until the Web Print performance during peak printing hours is acceptable, sites with particularly demanding throughput will benefit from using statistics for their capacity planning.

Analyzing these statistics will help you plan your Web Print deployment. While we recommend a minimum of two Web Print servers as a starting point, the unique demands and performance characteristics of your environment are the key drivers in determining what you need. You will need to balance the acceptable average wait time that is appropriate for your users, against the resources needed to deploy additional Web Print servers.

Determine the number of pending Web Print jobs

To statistically determine the number of Web Print servers you need to adequately handle your throughput, you should evaluate the number of pending jobs your system has awaiting Web Print processing.

The Print System Health interface provides a monitoring endpoint that tracks the number of pending print jobs in a Web Print queue at a specific point in time. You can use this data to determine the average number of pending jobs as well as the maximum number during peak periods. For more information about this endpoint, see Base system health URL .

A direct link to this endpoint is available in the Admin web interface:

1. Select Options > Advanced. The Advanced page is displayed.
2. In the System Health Monitoring section, click the Detailed system information link.

The attribute is webPrint > pendingJobs.

You can use a monitoring tool to accurately track how this value changes over time. A large number of pending Web Print jobs that rarely or never varies during printing hours, might indicate that users are experiencing consistently high wait times. If, however, the number of pending jobs peaks at random points in time, the average wait time might not be an issue. You can test if this is the case by submitting a number of test Web Print jobs during a peak print period, and timing how long it takes for the job to process. Good test documents would be a one page PDF and a one page Microsoft Word document.

1. Log in to the User web interface.
2. Submit a test Web Print job.
3. On the Web Print page, time how long it takes for each job to progress in the queue from having a Status of Queued in position to Finished: Queued for printing.

Averaging out the wait times incurred for test jobs during these periods of sustained high load provides an idea of the average time it takes to process a Web Print job in your current environment.

View historical Web Print trends

Historical data is another good tool for tuning your Web Print scaling setup. The number of jobs processed during key periods (for example, during peak times), will provide you with an estimated mapping of job numbers to average queue length. You can use this value to estimate future average queue lengths based on expected changes in the Web Print job load.

To generate a Web Print report:

1. Select Reports > Printer.
   The Printer Reports page is displayed.
2. In the Print Log Reports area, for the Print logs report, select Adhoc from the drop-down list.
   The Ad-hoc Report: Print logs page is displayed.
3. In From date, enter the start date for the period you want to run the report.
4. In To date, enter the end date for the period you want to run the report.
5. In Print method, select Web Print.
6. In Report Format, select CSV.
7. Click Run Report.
   The report will be a spreadsheet containing information for all Web Print jobs performed over a specified interval of time.

It is a good idea to also compare the average wait times for jobs that can be processed by any of your Web Print servers (for example, PDF files) versus those that can be processed only by servers equipped with additional licensed software (for example, Microsoft Word documents). If jobs that require licensed software are taking significantly longer than those that can be processed by any Web Print server, you might want to consider purchasing additional licenses for the software and deploying it to a larger proportion of your Web Print servers.

You can use this report to determine the proportion of Web Print jobs of each file type, which can indicate if you need to license additional software for your Web Print servers. To do this, generate a separate report for each file type by entering values, such as .doc, .pdf, .xls, .jpg, in the Document name field. Sum the data provided in the Total Printed Pages or Size (KB) columns to give you an idea of the typical complexity of submitted jobs; a higher file size or page count indicates that a printed document was more complex, and thus would take longer for a Web Print server to render than a smaller job.

A real-life Web Print scaling example

West Face University has been using Web Print in Sandbox mode with a single Web Print server for some time. This Web Print server is a virtual machine, and supports Microsoft Office. The IT team have noticed that students and other staff sometimes complain that their Web Print jobs take longer than expected to print, particularly in the afternoons. Not only that, but they once experienced an outage of their Web Print server, which prevented any Web Print jobs until the outage was resolved.

Initially, they deploy one additional Web Print server virtual machine. Microsoft Office is not installed on this machine, as the IT team currently do not have any available licenses, and would like to be sure that more licenses are needed before submitting a purchase order. A monitoring tool is set up to track the number of pending Web Print jobs, so that further adjustments can be scoped out.

The monitoring tool reveals that the number of pending jobs is often below five in the early hours of the morning, only intermittently jumping up above this level. However, the number climbs sharply in the early afternoon, reaching as high as 20, and remaining above 10 until evening. They sent some small test print jobs during this peak period over a number of different days. These test jobs seem to take on average of around 10 minutes to finish processing, which immediately strikes the IT team as excessive, given that they know the students often walk a fair distance between rooms to collect their prints before returning to their areas of work. If their prints are not waiting for them when they get to the printer, this would be quite frustrating for them, and would explain many of the complaints they have been receiving.

They also ran a few “Print logs” reports to determine the total number of Web Print jobs processed during the peak periods. The average number of jobs submitted during this peak each day is about 60. With two Web Print servers handling 60 jobs, they now know that each server is likely taking around 30 jobs during this period. With a suspected average wait time of 10 minutes per job, it could be estimated that 300 minutes (or five hours) is how long this peak may last, which roughly fits with what has been observed.

They would like to decrease the average wait times during this peak to five minutes. 60 jobs across five Web Print servers seems like a good bet; each server would have 12 jobs to process during the afternoon, and a 2.5 multiple increase in available Web Print servers should bring average wait times down by at least somewhere around half.

But before introducing more Web Print servers, it is also considered that only one of the current Web Print servers has Microsoft Office installed in order to handle Office document printing. More “Print logs” reports covering the peak printing periods are generated, this time with distinct reports being created for common Web Print filetypes, such as “.pdf” and “.doc”. Upon inspection, it would appear that close to 60% of all jobs commonly submitted during the peak printing period are Microsoft Word documents. As three-fifths of these jobs require a Web Print server capable of printing Office documents, two additional licenses are purchased, so that Office can be installed on to three out of the five planned Web Print servers.

The three additional Web Print server virtual machines are now deployed. Initially, average wait times only drop to around eight minutes, but when the extra licenses are used install Office to two more Web Print servers as planned, average wait times decrease to just under five minutes, meeting the expected target.

However, the IT team know that a large number of complaints about the Web Print service were received during the exam period last semester. Wanting to know if they can expect average wait times to remain stable, more reports are generated, comparing the average number of daily Web Print jobs during past exam periods to the numbers now being observed. They discover that the number of PDF documents being printed per day skyrockets during each exam period.

With the number of jobs increasing by 50% during exam time, and these additional jobs being almost exclusively PDFs, the IT team plans to temporarily provision an additional two Web Print servers at the start of the next exam period. They do not need additional Microsoft Office licenses, and they will then shutdown these additional servers at the end of exams. This way, the extra resources will be used only when needed. They will monitor, track, and alarm the Web Print pending jobs statistic, to anticipate growing needs, and detect any sudden Web Print issues. They will also periodically generate reports on the number of Web Print jobs, knowing that around 60 Web Print jobs with five Web Print servers can be expected to have average wait times of five minutes.