Mit dem Siegeszug des digitalen Arbeitsplatzes während der Pandemie, hat auch die Collaboration-Plattform Microsoft Teams einen regelrechten Senkrechtstart hingelegt. Denn Microsoft Teams ist anders als alle bisher bekannten Werkzeuge für die interne und externe Zusammenarbeit. Es ist deutlich umfassender, bietet es doch neben den allgemeinen Kommunikationskanälen wie Video-Konferenz, Telefon und Chat auch die Möglichkeit zum Dateiaustausch untereinander, zur Ablage von Notizen und zur breiten Einbindung von Dokumenten, Webseiten und Anwendungen. Was den Anwendenden freut, ist jedoch das Leid der IT-Abteilung. Denn hinter dieser Funktionsvielfalt steckt ein technisch hochkomplexes System, wodurch häufig Performance-Problemen entstehen.
Inhaltsverzeichnis
- Technischer Aufbau von Microsoft Teams
- Performance-Messungen
- Ansatzpunkte zur Optimierung – Was kann ich tun?
- Fazit und Ausblick
Technischer Aufbau von Microsoft Teams
Aktuell verwendet Microsoft Teams Electron für den Unterbau. Dabei handelt es sich um ein Entwicklungsframework, welches verschiedene moderne Webtechnologien wie JavaScript, HTML und CSS in sich vereint. Es ist bei Entwicklern insbesondere aufgrund seiner Flexibilität beliebt, verbunden mit der Tatsache, dass sich die Anwendung auf vielen Betriebssystemen sowie auch als Webapplikation betreiben lässt – ganz nach dem Prinzip „Write once, run anywhere.“ Diese Architektur hat jedoch auch ein Defizit; und zwar der wohlbekannte Umstand, dass alle auf Electron basierende Anwendungen generell als „Speicherfresser“ bekannt sind. Dies ist selbst Microsoft bewusst, denn die offizielle Teams-Dokumentation liefert Auskunft darüber, warum das so ist.
Abb. 1: Technischer Aufbau von Microsoft Teams (Quelle: Microsoft)
Für die Darstellung der Anwendung nutzt Electron Chromium als Rendering Engine. Dabei unterscheidet sich das Verhalten von Chromium nicht sonderlich von dem seiner Namensvetter, die allgemein als Browser verwendet werden (z.B. Google Chrome, Microsoft Edge usw.). Vereinfacht gesagt: Die Rendering Engine von Chrome und seinen Derivaten verwendet so viel Arbeitsspeicher und CPU-Leistung, wie es dienlich ist, um eine optimale und performante Darstellung des Inhalts zu ermöglichen. Erst wenn andere Anwendungen innerhalb des Systems selbst Bedarf anmelden, zieht sich Chromium zurück und räumt Ressourcen frei. Bei üppig dimensionierten und hoch performanten Endgeräten merkt man davon nur wenig. Bei schwächeren oder knapp dimensionierten Endgeräten (u. a. virtuelle Desktops) hingegen kann es durch dieses Verhalten durchaus zu spürbaren Leistungseinbußen und somit zu einer beeinträchtigten Endbenutzererfahrung kommen.
Abb. 2: Technischer Aufbau von Microsoft Teams (Quelle: Microsoft)
Performance-Messungen
Um entsprechende Leistungsmessungen durchzuführen, wurde Microsoft Teams auf einem FAT-Client und einem Terminalserver (Windows Server 2019) installiert. Im Anschluss wurde die jeweilige Last (CPU und GPU) auf beiden Systemen gemessen – sowohl für den Fall der Videokonferenz als auch für den Fall der Kollaboration (Chat).
Hinweis: Die nachfolgend dargestellten Messungen sollen die groben Performance-Unterschiede je nach Anwendungsszenarium aufzeigen. Diese Ergebnisse sind in keiner Weise wissenschaftlich fundiert.
Videokonferenz
1. FAT-Client
System: Lenovo Notebook, Windows 10 20H2, Intel i7 Prozessor, 16GB RAM
Gemessen wurde die CPU- und GPU-Auslastung beim Start einer Teams Videokonferenz mit mehr als 20 Teilnehmenden. Die nachfolgende Abbildung verdeutlicht, dass beides – sowohl Prozessor als auch Grafik-karte – mit einer Sitzung gut ausgelastet sind.
Abb. 3: CPU- und GPU-Auslastung während einer Videokonferenz mit >20 Teilnehmer:innen
2. Terminalserver
System: VMware-VM, Windows 2019, 4 vCPUs, 24GB RAM, Citrix CVAD 1912U2
Die Messungen auf dem Terminalserver wurden unter drei verschiedenen Annahmen durchgeführt.
- Annahme 1: Mit Teams-Optimierung
- Annahme 2: Ohne Teams-Optimierung, mit GPU-Beschleunigung des Terminalservers
- Annahme 3: Ohne Teams-Optimierung, ohne GPU-Beschleunigung des Terminalservers
Mit Teams-Optimierung
Mit der Teams-Optimierung wird mittels WEB-RTC der Datenstrom für Audio und Video an den Remote-Rechner, der den virtuellen Desktop startet, umgeleitet. Somit wird die Last auf die Clients dezentral ver-teilt, womit eine Entlastung der Quell-VM einhergeht.
Weitere Informationen zum Thema Teams-Optimierung finden Sie in der Microsoft Teams Dokumentation.
Abb. 4: Funktionalität der Teams-Optimierung
Wie spiegelt sich nun die Teams-Optimierung in den Messergebnissen wider? Die Daten der folgenden Abbildung zeigen auf, dass die Grafiklast an den Client umgeleitet wird. Der Client hat somit eine GPU-Last von 40 %, der Terminalserver eine CPU-Last von nur 10 %. Die GPU des Terminalservers wird nicht belastet.
Abb. 5: Messergebnisse mit Teams-Optimierung
Ohne Teams-Optimierung und mit GPU-Beschleunigung des Terminalservers
Schauen uns wir nun die Auswirkungen an, wenn die Teams-Optimierung nicht genutzt wird, dafür aber GPU des Terminalservers beschleunigt wird: Da hier der Audio-/Video-Strom nicht umgeleitet wird, muss dies vom Terminalserver verarbeitet werden. Die Belastung des Terminalservers entspricht damit ungefähr der Belastung eines FAT-Clients.
Abb. 6: Messergebnisse ohne Teams-Optimierung und mit GPU-Beschleunigung des Terminalservers
Ohne Teams-Optimierung und ohne GPU-Beschleunigung des Terminalservers
Wenn Teams auf einem Terminalserver ohne Optimierung und Grafikkarte betrieben wird, muss die GPU-Berechnung durch die CPU (Citrix Graphics Engine) erledigt werden. Die Systemlast auf dem Terminalserver liegt allein mit einer Teams-Sitzung bei knapp 50%.
Abb. 7: Messergebnisse ohne Teams-Optimierung und ohne GPU-Beschleunigung des Terminalservers
Kollaboration (Chat)
Gemessen wurde die Auslastung der CPU im Chat-Verlauf. Hierbei wurde einfach das Chat-Fenster geöffnet und der Verlauf gescrollt. Diese Messungen sind vom Client unabhängig.
Abb. 8: Gemessene CPU-Last beim Scrollen durch den Verlauf eines geöffneten Chats
Während der Messung konnte beobachtet werden, dass die CPU-Last des Teams-Prozesses auf 30 % an-steigt (siehe Abbildung 8). Doch was ist die Ursache dafür? Um das herauszufinden, haben wir zusätzlich das Browserdebug-Fenster geöffnet und erneut gescrollt. Folgende Abbildung zeigt das Ergebnis.
Abb. 9: Browserdebug-Fenster während eines geöffneten Chat-Verlaufs
Ergebnis: Beim Scrollen des Chatverlaufs werden die einzelnen Daten direkt aus dem Internet abgerufen und gerendert. Dies liegt am technologischen Unterbau von Teams, denn jeder einzelne Chat-Beitrag be-deutet in der Folge auch einen Web-Request an die Teams-Infrastruktur in der Cloud. Daher ist es wichtig, die Netzwerkinfrastruktur bis ins Internet gut zu bemessen. Dies kann mit dem Microsoft Tool https://connectivity.office.com/ erfolgen.
Zusammenfassung der Messergebnisse
Es wurde immer die Last des Rechners gemessen, auf dem Teams installiert ist. Generell konnte festgestellt werden, dass die Belastung der Systeme durch Teams auf einem sehr hohen Niveau ist. Selbst ein lokaler FAT-Client mit einer modernen CPU hat eine Last von 30-50 %.
Auf einem Terminalserver mit mehreren Benutzern ohne jegliche Optimierung wird dies zu einer unzu-reichenden Benutzererfahrung führen. Hier empfiehlt es sich, die Optimierung der Hersteller zu nutzen.
| Teams Lastart | lokaler PC Intel I7 | VDI / RDSH umgeleitet | VDI / RDHS mit GPU | VDI / RDSH ohne GPU |
|---|---|---|---|---|
| Video Chat CPU | 30-40% | 3-6% | 30-40% | 45-50% |
| Teams Chat/Kanäle CPU | 30-50% | 40-50% | 40-50% | 40-50% |
| Video Chat GPU | 30-40% | unter 1% | 10-15% | nicht vorhanden |
| Teams Chat/Kanäle GPU | 30-50% | unter 2% | unter 2% | nicht vorhanden |
Abb. 10: Zusammenfassung der Messergebnisse
Ansatzpunkte zur Optimierung – Was kann ich tun?
Zu Beginn haben wir in einer Übersicht dargestellt, dass es sich bei Microsoft Teams um eine sehr komplexe Lösung innerhalb der Microsoft Clouddienste handelt, auf die man als Unternehmen nur wenig Einfluss nehmen kann. Gleichzeitig stellt natürlich der Teams-Client die wichtigste Schnittstelle zum Enduser inner-halb der Lösung dar. Aus diesem Grund soll es im Folgenden darum gehen, aufzuzeigen, welche Möglichkei-ten sich in Bezug auf den Client ergeben, um Verbesserungen herbeizuführen.
Fokus: Netzwerk
Da die Kommunikation zur Microsoft Cloud unabdingbar für einen reibungslosen Betrieb ist, gilt es in erster Instanz zu gewährleisten, dass die netzwerktechnischen Voraussetzungen für den Betrieb gegeben sind. Zu Beginn, aber auch durchaus nach der Einführung sollte daher immer die Konnektivität zu den Microsoft-Diensten geprüft werden.
Diese Analyse lässt sich bequem über das Microsoft 365 Network Connectivity Dashboard unter https://connectivity.office.com/ durchführen; gleichzeitig ist sie ein erster wichtiger Indikator für sich an-bahnende Probleme. Auch sollte die IT angesichts der verstärkten Homeoffice-Tätigkeit den Endanwen-der:innen dazu raten, bei auftretenden Problemen die Netzwerkanbindung mittels des Connectivity Dash-boards in Eigenregie zu überprüfen.
Abb. 11: Das Connectivity-Dashboard von Microsoft
Da in den meisten Unternehmensnetzwerken der Netzwerkverkehr durchleuchtet, analysiert und ggf. gefiltert wird, sollten die entsprechenden Netzwerkfreischaltungen im Vorfeld erfolgen. Auch hierfür bietet Microsoft zahlreiche Werkzeuge sowohl für eine Vorab-Analyse als auch eine periodische Überprüfung an. Eine Auswahl:
Zudem spielt die Bandbreite im Rahmen des Conferencings eine erhebliche Rolle. Obwohl Teams mit der Zielsetzung entwickelt wurde, auch unter widrigen Umständen die bestmögliche Audio- und Videoqualität zu ermöglichen, ergeben sich diesbezüglich Grenzen. So wird bei unzureichenden Bedingungen Teams im-mer Audio vor Video priorisieren. In Fällen, wo Bandbreite keine Rolle spielt, findet weiterhin eine Optimierung der Inhalte statt. Die maximale Auflösung liegt hier jedoch bei 1080p/30 Frames für Video und 1080p/15 Frames für geteilte Inhalte.
Im Durchschnitt wird die benötigte Bandbreite pro Nutzer mit ca. 1,2 Mbit/sec angegeben, um hochauflö-sendes Conferencing zu ermöglichen. Diese Werte sind allerdings nicht absolut, sondern von verschiedenen Faktoren wie Videolayout, Auflösung und Framerate abhängig.
Fokus: Installation
Obwohl die Installation heutzutage eine Selbstverständlichkeit ist, kann es in Abhängigkeit von der Zielum-gebung beim Teams-Client durchaus herausfordernd sein, eine korrekte Installation durchzuführen. Daher ist es wichtig, zu Beginn auf eine korrekte Installation für die gewählte Zielumgebung zu achten. Die Instal-lationsparameter für Desktop-Clients und virtuelle Umgebungen unterscheiden sich und eine falsche Auswahl kann dazu führen, dass der Client sich bei den Endanwender:innen höchst instabil verhält.
Wichtig ist abzugrenzen, auf welche Art von Zielsystem der Client installiert wird. Dabei unterscheiden wir hauptsächlich zwischen nicht-persistenten virtualisierten Desktops (Pooled VDI’s und Terminalserver) und persistenten virtuellen Desktops bzw. physikalischen Systemen. Entsprechend ergeben sich folgende Installationsparameter:
Trotz der hohen Ähnlichkeit der beiden entscheidenden Parameter bewirken diese jeweils fundamental unterschiedliche Dinge: Während ALLUSERS einfach nur dafür sorgt, dass im Windows-System unter „Programme & Funktionen“ ein Eintrag über die Installation hinzugefügt wird, bewirkt der Parameter ALLUSER (Achtung: Singular, nicht Plural), dass der automatische Updater von Teams, welcher bei jedem Start die Version von Teams überprüft und ggf. aktualisiert, nicht aktualisiert werden soll. Dies ist vor allem essenziell für die benannten virtuellen Systeme ohne persistentes Benutzerprofil, da eine normale Installation von Teams alle Installationsdateien ins Benutzerprofil schreibt. Das Ziel muss aber sein, für geteilte Systeme eine Kopie der Installation im Programmverzeichnis vorzuhalten und nur die Einstellungen sowie den Cache von Teams im Benutzerprofil abzulegen.
Mit dieser Information muss den Verantwortlichen für den Aufbau und die Pflege der Arbeitsplätze aber auch bewusst sein, dass die automatische Aktualisierung von Teams nicht mehr aktiv ist. Dies ist insofern problematisch, da gerade der Teams-Client teilweise mehrere Updates pro Monat erhält. Somit ist es enorm wichtig, im Rahmen der Betriebssystempflege einen periodischen Update-Prozess der Teams Client-Installation umzusetzen.
Fokus: Profilmanagement
Hat der Anwender erstmalig den Teams-Client geöffnet, findet im Hintergrund die Ersteinrichtung statt. Auch diese hat es „in sich“. Denn Microsoft Teams schafft es, bei dem ersten Start fast 1 GB an Daten in das Benutzerprofil zu schreiben.
Für physikalische Geräte (Desktops, Laptops oder Tablets) ist das nach dem aktuellen Stand der Technik keine besondere Herausforderung. Ganz anders stellt sich die Sachlage aber in virtuellen Umgebungen dar. Denn hier ist zu berücksichtigen, dass die gesamte Infrastruktur zur Bereitstellung der virtuellen Desktops eng ineinander verwoben ist. So laufen gerne mal hunderte oder gar tausende virtuelle Maschinen in einer gemeinsamen Umgebung. Summiert man nun die Menge der Daten, die im Benutzerkontext anfallen und separat vom Arbeitsplatz gesichert werden müssen, kommen plötzlich ganz andere Anforderungen auf die IT zu. Denn gerade für das Profilmanagement in Verbindung mit Teams kann es problematisch sein, diese Mengen sinnvoll zu managen.
Ferner ist zu beachten, dass Teams zwecks Dateiaustausch auf OneDrive for Business angewiesen ist. Das heißt: Eine optimale Nutzung von Teams u.a. im Bereich Kollaboration und Dateiaustausch ist nur im Ge-spann mit OneDrive möglich. Hieraus ergeben sich weitere Abhängigkeiten, denn der OneDrive-Support von Microsoft greift nur, wenn als Profilmanagement-Lösung FSLogix eingesetzt wird. Unser Dank geht hier an unseren Kollegen aus dem Competence Center Microsoft 365, der dies vor geraumer Zeit direkt mit Microsoft geklärt hat:
Abb. 12: Statement von Microsoft zum Support von OneDrive
Zusammenfassend kann man also sagen: Unternehmen, die den vollen Funktionsumfang von Teams nutzen möchten, sind auf OneDrive angewiesen. Daraus ergibt sich automatisch der Zwang, FSLogix als Profilma-nagement-Lösung einzusetzen.
Das ist erst einmal gar nicht so tragisch, wie es klingt. Denn generell spricht sehr viel für FSLogix – und oft-mals werden viele VDI-Lösungen mit FSLogix als Profilmanagement-Komponente implementiert, was zu herausragenden Ergebnissen führt. Dennoch muss an dieser Stelle auch erwähnt werden, dass durch die Arbeitsweise von FSLogix die Profilgrößen um ein Vielfaches höher ausfallen können als diejenigen von klassischen Profilmanagementlösungen. Auf der einen Seite profitiert man also von einem extremen Performancegewinn, auf der anderen Seite bereiten die enormen Größen der Benutzerprofile gerne einmal Kopfzerbrechen.
Hinzu kommt die besondere Eigenart des Teams-Clients, dass nicht nur 1 GB an Profildaten (netto) weggeschrieben, sondern in Summe sogar 5 GB „umgewälzt“ werden. Sprich: Teams schreibt ca. 5 GB Daten ins Profil, löscht danach aber 4 GB (siehe Abbildung 12). Das hat zur Folge, dass alle Benutzerprofildisks auf ihrer maximalen Größe verharren, auf die sie sich durch den Erststart erweitert haben.
Abb. 13: Speicherkonsum Microsoft Teams nach Anmeldung
Um dieses Verhalten auf ein Minimum zu reduzieren, haben wir uns intensiv mit dem Profilmanagement von Teams in Verbindung mit FSLogix auseinandergesetzt und eine Ausschlussliste entwickelt, die einerseits den störungsfreien Betrieb des Clients gewährleistet, auf der Haben-Seite aber die überproportionale Er-weiterung der Profildisk verhindert.
Für die korrekte Implementierung der Ausschlüsse bietet der Microsoft-Artikel „FSLogix Profile container content“ eine ausführliche Anleitung.
Fazit und Ausblick
Zu Beginn der Entwicklung von Teams hat Microsoft einen neuartigen und mutigen Ansatz gewählt. Hierbei sei erwähnt, dass bei einem mittlerweile so komplexen Softwareprodukt wie Teams die Wahrung der Balance zwischen Performance & Schlankheit und der Abbildung aller Nutzerbedürfnisse aus Entwicklerper-spektive durchaus eine Herausforderung darstellt. Daher gelingt die Performance-Optimierung für Microsoft Teams nicht nur durch das Aufsummieren von ein paar Parametern, sondern erst durch die Kombinati-on von auf die Umgebung und Arbeitsweise abgestimmten Ansätzen. Dies setzt allerdings voraus, das erwartete Verhalten von Teams zu verstehen – und genau dazu sollte dieser Beitrag dienen.
Ein erster Ausblick auf das zukünftige „Teams 2.0“ bietet schon jetzt das Betriebssystem Windows 11, in welches Microsoft bereits eine vollständig neuentwickelte Teams-Version integriert hat. Dabei handelt es sich jedoch um eine schlankere Variante, die speziell auf Endkunden ausgerichtet ist und somit nicht den gleichen Funktionsumfang hinsichtlich Business-Collaboration bietet, wie es aktuell der Fall ist.
Eine Marschrichtung zeichnet sich allerdings bereits ab: Microsoft verlässt den Electron-Entwicklungspfad zugunsten von Edge WebView2. WebView2 dient als schlanker und moderner Ersatz von Electron und ermöglicht ebenfalls die Entwicklung von Anwendungen unter Zuhilfenahme von Webtechnologien. Da Microsoft hier also zukünftig auf einen hauseigenen Unterbau setzen wird, ist anzunehmen, dass die Ent-wicklung entsprechend effizienter und optimierter erfolgen wird.
Erste Tests mit der neuen Teams-Version unter Windows 11 zeigen auf, dass sich der Technologiewechsel positiv auf die Anwendungsperformance auswirkt. Ein endgültiges Datum für das Erscheinen der neuentwickelten Business-Version hat Microsoft zum aktuellen Zeitpunkt noch nicht genannt. Sobald dies der Fall ist, werden wir selbstverständlich unsere Performance-Untersuchungen erneuern und an dieser Stelle publizieren.