On App-V 5 Performance

You may have heard that I am working on a book.

It started as a White Paper to help explain how the different caching options in App-V 5 work, to help customers with their questions on how to deploy. But the scope became more book-like, so it will become an e-book.

I have done a lot of testing, and the results are not pretty. As in some really ugly results. Keep in mind that I did not test production scenarios; these were very isolated tests designed to magnify performance differences. Also, the testing was performed against the 5.0 SP2 Beta release, but it confirms concerns that I have heard from customers with the current release also.

In fact, the test results are so bad that I want to share some potential conclusions here, before I even finish the book. Don’t ask me for details. But here is what I’m thinking.

• Multi-CPU systems perform App-V File I/O poorly. As most VDI desktops are deployed today as Single CPU, this is not an issue for those deployments. Desktop/Notebook systems beware. Testing on an RDS system was not performed (at this time), but it is likely that since the poor Windows 7 performance appears to be due to design flaws, they are likely present in RDS as well.
• Shared Cache Storage (SCS) mode should probably not be used at this time. This should change with a few fixes from Microsoft, but right now it is not ready for prime time.
• When App-V package contents are cached in memory (the stand-by lists), performance is good in all scenarios. Loading up on memory with App-V 5 may be the best advice at this time.
• Full pre-caching of packages produce the best performance when apps are not already cached in memory, with the downside of chewing up additional storage space over SCS. Scripting a pre-cache is best, using background streaming 2nd best. Note the word “Full” at the beginning of this item. Partially cached files perform the worst.
• Because of the advice above, how you optimize the package may not be important. If anything, the old advice of packing everything into Feature Block 1 (now done by selecting the checkbox on the streaming optimization page of the sequencer) might be the better practice for now. This ensures that if the package is published, it will be fully cached, but is not recommended if using the App-V Server to publish due to the impact when publishing (Note: I didn’t do any performance on publishing, but this is already understood as a problem).
• If you are currently using App-V 4.6, don’t be in a hurry to convert over. And certainly not without testing performance in production like scenarios. Get packages ready and do your own testing. And give Microsoft a chance to make improvements to App-V 5.