Updating app v applications

Rated 4.20/5 based on 553 customer reviews

A virtual client desktop on the same Hyper-V server hosting a publishing and content server also experienced the same problems, so that pretty much eliminates any physical switches.

Yes, I had reconfigured the client so that it was definitely getting its content from the content server on the same Hyper-V host.

When a user launches an App-V 5 application, this procedure takes place behind the scenes and the App-V 5 application will generally launch before the background streaming has completed (depending on Feature Block 1), although if using a hard disk, the disk IO is generally so high that the application won’t perform well until streaming has completed.

I use the phrase “mounting” a lot because the Power Shell command to 100% cache an App-V 5 application is “Mount-App VClient Package” although it performs the same streaming / download procedure that would take place if a user simply launched an application. Typically I assign more RAM to the IIS content servers these days and make use of IIS caching, but I didn’t know about that at the time.

So the problem doesn’t lie with IIS or my choice of HTTP streaming (which had already been questioned by a few on-lookers).

The table below gives an indication of how bad the App-V 5 streaming is compared with simple file copy and a similarly sized App-V 4.6 app.

I confirmed that I could use Internet Explorer to HTTP connect to the publishing server TCP port and get an XML list of packages available to the user and that this connection was fast. So there doesn’t appear to be a problem with communications to the publishing servers and this additionally confirms that the performance of the publishing servers appears to be adequate.

I remove Anti Virus software and still get the problem. (actually I wasn’t – I should have checked if it was an AV problem right at the start and would have looked like an idiot if it was. I was hopeful on this one because the customer was using x86 almost exclusively due to medical hardware driver requirements / limitations, whilst I generally only use x64. NOTE: I didn’t expect it to anyway because firstly the NIC doesn’t support it (checked on the Vendor website) and Netstat -t output shows “In Host” for offload state for all connections so that confirms that no offloading is being performed. I discovered that I would get different (faster) timings if I mounted (100% cached) an App-V 5 application, then removed that package, confirmed it was indeed deleted from the cache and then published and mounted the package again.

I build a Windows 8 x64 client and manage to shave about 2 seconds off the time when using SMB3 as opposed to SMB 2.1 or HTTP. These faster timings would remain until I rebooted.

App-V 5 streaming performance is approximately the same at all times of the day, equally bad on clients connected to different edge switches and on a client desktop connected to the core switches, so if there is a network switch problem then it is at the core.

Network utilisation and CPU usage of the core switches is confirmed to be below 25% so it isn’t looking like a network switching problem, but we’ll keep monitoring the stats.

Leave a Reply