Home > App-V > App-V 4: Factors that can cause Performance Issues with App-V 4.x Servers

App-V 4: Factors that can cause Performance Issues with App-V 4.x Servers

For those of you still using App-V 4 (hopefully at least App-V 4.6 on the client side and 4.5 SP2 on the server side due to supportability) you may have been reading about how App-V 5 resolves a lot of limitations of App-V 4 – especially those that revolve around scalability. I dealt with many customers in support and still get questions on existing App-V 4.x deployments. The most common one revolves around keeping the existing 4.5 server(s) running optimally. I figured I would let the users out there (who are still using App-V 4.5 servers) know that I know they are still out there and remind them of the key factors that lead to performance issues

Watch the Cores and Dispatcher

App-V 4.5 runs usually on four instances of the core process (SGHWVR.EXE or SQLQVR.EXE if using the lightweight streaming server) as well as the dispatcher service. These are usually the key processes to monitor for CPU spikes. In normal operation, utilization should be evenly dispersed. In some cases you may see one or more spiked out due to likely one of the related issues listed below:

Update 4.5 Server to at least 4.5 SP2 plus these Hotfixes.

You should be running at the very least HF2 for App-V 4.5 SP2 with this hotfix being applied:

“Hotfix Package 2 for Microsoft Application Virtualization 4.5 SP2: March 2011” http://support.microsoft.com/kb/2507096/en-us

The App-V 4.5 Management Server should be updated to at least version plus the following should you be working with SQL database mirroring:

“FIX: An App-V 4.5 SP2 server cannot recover when an application virtualization database fails over” http://support.microsoft.com/kb/2873468/en-us

In addition to these hotfixes, you may want to also include this out of band fix which involves adjusting the back end database. I personally worked on this issue while I was in support and I can tell you that this fix makes a tremendous impact but must be done with caution:

“A publishing refresh might time out and return the 0A-10000005 error code on an App-V 4.5 client” us

Check the Database Values of Server Objects

If you are running with a less than optimal amount of cores or suspect performance issues after pre-creation of server objects prior to scaling out, you could be falling victim to the default limited values that come with pre-creating server objects. Check out this article to resolve it: http://blogs.technet.com/b/appv/archive/2010/05/10/pre-creation-of-server-objects-may-yield-certain-sub-optimal-values-in-the-app-v-sql-database.aspx

Large SFT-Server.LOG file

When the server log gets too large or is set to a high verbosity level, it can impact performance. Regular maintenance of the log files (planned purging) as well as setting an optimal verbosity level (2 likely) will prevent this from occurring. The logging level for the Application Virtualization Management Server can be changed in the registry at:


Keeping it at a level no greater than 3 is recommended.


These tables can grow very large if unchecked, be it intentionally (i.e. no SQL agent running, running SQL Express) or unintentionally. The background of this long standing issues can be found here: http://blogs.technet.com/b/appv/archive/2008/08/04/troubleshooting-softgrid-database-growth-issues.aspx

The trouble is that you might be encountering this issue because the SQL jobs are not running properly or at all. Especially if you are running a more recent version of SQL Server or have just migrated databases. The Technet gallery has some scripts that can help you fix these jobs should they be failing:

SQL script that creates the SQL 4 Jobs that are required by the App-V DB: http://gallery.technet.microsoft.com/SQL-script-that-creates-b6345446

SQL script to allow App-V Check Usage History job to run on SQL 2008: http://gallery.technet.microsoft.com/SQL-script-to-allow-App-V-959bc1d4

SQL script to allow App-V Check Usage History job to run on SQL 2008 #2: http://gallery.technet.microsoft.com/SQL-script-to-allow-App-V-f656ac69

Limitations of Ephemeral Ports Used for RTSP

Delays in launching and launch timeouts can be traced to a defining limit in the amount of service requests an App-V management or streaming server can hold. This is due to the ephemeral port range defined by the default App-V 4.5 server configuration – http://blogs.technet.com/b/gladiatormsft/archive/2011/08/31/how-to-adjust-increase-reduce-the-rtcp-rtp-port-ranges-for-use-with-rtsp.aspx

Streaming Performance due to improperly configured Offloading or Block Size

Both the Underlying TCP offloading stack configuration and the block size for RTSP can be factors to slow streaming performance:

TCP Offloading Information: http://support.microsoft.com/kb/951037

RTSP Streaming Issue with block size: http://blogs.technet.com/b/gladiatormsft/archive/2011/11/28/the-default-block-size-of-64kb-in-app-v-4-6-and-later-may-cause-slow-streaming-with-certain-network-configurations.aspx

As App-V 4.5 is in extended support, the likelihood of new problems is low but not impossible with App-V 4.6 SP3 running on modern operating systems. However, I would recommend you verify the above before contacting support.

Categories: App-V Tags: , , , , , ,
  1. hassan sayed issa
    July 20, 2014 at 4:34 pm

    App-V Scheduler will store this application in a XML file on the package source location. There is no need to configure this on every machine or inside your image. You can also directly edit the XML file if you like. When the machine boots the App-V Scheduler service will deploy all packages to your machine and after that read the XML file for applications to pre-launch. If there are applications found, App-V Scheduler will launch them all together and keep them open for 60 seconds. After that the applications are closed. When the first users log in to the machine and launch the application, it will open much quicker because application assets are already present in memory.

    Mount selected packages
    Besides the option to mount all packages, App-V Scheduler can also mount only selected packages. This means you can use Shared Content Store mode for all your packages but select specific packages which should be fully mounted inside the cache so they are always available or to reduce network load to the content share.

  2. Allan
    June 9, 2015 at 1:26 am


    I have a question about SFTgetPorterDCRefreshXML. I know App-V 4.5 is quite outdated but we still run it in our company 🙂

    We experience that the above stored procedure inserts 11.000.000 records in our tempdb once every minute. Have you you heard about that issue. Is it normal or how do we reduce the records or frequency. We are running the version from https://support.microsoft.com/en-us/kb/2445212

    Thanks in advance

    • Allan
      June 9, 2015 at 4:52 am

      We figured out that we had a lot of applications and FTA’s that could be deleted. That reduced the output dramatically.

  1. August 16, 2014 at 4:43 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: