VMware Horizon Community
szilagyic
Hot Shot
Hot Shot

Slow sending print jobs with ThinPrint to the local printer

Hello:

We are expanding our use of VDI here and recently came across an issue specific to printing.  Remote users were complaining about slow printing and after some investigation we are finding that print jobs are somewhat slow at transferring from the VM's printer queue to the Thin Client's printer queue.  All of our printers are installed directly on our Thin Clients (Windows 10 LTSB), and print direct to the associated printer on their local network via TCP/IP.  The local printing fro the Thin Client to the printer appears to be fast as expected.  Users are printing to the printers in their VMs that use the ThinPrint output gateway, which then gets sent down over the WAN to the local Thin Client's printer, which is connected to its local network.

When we print some test documents, we see the jobs queue up instantly in the VM to their printers (that use the ThinPrint output gateway).  But, after that there is a lag as the jobs take anywhere from several seconds to up to a minute at times to appear in the queue of the printers on the actual Thin Client itself.  To my knowledge we do not have any bandwidth issues at this location. Latency is around 30 ms.  The print jobs are around 150KB each in size (relatively small).  This is a new location so we don't have a benchmark on speed, but I would think it should be really fast for small print jobs like this.

What's the best way to go about troubleshooting this further, and are there any settings we can try?  Any help would be appreciated.

Thanks.

Reply
0 Kudos
9 Replies
grossag
VMware Employee
VMware Employee

What version of Agent and Client are you running? Try comparing printing performance over PCoIP and Blast on the same client.

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

What version of Agent and Client are you running? Try comparing printing performance over PCoIP and Blast on the same client.

Sorry for leaving out that detail.  We are on the Horizon 7.0.3 agent and 4.3 client.  We have not upgraded either side because the environment has been very stable.  However we do have a project to upgrade it in the near future.

Also, we cannot switch to Blast in production for a permanent solution, as our tests were suboptimal with screen artifacts and such that we stuck with PCoIP and we force this across for all of our clients.  I thought ThinPrint worked outside of Blast and PCoIP anyway, as its own service.  Does it sit within the display protocols?

Thanks for your help.

Reply
0 Kudos
grossag
VMware Employee
VMware Employee

ThinPrint goes over virtual channel, which is part of the display protocol traffic. You may want to try Blast anyway as part of your speed comparison, just to have the data.

I will ask around about printing performance, but I suspect that the answer may not be what you want to hear: upgrade to 7.4 and switch to Blast because of the adaptive transport that was added recently. But I want to hear from the engineers first before recommending this.

Reply
0 Kudos
grossag
VMware Employee
VMware Employee

Also, what is the OS of the View Agent VM? Are you doing VDI (desktop OS) or RDSH (server OS with RDSH role installed)?

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

The OS is Windows 10 build 1607 for the Agent VMs, and Windows 10 1607 for the Thin Clients as well.  We are not doing RDSH at all, it's straight VDI.

I will see if we can try a test client with Blast.  Currently, I do not have a good way to do this as we have all Thin Clients deployed at our remote locations, locked down with GPOs.

That is good to know on 7.4 and the new enhancements of Blast, will definitely be something we will eventually need to look at.  Unfortunately this would require changes to our production environment and as such takes a while for lots of testing, etc. first.

Thanks again.

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

Is there anything else we can check from the Thinprint side of things?  The problem is very sporadic here, and as far as I can tell it's not tied to network or bandwidth utilization.  I was starting to look through the Thinprint settings and documentation, but I was hoping there were some general things we could do for optimization, or best practices??  By default it looks like Thinprint has some optimization settings already set.

Thanks.

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

I've done some more testing and Blast doesn't seem to have helped the issue.  After some extensive testing, the issue almost appears to be on the virtual desktop side but only to the printers that are there passed through from ThinPrint.  Some jobs take longer time to queue up than others.  When the job takes longer, it will show up in the queue as for example at 5.0 MB in size and sit there.  Then... shortly after, the size shows as 5.0/5.0 MB and then the job is moved out and transferred to the Thin Client very quickly from there forward.  I'm not sure if this helps.

I also did another test by using a full clone VM.  I print to the same printer that is appearing via ThinPrint, and it's slow queueing up.  If I install that very same printer local inside the full clone, it's very fast.  This again shows me that the issue is clearly only when using a printer that is from ThinPrint, are we seeing the issue.

Unfortunately we are stuck on this one at the moment and it's affecting our production work. 

Reply
0 Kudos
szilagyic
Hot Shot
Hot Shot

I have submitted a ticket for this, as we are needing to resolve this issue.  I will post any useful details back here.  Thanks.

Reply
0 Kudos
sohailm6
Contributor
Contributor

Hi

Did you find a resolution to the issue

Sohail

Reply
0 Kudos