Internet Explorer Performance Lab: zuverlässige Messung der Browserleistung

Die Entwicklung von Windows 8

Einblicke in die Arbeit des Windows-Entwicklerteams

Internet Explorer Performance Lab: zuverlässige Messung der Browserleistung

Rate This
  • Comments 0

In einem Großteil dieses Blogs erhalten Sie Einblick in all die Arbeit, die mit der Entwicklung von Windows 8 zusammenhängt. In diesem Beitrag werfen wir einen Blick auf etwas, das uns allen – Entwicklern und Endbenutzern – wichtig ist: die tatsächliche Webleistung. Wir arbeiten hart daran, über das reine Empfinden hinaus für ein leistungsfähiges Weberlebnis zu sorgen. Dieser Beitrag wurde von Matt Kotsenas, Jatinder Mann und Jason Weber des IE-Teams verfasst, auch wenn alle Mitglieder des Teams an der Leistungsoptimierung beteiligt sind. --Steven

Webleistung ist für jeden von Bedeutung, und ein Entwicklungsziel für Internet Explorer besteht darin, der weltweit schnellste Browser zu sein. Um dieses Ziel zu erreichen, müssen wir die Browserleistung zuverlässig anhand von alltäglichen Szenarien messen, die unsere Kunden betreffen. In den letzten fünf Jahren haben wir das Internet Explorer Performance Lab entworfen und aufgebaut, eines der weltweit aufwändigsten Messsysteme für die Webleistung.

Im IE Performance Lab werden zuverlässige, präzise und nutzbare Daten gesammelt, um während des Entwicklungszyklus Entscheidungen zu treffen. Wir messen die Leistung von Internet Explorer täglich 200-mal und sammeln so über 5,7 Millionen Messwerte und 480 GB Laufzeitdaten pro Tag. Wir sind uns der Auswirkung jeder Änderung am Produkt bewusst und stellen sicher, dass Internet Explorer nur schneller wird. In diesem Blogbeitrag werfen wir einen genaueren Blick darauf, wie das IE Performance Lab aufgebaut ist und wie wir damit das Internet kontinuierlich schneller machen.

In diesem Beitrag werden folgende Punkte behandelt:

  • Übersicht über das IE Performance Lab
  • Infrastruktur des Labors
  • Was (und wie) gemessen wird
  • Testen eines Szenarios
  • Ergebnisanalyse
  • Testen von Drittanbietersoftware
  • Erstellen eines schnellen Browsers für Benutzer

Übersicht über das IE Performance Lab

Um die Webleistung zuverlässig über einen Zeitraum messen zu können, muss ein System reale Benutzerszenarien reproduzierbar simulieren können. Unser System muss im Wesentlichen eine "Miniversion des Internets" nachbilden.

Das IE Performance Lab ist ein privates Netzwerk, das vom öffentlichen Internet und vom Microsoft-Intranet vollständig abgeschnitten ist und aus über 140 Computern besteht. Das Labor enthält die Kernelemente des wirklichen Internets, wie Webserver, DNS-Server, Router und Netzwerkemulatoren, die unterschiedliche Konnektivitätsszenarien von Kunden simulieren.

Obwohl dies auf den ersten Blick komplex erscheinen mag, können wir mit diesem Ansatz alle Quellen für Abweichungen ausschließen. Da wir jeden Aspekt des Netzwerks bis hin zu einzelnen Paket-Hops und Latenzen kontrollieren, werden unsere Tests vorherbestimmbar und wiederholbar, eine Voraussetzung, um die Ergebnisse nutzen zu können. Im IE Performance Lab wird die Aktivität mit einer Auflösung von 100 Nanosekunden gemessen.

Diagramm zeigt Verbindungen zwischen Inhaltsservern, Netzwerkemulatoren, DNS-Servern, Testclients, Rohdatenspeicher, Datenanalyse und SQL-Datenbank.

Diese Art von Netzwerkkonfiguration bietet außerdem viel Flexibilität. Da wir einen realen Aufbau simulieren, kann unser Labor nahezu jede Art von Testcomputer oder Websiteinhalt aufnehmen. Das IE Performance Lab unterstützt Desktops, Laptops, Netbooks und Tablets mit x86-, x64- und ARM-Prozessoren, alles zur gleichen Zeit. Da wir für das Labor die Windows Performance Tools (WPT) verwenden, können wir ebenso die gleichen Tests mit unterschiedlichen Webbrowsern, Symbolleisten, Antivirusprodukten oder anderer Drittanbietersoftware ausführen und die Ergebnisse direkt miteinander vergleichen.

