Updating app v applications Asian sexchat
I had initially thought it was the Antivirus software, but I removed it (I learnt long ago to remove the AV software rather than simply disabling it) and the pattern didn’t change.It wasn’t due to the computer simply being busy after a reboot because I would boot the computer, logon and wait 5 minutes before performing any tests, always waiting for the hard disk to settle before starting any timings.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.A 149MB application was used in this example, but similar results were obtained for other sized packages.Each test was run 5 times at different locations and the variations between each timing were low (so I had confidence in the figures – although see “Hot and cold timings” later on): Blimey!The customer’s existing App-V 4.6 environment did not exhibit these problems with similar sized applications.I initially thought this would be a simple networking problem to overcome – how wrong I was!
In these cases I’m referring to the transfer of an App-V 5 application from a network location (typically a SMB share or HTTP content server) to the App-V 5 client.
This is a guest article written by Simon Bond, Senior IT Consultant with Ultima Business Solutions.
In this article he details his efforts in overcoming a slow App-V 5 publishing and streaming problem he encountered in a large desktop application upgrade project.
I confirmed that I could HTTP download the “.appv” file content from the IIS content servers to the clients very quickly, at approximately 400Mb/s which isn’t bad considering the physical size of the site and the number of network switches involved.
So there doesn’t appear to be a network performance problem with the content servers or the core switches.