Updating app v applications
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.
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.App-V 5 is taking 15 times longer than App-V 4.6 for this package. I’ve blown a whole (long) day investigating the problem and have eliminated all of the simple explanations and still don’t know what is going wrong. I would have been SO happy at this point if it had been an App-V 5.0 sp1 bug.The phone is starting to ring a lot more as well 🙁 [vc_widget_sidebar sidebar_id=”ups-sidebar-blog-offer-app-v”]The customer has a number of different types of client hardware and a few different “builds” and all exhibit the problem. )I try the original App-V 5.0 client instead of the SP1 client I’ve been using up till now. I build a clean Windows 7 sp1 PC and put in an AD OU with inheritance blocked so I don’t get any GPOs. I try both Windows 7 x86 and x64 and still get the problem. 🙁I can’t see how it can be a client network card / network stack problem because a manual “.appv” file copy is so quick, but I try anyway because if I don’t do it then somebody will ask if I’ve tried: I turned off TCP auto-tuning on the client with:and nothing has improved.I also had some publishing and content servers hosted on VMware ESXi so I could eliminate Hyper-V from my investigation (as the problem was equally bad on VMware).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.