WPT bietet einen tiefen Einblick in die zugrunde liegende Hardware. Mit WPT können wir alles von CPU- und GPU-Aktivität auf hoher Ebene bis hin zu Informationen auf niedriger Ebene, wie Cacheeffizienz, Netzwerkstatistik, Muster der Arbeitsspeichernutzung und mehr erfassen. Dank WPT können wir die Leistung im Stapel messen und optimieren, um sicherzustellen, dass Hardware, Gerätetreiber, Windows-Betriebssystem und Internet Explorer effizient aufeinander abgestimmt sind.

Ein einzelner Testlauf dauert sechs Stunden und generiert in dieser Zeit über 22 GB Daten. Dieses hoch automatisierte System wird von einem kleinen Team gewartet, das Operationen überwacht, Ergebnisse analysiert und neue Infrastrukturfeatures entwickelt.

Infrastruktur des Labors

Die Infrastruktur des Performance Labs kann in drei Hauptkategorien unterteilt werden: Netzwerk und Server, Testclients sowie Analyse und Berichterstellung. Jede Kategorie ist dafür konzipiert, die Interaktion zwischen Komponenten zu minimieren, um die Skalierbarkeit der Tests zu verbessern und die Möglichkeit von Störsignalen in der Laborumgebung zu verringern.

Ein großer Raum voll von Computern

Hier ist eine Abbildung des IE Performance Labs mit einer Reihe von Test- und Analysecomputern in unserem privaten Netzwerk.

Netzwerk- und Serverinfrastruktur

Zuerst werden wir die DNS-Server, Netzwerkemulatoren und Inhaltsserver behandeln. Diese Komponenten bilden zusammen das "Mini-Internet". In den nächsten drei Abschnitten arbeiten wir uns im Architekturdiagramm von rechts nach links vor.

Inhaltsserver

Inhaltsserver sind Webserver, die die Millionen von Webhosts im Internet ersetzen. Auf jedem Inhaltsserver sind reale Webseiten gehostet, die lokal gespeichert wurden. Die gespeicherten Seiten werden einem Prozess unterzogen, den wir als "Sanitisation" bezeichnen, bei dem wir Teile des Webinhalts justieren, um eine reproduzierbare Zufallsunabhängigkeit sicherzustellen. Beispielsweise werden JavaScript Date-Funktionen oder Math.Random()-Aufrufe durch einen statischen Wert ersetzt. Außerdem werden die von Anzeigenframeworks erstellten dynamischen URLs auf die URL festgelegt, die zuerst vom Framework verwendet wurde.

Nach der Sanitisation werden Inhalte ähnlich wie statische Inhalte über einen ISAPI-Filter bereitgestellt, der einen Hash der URL dem Inhalt zuordnet, sodass ein unmittelbares Nachschlagen ermöglicht wird. Jeder Webserver ist ein 16-Kern-Computer mit 16 GB Arbeitsspeicher, um die Variabilität zu minimieren und sicherzustellen, dass sich der Inhalt im Arbeitsspeicher befindet (kein Festplattenzugriff erforderlich).

Inhaltsserver können auch dynamische Webanwendungen wie Outlook Web Access oder Office Web Apps hosten. In diesen Fällen werden der Anwendungsserver sowie Abhängigkeiten mit mehreren Ebenen auf dedizierten Servern im Labor gehostet, so wie in realen Umgebungen.

Netzwerkemulatoren

Da viele Quellen für Variabilität ausgeschlossen wurden, spiegeln die Netzwerkgeschwindigkeiten nicht mehr das Erlebnis vieler Benutzer mit langsameren Verbindungen wider. Zum Simulieren realer Benutzerumgebungen kann für Tests eine Netzwerkemulation verwendet werden, um die Leistung innerhalb eines breiten Spektrums der heutzutage verwendeten Netzwerke zu analysieren. Das Labor unterstützt die Emulation mehrerer DSL-Konfigurationen, Kabelmodems, 56k-Modems sowie Umgebungen mit hoher Bandbreite und hoher Latenz, wie z. B. WAN- und 4G-Umgebungen. Beim Übergeben der HTTP-Anforderungen an den Emulator werden die Netzwerkeigenschaften wie Paketverzögerung und Sortierung simuliert. Anschließend wird die Anforderung an die Webhosts weitergeleitet. Beim Empfangen einer Antwort wird die Emulation wieder angewendet, bevor sie an den Testclient übergeben wird.

Durch die Verwendung dedizierter Hardware für die Netzwerkemulation kann die Testumgebung so realistisch wie möglich gestaltet werden, und der Beobachtereffekt wird deutlich verringert. Obwohl dedizierte Hardware im Vergleich zu Proxy- oder Softwarelösungen mehr Kosten und Komplexität bedeutet, ist dies die einzige Möglichkeit, die Leistung präzise zu messen. Browser beschränken die Anzahl gleichzeitiger Proxyverbindungen, um eine Proxysaturiertheit zu verhindern. Daher hat die Verwendung eines Proxys für die Netzwerkemulation den unerwünschten Effekt der Umgehung von Domain Sharding und anderen Optimierungen, die von der Webseite vorgenommen werden. Außerdem konkurriert die lokale Netzwerkemulation mit dem Browser um die lokalen Computerressourcen, besonders auf Computern mit niedriger Leistung.

DNS-Server

Wie auch reale DNS-Server verbinden die DNS-Server des Labors die Inhaltsserver mit den Testclients. Im Labor wird für jeden Netzwerkemulator ein eigener DNS-Server verwendet. Dadurch ist das Wechseln von einer Netzwerkgeschwindigkeit zu einer anderen so einfach wie das Wechseln des DNS-Servers. Anstatt die Domänennamen für die Webhosts aufzulösen, werden in diesen Fällen vom DNS-Server alle Domänennamen für den zugeordneten Netzwerkemulator aufgelöst.

Konfiguration der Testclients

Wir möchten sicherstellen, dass Internet Explorer auf allen Klassen von Computerhardware konsistent ausgeführt wird. Das Labor umfasst über 120 Computer für die Messung der Leistung von Internet Explorer. Diese bezeichnen wir als Testclients. Sie reichen von High-End-x64-Desktops bis hin zu Netbooks mit niedriger Leistung und Tablets mit Touchscreen sowie alles im Zwischenbereich. Da die Wiederholbarkeit der Messungen Priorität hat, handelt es sich bei allen Testclients um physische Computer.

Ein langes Pult und zwei Regale mit jeweils 12 oder mehr Computern

Internet Explorer Performance Lab-Computerpool für Änderungsvergleiche

Verschiedene Computerklassen enthalten sowohl eigenständige als auch integrierte Grafikplattformen, um sicherzustellen, dass Internet Explorer die Hardwarebeschleunigung innerhalb des Ökosystems von Geräten immer voll ausnutzt. Weiter oben ist unser Hauptcomputerpool abgebildet. Diese PCs entsprechen in etwa dem durchschnittlichen Benutzererlebnis während der Lebensdauer eines Windows 7- oder Windows 8-PCs. Die Computer werden vom OEM bestellt, damit sie identisch sind. Sie kommen alle aus derselben Produktionscharge, und ihre Leistungseigenschaften werden vor der Verwendung überprüft.

Da das Labor rund um die Uhr betrieben wird, sind Hardwarefehler unvermeidbar. Das Austauschen fehlerhafter Komponenten mit identischen Bauteilen aus einer anderen Produktionscharge führt fast immer dazu, dass der reparierte Computer schneller läuft als die anderen Computer im Pool. Während dieser Unterschied im realen Leben nicht bemerkbar wäre, können bei einer Messung im Bereich von 100 Nanosekunden selbst wenige Zyklen die Ergebnisse beeinflussen! Wenn ein Computer nach einer Reparatur mit dem Rest des Pools nicht mehr gleichförmig läuft, wird er aus dem Labor entfernt, wodurch die Größe des Pools permanent schrumpft. Daher werden für das Labor zusätzliche Computer als "Puffer" eingekauft, damit die überschüssige Kapazität beim Entfernen eines fehlerhaften Computers aus dem Pool als Polster dient und der Betrieb des Labors nicht beeinträchtigt wird.

Poolname

Anzahl Computer

Formfaktor

Prozessor

Arch

Taktrate

Arbeitsspeicher

Grafik

Main Pool

32

Desktop

Core i5 750 (Lynnfield)

64-Bit

2,66 GHz

4096 MB DDR3

NVIDIA GeForce 310

Um den Hardwareumfang zu erhöhen, haben wir zusätzliche Computerpools, in denen das Spektrum von Benutzerszenarien umgesetzt wird. Durch eine gute Leistung auf diesen Computern wird sichergestellt, dass IE die zugrunde liegende Hardware innerhalb des PC-Ökosystems effektiv nutzt.

Poolname

Anzahl Computer

Formfaktor

Prozessor

Arch

Taktrate

Arbeitsspeicher

Grafik

High‑End 1

20

Desktop

Core i7 870

64-Bit

2,93 GHz

4096 MB DDR3

ATI Radeon HD 4550

High‑End 2

4

Desktop

Xeon 5150 (Woodcrest)

64-Bit

2,66 GHz

8192 MB DDR2

ATI Radeon X1950 Pro

Mid‑Range 1

6

Desktop

Core 2 Duo (Wolfdale)

64-Bit

3,0 GHz

4096 MB DDR2

Intel GMA 4500

Mid‑Range 2

15

Desktop

Core 2 Duo E6750

64-Bit

2,66 GHz

4096 MB DDR2

ATI Radeon HD 2400 XT

Mid‑Range 3

25

Desktop

Core i5 2500

64-Bit

3,3 GHz

4096 MB DDR3

Intel HD Graphics 2000

Mid‑Range 4

6

Desktop

Core 2 Duo (Conroe)

64-Bit

2,66 GHz

