App-V 5 und der Fall des langsamen Starts bei großen Paketen


Hallo zusammen,

Es gibt immer wieder mal Szenarien in denen man feststellt das ein Anwendungsstart der lokal (ohne App-V) ein paar Sekunden dauert in App-V gefühlt ewig, aber doch einige Minuten dauert.

Meist trifft das bei Paketen zu die recht Groß sind, ich möchte in diesem Post einen Fall exemplarisch aufbereiten und Hilfestellung geben wie man damit umgehen kann.

Das erste was man macht wenn man ein Paket hat (meist sind es ja Anwendungssuiten) aus dem Anwendungen nut sehr langsam starten, ist dass man es mit einer PVAD Virtualisierung versucht - das bringt was, aber eben auch nur ca. 15%.

Werden wir mal konkret, ich durfte mir vor kurzen die Aspentech Suite ansehen wenn man in dieses Paket eine CMD gestartet hat so dauerte der Start einer CMD über 70 Sekunden.

Warum ist das so?

Nun im Gegensatz zu App-V 4, wo wir einen Launcher Prozess hatten, haben wir in App-V 5 unsere Subsystem welches sich in den Prozess "hooked". Diese hat dann die Aufgabe die virtuelle Umgebung in diesen Prozess Mappen.

So in unserem Fall haben wir mehr als 70 Sekunden bis das CMD Fenster sichtbar ist, Im Windows Performance Recorder kann man das etwas grafisch aufbereiten:

70secs

Man sieht also dass der App-V Client mit kurzen Unterbrechung von ca. 8 Sekunden, die ganze Zeit beschäftigt ist und erst am Schluss der eigentliche Prozess gestartet wird.

Wenn man den selben Test macht mit deaktivierten VFS dann sieht das ganze so aus:

VFSDis

Man kann also behaupten das ganze ist ca. 10 x Schneller.

Also schauen wir uns man das VFS genauer an:

VFS

Man sieht das ein Großteil im Common Appdata liegt und wenn wir darauf unseren Fokus legen sehen wir:

Explorer

Über 100 000 Dateien und über 3000 Ordner - das muss erst mal in das Prozess Object gemapped werden - das dauert einfach.

In den aktuellen App-V Versionen bis App-V 5.1 HF4 gibt es keine richtig gute Lösung für diese Anwendungen.

Bei diesen Fall haben wir uns nun für folgendes Vorgehen entschieden:

Nach dem Sequencen als VFS Paket haben wir den /die Ordner unter Common Appdata aus dem Paket exportiert und diese(n) dann aus dem Paket entfernt.

Auf dem Client haben wir diesen Ordner dann erstellt und den Inhalt nach nach c:\Programdata\ORDNER kopiert, da wir das Paket so editiert haben das dieser Ordner nicht mehr im Paket ist fallen alle Aufrufe in das Native Verzeichnis. Somit müssen diese ganzen Dateien und Ordner nicht mehr gemappt werden. Somit startete die CMD.EXE nun innerhalb von 2 - 3 Sekunden. Wichtig ist hier nicht den allerersten Start zu messen da hier noch die Registry gestaged wird (das passiert aber nur einmal) also hat man ab dem zweiten Start ein deutlich besseres Ergebnis als zuvor.

Da es sich bei den Dateien die wir lokel legen wirklich nur um Dateien handelt (reiner Copy Job) - werden diese jetzt etweder gleich mit in Image / per CM als Abhängigkeit oder in einem Add Script verteilt.

Man kann hier von einer Schwäche im Design reden, und wir versuchen in einer kommenden Version dieses Verhalten zu optimieren.

Ich hoffe ich konnte hier etwas helfen, denn es gibt ja noch einige Kandidaten da draußen sei es  nun Aspentech Suites oder MatLab etc.

Schönen Gruß

Sebastian Gernert - Escalation Engineer App-V

 

 


Comments (2)

  1. tim says:

    Assuming majority of files are under C:\ProgramData\SomeSubFolder natively, setting the PVAD to that folder might also do the trick.

    1. S Gern says:

      Hi Tim,
      well - no.
      No because even PVAD to that Folder need to be mapped into the Process Object so that hooking can be done... (we try that and get 15% Improvement) which is ok but not enough by that long time.

Skip to main content