Those doing planning might well be interested in these stats from a real-world ThinPrint deployment in respect of how well it compresses jobs.
We started by testing a job typical of the users; a PDF consisting of scanned black and white pages. He we measured the data passed on the network for each of ThinPrint’s compression settings.
| Setting | Job size (%) | Quality |
|---|---|---|
| None | 100 | Original |
| Optimal | 90 | Near perfect |
| Maximum | 58 | Good; useable |
| Extreme | 19 | Medium; readable |
| No images | Not tested |
Pretty decent, we thought, for a test document that is all A4 images. Now to try a pilot.
One all VDI office has 63 users. All of them use Wyse terminals, so using the ThinPrint compression built in to VMware View is not an option. We wanted to test whether or not ThinPrint was worth buying. Of the 63, 40 use only ThinPrint printers. For them, their print jobs go from VM to the .print Engine for VMware View in the datacentre, to the Windows print server in the office. The others print direct from their VDI desktop hosted in the datacenter to the Windows print server in the office.
There are four printers, three HP A4 monochrome lasers and one Xerox A3 colour printer (with the colour drums removed…). Each printer is accessible via ThinPrint and directly. ThinPrint is set to ‘Optimum’ compression.
I dragged out the stats on the amount of print data transferred for each of six consecutive business days:
| Day | ThinPrint data (b) | Uncompressed data (b) |
|---|---|---|
| 1 | 26340958 | 234708630 |
| 2 | 67133657 | 121979299 |
| 3 | 113838547 | 189902846 |
| 4 | 46067764 | 145088982 |
| 5 | 42741516 | 155059692 |
| 6 | 55769733 | 172241368 |
Not that interesting in and of itself, unless you know how many jobs were sent by each method, but it gave me an idea of the degree of variability. So then I chose to look into day 6 a bit further.
| Type | Data (Kb) | Jobs | Avg. size (Kb/job) |
|---|---|---|---|
| Original job as listed in event viewer | 1556467 | 277 | 5619 |
| Uncompressed print data over network | 168204 | 186 | 904 |
| Compressed print data over network | 54462 | 277 | 196 |
| Total: | 463 |
So over that day over a whole range of print jobs, the average ThinPrint job was 21% of the size of the normal job. Pretty good – and much better than the 90% we experienced with the single test document. This shows if you want to test its performance, use a real world selection of documents.
The real question is, if I switch all the office to ThinPrint, or abandon it altogether, what is my predicted print data for a day?
| Type | Jobs | Avg. size (Kb/job) | Predicted data (Kbits) | Flat rate (Kbps) |
|---|---|---|---|---|
| Uncompressed | 500 | 904 | 3617300 | 125 |
| Compressed | 500 | 197 | 786464 | 27 |
Hmmm. The amount of data transferred over the line would be equivalent to a constant background rate of 125Kbps. I know my print traffic is peaky, but QoS settings on the link will smooth that out. That’s just 6% of a 2Mbps line for 60 people. Hardly a killer. In fact, since we can only get 30 RDP sessions on a 4Mbps line, I will need 8Mbps of capacity for my 60 users, making the print traffic just 3% of my line.
What about the other features of .print Engine for VMware View? We pretty quickly had to abandon driver-free printing to get features such as double-sided printing and A3 to work, and none of the other features have been of any practical use to me. You might find the ability to limit the print traffic to a certain rate useful if you don’t have that level of control over your line.
At €23 per user, and my SDSL line at €200 per month, it would take me 19 years to recoup my investment in ThinPrint. I think I’ll pass, thanks…
Ian
vSphere 4.0 Quick Start Guide