4096 MB DDR2

ATI Radeon HD 2400XT

Mid‑Range 5

4

Desktop

Core 2 Duo (Conroe)

64-Bit

2,4 GHz

4096 MB DDR2

ATI Radeon X1950 Pro

Low‑Power 1

2

Laptop

Atom Z530

32-Bit

1,6 GHz

2038 MB DDR2

Intel GMA 500

Low‑Power 2

4

Netbook

Atom N270

32-Bit

1,6 GHz

1024 MB DDR2

NVIDIA ION

Low‑Power 3

2

Netbook

Atom N450

64-Bit

1,66 GHz

1024 MB DDR2

Intel GMA 3150

Low‑Power 4

4

Netbook

Atom N270

32-Bit

1,6 GHz

1024 MB DDR2

Intel GMA950

Low‑Power 5

4

Slate

ARM

32-Bit

Prototyphardware

Sortiment von Laptop- und Desktop-PCs auf zwei Regalen

Testcomputer mit niedriger Leistung. Jeder befindet sich in einem anderen Teststatus.

Wenn noch mehr Vielfalt benötigt wird, kann für das IE Performance Lab auch noch das Windows Graphics Lab genutzt werden. Das Windows Graphics Lab hat nahezu alle hergestellten Grafikchips auf Lager. PCs können mit fast jeder erdenklichen Permutation konfiguriert und dann für Leistungstests verwendet werden. Das Windows Graphics Lab ist von unschätzbarem Wert für die Diagnose von Grafikproblemen zwischen Chipsätzen und Treiberrevisionen.

Analyse- und Berichtsserver

Die Erfassung und Analyse von Testergebnissen sind in zwei getrennte Schritte unterteilt. Durch das Abladen der Analyse auf dedizierte Computer können die Testclients früher mit dem nächsten Leistungstestlauf beginnen, und die Analyse kann mit leistungsstärkeren Serverklassencomputern schneller durchgeführt werden. Je schneller die Analyse abgeschlossen ist, desto effizienter können wir Leistungsänderungen erkennen.

Für die Analyse verwenden wir elf Serverklassencomputer, die jeweils über 16 Prozessorkerne und 16 GB Arbeitsspeicher verfügen. Während der Analyse wird jede Ablaufverfolgungsdatei untersucht, und Tausende von Metriken werden auf einem SQL-Server extrahiert und eingefügt. Innerhalb von 24 Stunden untersuchen diese Analysecomputer über 15.000 Ablaufverfolgungen für die Trendanalyse.

Zwei Serverracks

Abgebildet sind zwei von mehreren Serverracks mit Dateiservern, einem SQL-Server sowie mehreren Analyse- und Inhaltsservern.

Der SQL-Server zum Speichern der fast 6 Millionen Messwerte, die wir jeden Tag sammeln, ist ein Computer mit 24 logischen Kernen und 64 GB Arbeitsspeicher. Die Berichte können direkt über SQL generiert werden, oder die Ergebnisse können mit einer HTML-basierten Vergleichsanwendung oder dem WCF-Dienst untersucht werden, der die Ergebnisse im XML- oder JSON-Format bereitstellt.

Was (und wie) gemessen wird

Werfen wir mit der vorhandenen Infrastruktur nun einen Blick auf die verschiedenen Arten von Szenarien, die im Performance Lab gemessen werden, sowie auf die Tools, mit denen wir die Metriken erfassen.

Täglich gemessene Szenarien

Das Performance Lab konzentriert sich auf reale Szenarien, die für Benutzer von Bedeutung sind. Daher führen wir täglich über 20.000 verschiedene Tests durch. Diese Tests lassen sich in vier Kategorien aufteilen, die sich manchmal überschneiden:

Vier sich überschneidende Kreise: Laden von Inhalten, interaktive Webanwendungen, "Die Anwendung" IE, synthetische Plattformbenchmarks

Laden von Inhalten – Das Navigieren von einer Seite zu einer anderen ist immer noch die häufigste Aktivität in einem Webbrowser. Das Laden von Webinhalten ist außerdem die einzige Kategorie, die den Großteil der elf Subsysteme des Browsers involviert. Das Laden von Webinhalten ist eine Voraussetzung für die anderen Kategorien von Szenarien.

Interaktive Webanwendungen – Diese Kategorie beinhaltet das, was gelegentlich als Inhaltserstellung, AJAX-Anwendungen oder Web 2.0-Websites bezeichnet wird. Darunter fällt das Interagieren mit gängigen Nachrichtenwebsites und sozialen Netzwerken sowie mit E-Mail- und Dokumentanwendungen wie Outlook Web Access und Office Web Apps.

