First published on MSDN on Jul 11, 2016
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:
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:
Man kann also behaupten das ganze ist ca. 10 x Schneller.
Also schauen wir uns man das VFS genauer an:
Man sieht das ein Großteil im Common Appdata liegt und wenn wir darauf unseren Fokus legen sehen wir:
Ü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
Microsoft