"Die Anwendung" IE – Wichtig, aber oft vergessen, sind Szenarien, die mit dem Browser selbst interagieren. Häufige Interaktionen beinhalten das Öffnen und Schließen des Browsers, das Wechseln zwischen Registerkarten, das Verwenden von Browserfeatures wie Verlauf und Favoriten sowie das Verschieben und Zoomen mit Tastatur und Maus oder mit Toucheingabe.

Synthetische Benchmarks – Selten vergessen, aber oft überbewertet, werden die synthetischen Benchmarks wie WebKit SunSpider. Benchmarks können ein nützliches Entwicklungstool sein, da sie dafür konzipiert sind, einzelne Browsersubsysteme zu beanspruchen und Unterschiede zwischen Browsern hervorzuheben. Um diese Unterschiede zu maximieren, bedienen sich Benchmarks jedoch oft atypischer Verwendungsmuster oder Grenzfälle.

Reale Verwendungsmuster

Beim Messen der Leistung muss sichergestellt werden, dass die Tests reale Verwendungsmuster widerspiegeln. In den meisten Fachbüchern zu Softwareentwicklung wird dieser Prozess als Arbeitslastmodellierung oder Modellierung der Anwendungsnutzung bezeichnet. Um sicherzustellen, dass das Performance Lab realitätsnahe Muster misst, werden dort reale Webseiten verwendet, die reale Verwendungsmuster repräsentieren und unterschiedliche Browsersubsysteme beanspruchen.

Um die für die Tests verwendeten Websites zu bestimmen, durchforsten wir regelmäßig Millionen von Websites und stellen eine Liste von Websiteattributen und Codierungsmustern zusammen. Wir verwenden 68 unterschiedliche Datenpunkte, um Gemeinsamkeiten zwischen Websites zu ermitteln – Dinge wie die Tiefe und Breite des resultierenden DOM, CSS-Layoutmuster, häufig verwendete Frameworks, internationale Features usw. Anhand der Ergebnisse wählen wir Websites aus, die am ehesten die allgemeinen Muster und die Vielfalt des breiten Internets repräsentieren.

Entwickeln von Metriken

Leistung ist ein mehrdimensionales Problem. Um eine genaue Sicht auf die Leistung zu erhalten, ist es wichtig zu verstehen, welches Szenario getestet wird und wie Hardware und Betriebssystem mit dem Browser interagieren. Werfen wir einen näheren Blick auf fünf wichtige Leistungsmetriken im Zusammenhang mit dem ersten Laden einer großen Sportwebsite.

Diagramm zum Vergleich von Anzeigezeit, verstrichener Zeit, CPU-Zeit, Ressourcennutzung und Energieverbrauch

Anzeigezeit – Mit der Anzeigezeit wird die Zeitspanne ab dem Ausführen einer Aktion durch den Benutzer bis zum Anzeigen des Ergebnisses dieser Aktion auf dem Bildschirm gemessen.

Verstrichene Zeit – Von den meisten Websites werden weiter Hintergrundvorgänge ausgeführt, nachdem der Inhalt bereits auf dem Bildschirm angezeigt wird. Das kann beispielsweise das Herunterladen der nächsten E-Mail in einer Webmailanwendung oder das Senden von Analysen an einen Anbieter beinhalten. Aus Sicht des Benutzers erscheint die Website möglicherweise fertig geladen, jedoch werden oft beträchtliche Aufgaben ausgeführt, die die allgemeine Reaktionsfähigkeit beeinträchtigen können.

CPU-Zeit – Moderne Webbrowser sind fast ausschließlich durch die Geschwindigkeit der CPU beschränkt. Das Abladen der Arbeit auf die GPU und das Entwickeln effizienterer CPUs haben große Auswirkungen auf die Leistung.

Ressourcennutzung – Um einen schnellen Browser zu entwickeln, muss sichergestellt werden, dass alle Ressourcen im PC gut aufeinander abgestimmt sind. Dazu zählen Netzwerknutzung, Verwendungsmuster des Arbeitsspeichers, GPU-Verarbeitung, Grafik, Arbeitsspeicher sowie Hunderte weiterer Dimensionen. Da Benutzer auf ihren PCs mehrere Anwendungen gleichzeitig ausführen, müssen Browser diese Ressourcen verantwortungsvoll mit anderen Anwendungen teilen.

Energieverbrauch – Höhere Energieeffizienz führt zu einer längeren Akkulebensdauer bei Mobilszenarien, niedrigeren Energiekosten für das Gerät sowie einer geringeren Umweltbelastung.

Mit der Konzentration auf nur eine Metrik würde die Leistung zu einseitig bewertet werden. Wenn sich Menschen auf eine einzige Metrik konzentrieren, tendieren sie normalerweise dazu, auf die Optimierung dieser Metrik hinzuarbeiten, was oft auf Kosten anderer Metriken geschieht, die genauso wichtig sind. Dieser Tendenz kann nur damit begegnet werden, alle Aspekte von Leistung zu messen und anschließend bewusst Kompromissentscheidungen zu treffen.

Das Performance Lab misst insgesamt über 850 verschiedene Metriken. Jede stellt einen Teil des Gesamtbilds der Browserleistung dar. Um Ihnen ein Gefühl dafür zu geben, was wir messen, folgt hier eine (unvollständige) Liste von Schlüsselmetriken: Privater Arbeitssatz, gesamter Arbeitssatz, HTTP-Anforderungsanzahl, empfangene TCP-Bytes, Anzahl geladener Binärdateien, Anzahl von Kontextwechseln, DWM-Videospeichernutzung, Prozentsatz der GPU-Nutzung, Anzahl der Farben, CPU-Zeit bei JavaScript-Speicherbereinigung, CPU-Zeit bei JavaScript-Analyse, durchschnittliches Intervall für DWM-Aktualisierung, gesamter Spitzenarbeitssatz, Anzahl von Heapzuweisungen, Größe der Heapzuweisungen, Anzahl herausragender Heapzuweisungen, Größe herausragender Heapzuweisungen, CPU-Zeit im Layoutsubsystem, CPU-Zeit im Formatierungssubsystem, CPU-Zeit im Renderingsubsystem, CPU-Zeit im HTML-Parser-Subsystem, CPU-Zeit im Leerlauf, Anzahl von Threads.

Ereignisablaufverfolgung für Windows

Metriken werden mithilfe der Ereignisablaufverfolgung für Windows (ETW) und VMMap gesammelt. ETW ist das Windows-weite Ereignisprotokollierungssystem, das von vielen Windows-Komponenten und Drittanbieteranwendungen verwendet wird, darunter das Windows-Ereignisprotokoll. ETW-Protokollierungs-APIs werden auf einer extrem niedrigen Ebene und mit wenig Mehraufwand ausgeführt, was für Leistungstests entscheidend ist.

Die Ansicht zeigt sechs vertikal gestapelte Diagramme. Die Diagramme sind mit "CPU Usage by Process", "Generic Events", "WinINet End-to-End Downloads", "IE CPU Breakdown", "WinInet Transfer Setups" und "IE Repaint" benannt.

Der in WPT enthaltene Ablaufverfolgungs-Viewer, xperfview.exe, ist eine leistungsstarke Schnellansicht, die die Korrelation und Überlagerung von Kernel-, CPU-, GPU-, E/A-, Netzwerk- und anderen Ereignissen ermöglicht. WPT unterstützt außerdem Stackwalking. Beim Stackwalking wird in regelmäßigen Abständen eine Momentaufnahme vom Callstack des Programms erfasst und im Rahmen der Ablaufverfolgung gespeichert. Durch die Korrelation von ETW-Ereignissen mit Stapeln wird in WPT nicht nur angezeigt, welche Arbeit verrichtet wurde, sondern auch der mit dieser Arbeit verknüpfte Callstack sowie die dafür benötigte Zeit mit einer Auflösung von 10 Mikrosekunden. Stackwalking kann für jeden Prozess aktiviert werden, auch für solche, die keine ETW-Ereignisse verwenden. Der Nachteil von Stackwalking ist, dass zum Decodieren der Stapel Debuggingsymbole erforderlich sind und dass eine Anfälligkeit für Aliasing besteht.

Testen eines Szenarios

Das letzte Teil des Puzzles ist der eigentliche Testvorgang. Das Testen kann in drei Phasen unterteilt werden: Einrichtung, Testen sowie Fehler und Bereinigung. Hier sehen Sie ein Flussdiagramm des gesamten Prozesses.

Ein komplexes Flussdiagramm, das mit "User requests run" beginnt und mit "Run is marked finished" endet

Einrichtung

Der Prozess beginnt, wenn ein Benutzer einen Testlauf durch die Laborwebsite oder das Automationsframework anfordert. Der Testlauf wird mit anderen ausstehenden Testläufen in einer Prioritätswarteschlange platziert. Wenn ein Testclient verfügbar wird, prüft dieser die Warteschlange und startet den Auftrag mit der höchstmöglichen Priorität. Zuerst wird vom Testclient das angegebene Testbetriebssystem installiert. Das IE Performance Lab unterstützt Tests auf Vista, Windows 7 und Windows 8. Vom Testclient wird für jede Ausführung eine frische Kopie des Testbetriebssystems installiert, damit der Computer immer in einem ordnungsgemäßen Zustand gestartet wird.

Nachdem das Testbetriebssystem installiert wurde, werden WPT, VMMap und die Testumgebung vom Client konfiguriert. Beim Testlauf wird außerdem eine Reihe von IE-Einstellungen festgelegt, wie Startseite, die Verwendung vorgeschlagener Sites, InPrivate-Browsen usw. Zu diesem Zeitpunkt wird auch eventuelle Drittanbietersoftware installiert.

Im letzten Schritt vor dem Test wird sichergestellt, dass sich der Testclient im Leerlauf befindet, um die Testbeeinflussung zu minimieren. In Windows ist ein Konzept von Leerlaufaufgaben definiert. Leerlaufaufgaben sind für Windows und andere Entwickler eine Möglichkeit, weniger wichtige Aufgaben zu einem späteren Zeitpunkt auszuführen, wenn vom Benutzer keine Ressourcen beansprucht werden. Zu den Leerlaufaufgaben des Betriebssystems zählen unter anderem Vorabruf oder SuperFetching, Datenträgerdefragmentierung sowie das Aktualisieren von Suchindizes, je nach Betriebssystemversion und konfigurierten Diensten. Um sicherzustellen, dass während der Tests keine Leerlaufaufgaben ausgeführt werden, wird die Warteschlange der Leerlaufaufgaben geleert. Außerdem wird Windows Defender angehalten, und der Protokollspeicherort für die Testumgebung wird vom Windows-Indexdienst ausgeschlossen, damit die Protokoll- und Ablaufverfolgungsdateien nicht dazu führen, dass die Indexerstellung während eines Testlaufs gestartet wird. Der Test wird in mehreren Durchgängen ausgeführt, um die Anzahl der erforderlichen Anbieter zu minimieren, da zusätzliche Anbieter den Beobachtereffekt verstärken können. Der erste Durchgang dient immer zum Aufwärmen. Durch das Aufwärmen wird sichergestellt, dass die Binärdateien des Browsers "warm" sind und die Höchstmenge an zwischenspeicherbaren Seiteninhalten im WinINET-Cache verfügbar ist. Die nachfolgenden Durchgänge konzentrieren sich jeweils auf einen bestimmten Typ von Instrumentation, wie Stackwalking, Speicherablaufverfolgung sowie E/A- und Registrierungsablaufverfolgung.

Fehler und Bereinigung

Wenn der Browser zu irgendeinem Zeitpunkt des Tests abstürzt, gilt der Testdurchgang als fehlgeschlagen, und der Testlauf wird mit dem nächsten Durchgang fortgesetzt. Wenn Windows zu irgendeinem Zeitpunkt des Tests abstürzt, wird der Computer neu gestartet und das Betriebssystem neu installiert, da sein Zustand nicht sicher überprüft werden kann. Wenn die Anzahl der Versuche den Grenzwert übersteigt, gilt der gesamte Testlauf als fehlgeschlagen, und der Computer wird für einen anderen Testlauf verwendet, um zu verhindern, dass ein unstabiler Build endlos getestet wird.

Wenn alle Testfälle abgeschlossen sind, werden die Protokolle und Ablaufverfolgungen vom Testclient zur Analyse hochgeladen. Der Testclient kehrt dann in den Leerlauf zurück und ruft einen neuen Testlauf ab.

Ergebnisanalyse

Für alle Metriken wird jede Änderung nachverfolgt. Um genügend Stichproben zu erhalten, wird jeder Testfall mindestens zehnmal ausgeführt, und die Testläufe werden auf mindestens zwei verschiedenen Computern verdoppelt. Mithilfe von Statistiktools können untypische Ergebnisse automatisch für die Untersuchung gekennzeichnet werden. Eine Abweichungsänderung gilt ebenfalls als Rückschritt. Benutzer interagieren mit IE in vielen verschiedenen Situationen und mit unterschiedlicher Hardware, und eines unserer Ziele besteht darin, jederzeit ein reibungsloses und berechenbares Erlebnis zu gewährleisten.

Neben der automatisierten Analyse untersucht ein Sichtungsteam die täglichen Ergebnisse auf Trends und andere interessante Verhaltensweisen. Auf eine manuelle Untersuchung kann nicht verzichtet werden, da viele Statistiktools von einer Normalverteilung und der Unabhängigkeit aller Stichproben ausgehen. Keine dieser Annahmen wird bei unseren Messungen vollständig erfüllt. Manche Aktivitäten in IE werden von einem Zeitgeber des Betriebssystems gesteuert, sodass die Ergebnisse auch davon abhängen, wann (im Verlauf des Zeitgeberzyklus) das Laden der Seite beginnt. Wenn das Laden einer Seite direkt vor oder nach einem Zeitgeberinterrupt beginnt, kann dadurch mehr bzw. weniger Arbeit anfallen, da IE den Interrupt an verschiedenen Punkten im Seitenladevorgang bedienen muss. Diese Unterbrechung kann einen Welleneffekt haben, der zu einer bimodalen Verteilung führt. Da wir außerdem wiederholte Testläufe verwenden (ohne den Computer zwischen Durchläufen zu bereinigen), wird der nachfolgende Testlauf durch die vorherigen beeinflusst. Hier sehen Sie ein Beispieldiagramm der verstrichenen Zeit für einen Änderungsvergleich für Bing Maps.

Ein Balkendiagramm mit einer roten überlagerten Linie. Ein Mauszeiger bewegt sich über einen Punkt im Diagramm, und daneben wird eine QuickInfo mit Informationen wie "max", "median", "min" usw. angezeigt.

Die rote Reihe zeigt den Mittelwert jedes Testlaufs, und graue Balken geben den Bereich an. Beim Bewegen des Mauszeigers über einen Testlauf werden die Durchläufe für die Metrik (in blau) sowie eine QuickInfo mit den genauen Werten für Mindest-, Mittel- und Höchstwert sowie der absoluten und relativen Differenz zum vorherigen Testlauf angezeigt. Die QuickInfo in dieser Abbildung enthält außerdem zusätzlichen Kontext wie den zu testenden Build sowie einen Quicklink zu unserem Quellcodeverwaltungssystem zum Anzeigen der Änderungen im Build.

Durch die Kombination aus automatisierter Analyse und manueller Untersuchung erhält das IE-Team zuverlässige und nutzbare Daten für die Leistungsoptimierung.

Testen von Drittanbietersoftware

Viele Drittanbieteranwendungen basieren auf Trident, dem Netzwerkstapel und anderen IE-Komponenten. Erweiterungen wie BHOs und Symbolleisten werden innerhalb des IE-Kontexts geladen. Andere Anwendungen wie Sicherheitssoftware können sich selbst zwischen IE-Komponenten einfügen. Diese Anwendungen werden Teil des IE-Stapels und können die Leistung beeinträchtigen. Das Performance Lab kann die Auswirkung von Drittanbietersoftware auf das Browsen in realen Inhalten in einer kontrollierten Umgebung messen. Diese Untersuchungen sind wichtig für IE und das Ökosystem, da Benutzer die Auswirkung von verbreiteter Software auf das Browsererlebnis im Allgemeinen nicht quantitativ bestimmen können.

Beim Testen der Auswirkung von Drittanbietersoftware vergleichen wir einen Testlauf mit installierter Drittanbietersoftware mit einem sauberen Testlauf, bei dem nur IE installiert ist, um die Auswirkung zu ermitteln. Im Einzelnen sind wir an der Messung von zwei Metriken interessiert: Startzeit und Navigationszeit. Bei der Startzeit wird die Zeitspanne gemessen, in der der Browser gestartet und zu einer URL navigiert wird, während die Navigationszeit die Zeitspanne angibt, in der zu einer URL navigiert wird, wenn der Browser bereits gestartet wurde. Zur Startzeit zählt auch die Zeit, die Drittanbieteranwendungen zum Laden der zugehörigen IE-Erweiterungen benötigen.

Die Verwendung zwischengespeicherter Inhalte sorgt für die Wiederholbarkeit bei unseren Messungen. Außerdem können wir durch das Messen einer zwischengespeicherten Website definitiv bestimmen, dass ein Leistungsrückgang durch eine Drittanbietersoftware und nicht durch Abweichungen auf der Website verursacht wird. Bei jeder Messung der Auswirkung von Drittanbietersoftware überprüfen wir unsere Ergebnisse auch durch das Testen von Start und Navigation mit einer direkten Verbindung zum Internet, um auszuschließen, dass die Testumgebung für etwaige Deltas verantwortlich ist.

Die Arbeit während einer Seitennavigation wird von vielen Drittanbieteranwendungen auf Cloud-Dienste abgeladen. Während die Parallelisierung von Arbeit und die Nutzung von Cloud-Diensten ausgezeichnete Techniken zum Verbessern der Leistung sind, warten einige Anwendungen synchron auf die Ergebnisse aus dem Netzwerk und blockieren dabei die Navigation. Es gibt viele reale Szenarien wie strikte Firewalls, WAN-Verbindungen und Offlineszenarien, bei denen solche Muster zu einer schwachen Leistung für Benutzer führen können. Drittanbietersoftware sollte niemals synchron in Reaktion auf eine IE- oder Benutzeraktion verarbeitet werden, und Benutzeroberflächen- und DOM-Aktualisierungen sollten gestapelt werden, um die Unterbrechung zu minimieren.

Erstellen eines schnellen Browsers für Benutzer

Auf die reale Browserleistung kommt es an. Das Messen der Leistung im Maßstab ist eine wichtige Investition und ein Vollzeitjob, aber die Ergebnisse sind die Mühe wert. Die vom Internet Explorer Performance Lab gesammelten Daten sind entscheidend für unser Verständnis der Browserleistung und der zugrunde liegenden PC-Hardware sowie für die Entwicklung eines flüssigen und reaktionsschnellen Weberlebnisses für Benutzer.

—Matt Kotsenas, Jatinder Mann und Jason Weber für das Internet Explorer Performance Team

  • Loading...
Leave a Comment
  • Please add 6 and 7 and type the answer here:
  • Post