Laboratoire de performances Internet Explorer : mesures fiables des performances des navigateurs
Ce blog est en grande partie consacré à montrer au plus près tout le travail dédié à la conception de Windows 8. Dans ce billet, nous allons regarder ce qui nous importe beaucoup à tous (en tant qu'ingénieur et en tant qu'utilisateur final) : les performances Web réelles. Nous travaillons énormément pour aller encore plus loin et créer une navigation Web hautes performances. Ce billet a été rédigé par Matt Kotsenas, Jatinder Mann et Jason Weber de l'équipe IE, même si tous les membres de l'équipe travaillent sur les performances. --Steven
Les performances Web importent à tous, et un des objectifs d'ingénierie pour Internet Explorer est d'être le navigateur le plus rapide du monde. Pour atteindre cet objectif, nous devons mesurer les performances du navigateur par rapport aux scénarios réels qui sont importants pour nos clients. Au cours des cinq dernières années, nous avons conçu et créé un laboratoire de performances Internet Explorer, qui est un des systèmes de mesure des performances Web les plus sophistiqués du monde.
Le laboratoire de performances IE recueille des données fiables, précises et productives afin de guider les décisions tout au long du cycle de développement. Nous mesurons les performances d'Internet Explorer 200 fois par jour, recueillant ainsi plus de 5,7 millions de mesures et 480 Go de données d'exécution chaque jour. Nous comprenons l'impact de chaque changement dans le produit et nous vous assurons qu'Internet Explorer n'est que plus rapide. Ce billet explique de façon détaillée la façon dont le laboratoire de performances IE est conçu et comment nous l'utilisons afin de rendre constamment le Web plus rapide.
Dans ce billet, nous présentons les sections suivantes :
- Présentation du laboratoire de performances IE
- Infrastructure du laboratoire
- Ce que nous mesurons (et comment)
- Test d'un scénario
- Investigation des résultats
- Test de logiciels tiers
- Création d'un navigateur rapide pour les utilisateurs
Présentation du laboratoire de performances IE
Afin de mesurer de façon fiable les performances Web au fil du temps, un système doit être capable de simuler de façon reproductible des scénarios d'utilisateurs réels. En substance, notre système doit créer une « version miniature d'Internet ».
Le laboratoire de performances IE est un réseau privé entièrement étanche par rapport à l'Internet public et au réseau Intranet de Microsoft, et il contient plus de 140 machines. Le laboratoire contient les principaux composants du vrai Internet, y compris des serveurs Web, des serveurs DNS, des routeurs et des émulateurs réseau, qui simulent différents scénarios de connexion des clients.
Bien que cela puisse paraître complexe au premier coup d'œil, cette approche permet à toutes les sources de divergences d'être écartées. En contrôlant chaque aspect du réseau, jusqu'au moindre relais et à la moindre latence du paquet, nos tests deviennent déterministes et reproductibles, ce qui est primordial pour rendre les résultats recevables. Dans le laboratoire de performances IE, l'activité se mesure avec une résolution de 100 nanosecondes.
Ce type de configuration réseau offre également une grande flexibilité. Comme nous simulons une configuration réelle, notre laboratoire peut accueillir presque n'importe quel type de machine de test ou de contenu de site Web. Le laboratoire de performances IE prend en charge les ordinateurs de bureau, les ordinateurs portables, les miniportables et les tablettes avec des processeurs x86, x64 et ARM, le tout simultanément. De même, comme le laboratoire utilise les outils de performances Windows (WPT), nous pouvons exécuter les mêmes tests à l'aide de différents navigateurs Web, barres d'outils, produits antivirus ou d'autres logiciels tiers et comparer directement les résultats.
Les outils de performances Windows donnent une vision détaillée du matériel sous-jacent. À l'aide des outils de performances Windows, nous pouvons capturer tous les éléments, de l'activité UC et GPU de haut niveau aux informations de bas niveau, telles que l'efficacité du cache, les statistiques réseau, les modes d'utilisation de la mémoire et bien plus. Les outils de performances Windows nous permettent de mesurer et d'optimiser les performances sur la pile afin de nous assurer que le matériel, les pilotes de périphériques, le système d'exploitation Windows et Internet Explorer sont tous optimisés efficacement ensemble.
L'exécution d'une seule série de tests dure 6 heures et génère plus de 22 Go de données pendant ce laps de temps. Ce système hautement automatisé intègre une petite équipe chargée de gérer les opérations, d'analyser les résultats et de développer de nouvelles fonctionnalités d'infrastructure.
Infrastructure du laboratoire
L'infrastructure du laboratoire de performances peut se décomposer en trois catégories principales : Réseau et serveur, Clients de test et Analyse et rapports. Chaque catégorie est conçue pour réduire l'interaction entre les composants, à la fois pour améliorer l'évolutivité des tests et pour réduire la possibilité d'introduction d'interférences dans l'environnement du laboratoire.
Vue du laboratoire de performances IE comprenant plusieurs machines de test et d'analyse sur notre réseau privé.
Infrastructure réseau et serveur
Commençons par parler de tous les composants qui créent ensemble la version miniature d'Internet : les serveurs DNS, les émulateurs réseau et les serveurs de contenu. Au cours des trois prochaines sections, nous parcourrons le diagramme architectural de droite à gauche.
Serveurs de contenu
Les serveurs de contenu sont des serveurs Web qui remplacent les millions d'hôtes Web d'Internet. Chaque serveur de contenu héberge des pages Web réelles qui ont été capturées en local. Les pages capturées suivent un processus que nous désignons sous le terme de « nettoyage », au cours duquel nous corrigeons des parties du contenu Web afin d'obtenir un déterminisme reproductible. Par exemple, les fonctions JavaScript Date ou les appels Math.Random() sont remplacés par une valeur statique. En outre, les URL dynamiques créées par des structures publicitaires sont verrouillées sur la première URL utilisée par la structure.
Après le nettoyage, le contenu est affiché de la même façon que le contenu statique par l'intermédiaire d'un filtre ISAPI qui associe un code de hachage de l'URL au contenu, permettant ainsi une recherche instantanée. Chaque serveur Web est une machine à 16 cœurs avec 16 Go de RAM pour réduire la variabilité et s'assurer que le contenu est en mémoire (aucun accès au disque n'est requis).
Les serveurs de contenu peuvent également héberger des applications Web dynamiques, telles que Outlook Web Access ou Office Web Apps. Dans ce cas, le serveur d'applications et les dépendances multiniveau sont hébergés sur des serveurs dédiés dans le laboratoire, tout comme dans les environnements réels.
Émulateurs réseau
Comme de nombreuses sources de variabilité ont été supprimées, les vitesses réseau ne reflètent plus l'expérience de nombreux utilisateurs avec des connexions lentes. Pour simuler les environnements réels des clients, un test peut tirer parti de l'émulation réseau pour comprendre les performances sur la vaste gamme des réseaux utilisés de nos jours. Le laboratoire prend en charge l'émulation de plusieurs configurations DSL, des modems câblés, des modems 56k, ainsi que des environnements à bande passante élevée et à latence élevée, tels que les environnements WAN et 4G. Lorsque les requêtes HTTP sont transmises à l'émulateur, celui-ci simule les caractéristiques réseau, telles que le délai et la réorganisation du paquet, puis transmet la requête aux hôtes Web. Lors de la réception de la réponse, l'émulation est à nouveau appliquée, puis retransmise au client de test.
L'utilisation d'un matériel dédié à l'émulation réseau fournit l'environnement de test le plus réaliste possible, et réduit de façon importante l'effet d'observateur. Même si le matériel dédié augmente le coût et renforce la complexité par rapport au proxy ou aux solutions logicielles, c'est la seule façon de mesurer les performances de façon précise. Comme les navigateurs limitent le nombre de connexions proxy simultanées pour empêcher la saturation du proxy, l'utilisation d'un proxy pour l'émulation réseau a l'effet involontaire de contourner le partitionnement du domaine et d'autres optimisations effectuées par la page Web. En outre, l'émulation d'un réseau local entre en compétition avec le navigateur pour ce qui concerne les ressources des machines locales, en particulier sur les machines à faible consommation d'énergie.
Serveurs DNS
Comme les serveurs DNS réels, les serveurs DNS du laboratoire associent les serveurs de contenu aux clients de test. Le laboratoire utilise également un serveur DNS différent pour chaque émulateur réseau, ce qui signifie que changer la vitesse d'un réseau est aussi simple que changer le serveur DNS. Dans ce cas, au lieu de résoudre les noms de domaines sur les hôtes Web, le serveur DNS résout tous les noms de domaines sur l'émulateur réseau associé.
Configurations des clients de test
Nous voulons nous assurer qu'Internet Explorer s'exécute rapidement de façon cohérente sur toutes les classes de matériel informatique. Le laboratoire contient plus de 120 ordinateurs qui permettent de mesurer les performances d'Internet Explorer. Nous les désignons sous le nom de clients de test. Ils prennent la forme d'ordinateurs de bureau x64 haut de gamme, de miniportables à faible consommation d'énergie, de tablettes tactiles et de tout périphérique intermédiaire. Comme il est d'une importance capitale que les mesures puissent être répétées, tous les clients de test sont des machines physiques.
Pools de machines de comparaison des modifications dans laboratoire de performances Internet Explorer
Les différentes classes de machines contiennent des plateformes graphiques à la fois discrètes et intégrées pour s'assurer qu'Internet Explorer continue à tirer parti de l'accélération matérielle dans tout l'écosystème des périphériques. L'image ci-dessus représente notre pool de machines principal. Ces PC visent à se rapprocher de l'expérience moyenne des clients sur la durée de vie d'un PC Windows 7 ou Windows 8. Les machines commandées auprès du fabricant d'ordinateurs OEM doivent être identiques. Elles proviennent toutes du même lot de fabrication et les caractéristiques de leurs performances sont vérifiées avant d'être utilisées.
Comme le laboratoire fonctionne 24 heures sur 24 et 7 jours sur 7, les pannes matérielles sont inévitables. Le remplacement des composants défaillants par des pièces identiques provenant d'un autre lot de fabrication entraîne presque toujours une situation dans laquelle l'ordinateur réparé s'exécute plus rapidement que les autres machines du pool. Bien que cette différence puisse passer inaperçue dans le monde réel, lorsque vous effectuez des mesures à 100 nanosecondes près, même quelques cycles peuvent influer sur les résultats ! Si, après avoir été réparée, une machine ne s'exécute plus de la même manière que le reste du pool, elle est retirée du laboratoire et la taille du pool est définitivement réduite. En réponse à cette situation, les achats du laboratoire incluent des machines « tampon » supplémentaires, de sorte que lorsque une machine défaillante est retirée du pool, la capacité supplémentaire procure une sécurité et les opérations du laboratoire ne sont pas affectées.
Nom du pool |
Nombre de machines |
Format |
Processeur |
Arch |
Vitesse d'horloge |
RAM |
Graphismes |
Pool principal |
32 |
Ordinateur de bureau |
Core i5 750 (Lynnfield) |
64 bits |
2,66 GHz |
4 096 Mo DDR3 |
NVIDIA GeForce 310 |
Pour augmenter l'ampleur matérielle, nous avons des pools de machines supplémentaires qui exécutent tous les scénarios des utilisateurs. Des performances optimales sur ces machines assurent qu'IE utilise le matériel sous-jacent efficacement sur tout l'écosystème des PC.
Nom du pool |
Nombre de machines |
Format |
Processeur |
Arch |
Vitesse d'horloge |
RAM |
Graphismes |
Haut de gamme 1 |
20 |
Ordinateur de bureau |
Core i7 870 |
64 bits |
2,93 GHz |
4 096 Mo DDR3 |
ATI Radeon HD 4550 |
Haut de gamme 2 |
4 |
Ordinateur de bureau |
Xeon 5150 (Woodcrest) |
64 bits |
2,66 GHz |
8 192 Mo DDR2 |
ATI Radeon X1950 Pro |
Moyenne gamme 1 |
6 |
Ordinateur de bureau |
Core 2 Duo (Wolfdale) |
64 bits |
3,0 GHz |
4 096 Mo DDR2 |
Intel GMA 4500 |
Moyenne gamme 2 |
15 |
Ordinateur de bureau |
Core 2 Duo E6750 |
64 bits |
2,66 GHz |
4 096 Mo DDR2 |
ATI Radeon HD 2400 XT |
Moyenne gamme 3 |
25 |
Ordinateur de bureau |
Core i5 2500 |
64 bits |
3,30 GHz |
4 096 Mo DDR3 |
Intel HD Graphics 2000 |
Moyenne gamme 4 |
6 |
Ordinateur de bureau |
Core 2 Duo (Conroe) |
64 bits |
2,66 GHz |
4 096 Mo DDR2 |
ATI Radeon HD 2400XT |
Moyenne gamme 5 |
4 |
Ordinateur de bureau |
Core 2 Duo (Conroe) |
64 bits |
2,4 GHz |
4 096 Mo DDR2 |
ATI Radeon X1950 Pro |
Basse consommation 1 |
2 |
Ordinateur portable |
Atom Z530 |
32 bits |
1,6 GHz |
2 038 Mo DDR2 |
Intel GMA 500 |
Basse consommation 2 |
4 |
Miniportable |
Atom N270 |
32 bits |
1,6 GHz |
1 024 Mo DDR2 |
NVIDIA ION |
Basse consommation 3 |
2 |
Miniportable |
Atom N450 |
64 bits |
1,66 GHz |
1 024 Mo DDR2 |
Intel GMA 3150 |
Basse consommation 4 |
4 |
Miniportable |
Atom N270 |
32 bits |
1,6 GHz |
1 024 Mo DDR2 |
Intel GMA950 |
Basse consommation 5 |
4 |
Tablette tactile |
ARM |
32 bits |
— |
— |
— |
Prototype matériel |
— |
— |
— |
— |
— |
— |
— |
Machines de test à faible consommation d'énergie. L'état de test de chacune est différent.
Si une plus grande diversité est nécessaire, le laboratoire de performances peut également utiliser le laboratoire graphique Windows. Ce laboratoire stocke presque toutes les puces graphiques qui sont fabriquées. Les PC peuvent être configurés dans presque toutes les permutations imaginables, puis utilisés pour tester les performances. Le laboratoire graphique Windows présente un intérêt inestimable pour diagnostiquer les problèmes graphiques sur les puces et les révisions de pilotes.
Serveurs d'analyse et de rapports
La collecte et l'analyse des résultats des tests se décomposent en deux étapes distinctes. En se déchargeant des analyses sur les machines dédiées, les clients de test peuvent entamer plus tôt une autre série de tests des performances. Des machines de classe serveur plus puissantes peuvent alors être utilisées pour effectuer l'analyse plus rapidement. Plus l'analyse se termine tôt et plus nous pouvons identifier les changements de performances efficacement.
Pour l'analyse, nous utilisons 11 machines de classe serveur, chacune étant dotée de 16 cœurs et de 16 Go de RAM. Au cours de l'analyse, chaque fichier de trace est inspecté et des milliers de mesures sont extraits et insérés dans un serveur SQL. Sur 24 heures, ces machines d'analyse inspectent plus de 15 000 traces qui seront utilisées pour l'analyse des tendances.
Image de deux racks de serveurs contenant des serveurs de fichiers, un serveur SQL et plusieurs serveurs d'analyse et de contenu.
Le serveur SQL utilisé pour stocker les presque 6 millions de mesures que nous recueillons chaque jour est une machine dotée de 24 cœurs logiques et de 64 Go de RAM. Les rapports peuvent être générés directement à partir de SQL, ou les résultats peuvent être inspectés à l'aide d'une application de comparaison HTML ou d'un service WCF qui fournit les résultats aux formats XML ou JSON.
Ce que nous mesurons (et comment)
Une fois l'infrastructure en place, examinons les différents types de scénarios mesurés dans le laboratoire de performances, ainsi que les outils que nous utilisons pour recueillir les mesures.
Scénarios mesurés quotidiennement
Le laboratoire de performances se concentre sur les scénarios réels importants pour les utilisateurs. Par conséquent, nous réalisons plus de 20 000 tests différents chaque jour. Ces tests entrent dans quatre catégories (qui se chevauchent parfois) :
Chargement du contenu : le passage d'une page à une autre reste l'activité la plus répandue au sein d'un navigateur Web. Le chargement du contenu Web est également la seule catégorie qui touche la plupart des onze sous-systèmes du navigateur. Le chargement du contenu Web est un prérequis pour les autres catégories de scénarios.
Applications Web interactives : cette catégorie couvre ce qui est parfois désigné sous le nom de création de contenu, applications AJAX ou sites Web 2.0. Elle inclut l'interaction avec des sites d'actualités courants et des sites de réseaux sociaux, ainsi que l'interaction avec des applications de messagerie et de documents, telles qu'Outlook Web Access et Office Web Apps.
L'application IE : des scénarios importants, mais souvent oubliés, sont ceux qui interagissent avec le navigateur lui-même. Les interactions courantes comprennent l'ouverture ou la fermeture du navigateur, le changement d'onglets, l'utilisation des fonctionnalités du navigateur, telles que Historique et Favoris, ainsi que le déplacement et le zoom avec le clavier et la souris, et les saisies tactiles.
Repères synthétiques : les repères synthétiques, tels que WebKit SunSpider, sont rarement oubliés mais souvent exagérés. Les repères peuvent constituer un outil d'ingénierie utile, car ils sont conçus pour mettre en avant les sous-systèmes de chaque navigateur et pour accentuer les différences entre les navigateurs. Cependant, afin de maximiser ces différences, les repères recourent souvent à des modes d'utilisation atypiques ou à des cas limites.
Modes d'utilisation réels
Lorsque l'on mesure les performances, il est important de s'assurer que les tests reflètent les modes d'utilisation réels. La plupart des manuels d'ingénierie logicielle font référence à ce processus sous le terme de modélisation de la charge de travail ou de modélisation de l'utilisation des applications. Pour garantir que le laboratoire de performances mesure les modes d'utilisation réels, il utilise des pages Web réelles qui représentent les modes d'utilisation réels et utilisent différents sous-systèmes de navigateurs.
Afin de déterminer quels sites utiliser pour les tests, nous analysons régulièrement des millions de sites et compilons une liste d'attributs de sites et de modes de codage. Nous utilisons 68 éléments différents pour déterminer les points communs entre les sites (profondeur et largeur du DOM obtenu, modes de présentation CSS, structures communes utilisées, fonctionnalités internationales et bien plus. D'après les résultats, nous choisissons les sites qui représentent le mieux les modes communs et la diversité du Web.
Mesures d'ingénierie
Les performances constituent un problème à plusieurs dimensions. La seule façon d'obtenir une vue précise sur les performances est de comprendre le scénario que vous testez et comment le matériel et le système d'exploitation interagissent avec le navigateur. Examinons de plus près cinq mesures de performances importantes dans le contexte du premier chargement d'un site sportif majeur.
Temps d'affichage : le temps d'affichage mesure le temps qui s'écoule entre le moment où l'utilisateur effectue une action et le moment où il voit le résultat de cette action à l'écran.
Temps écoulé : la plupart des sites continuent à effectuer un travail en arrière-plan une fois le contenu affiché à l'écran. Par exemple, le site peut télécharger le prochain message électronique dans une application de messagerie Web ou renvoyer des études analytiques au fournisseur. Du point de vue de l'utilisateur, le site semble avoir terminé. Pourtant, un travail important a souvent lieu, qui peut avoir un impact sur la réactivité globale.
Temps processeur : les navigateurs Web modernes sont presque exclusivement limités par la vitesse du processeur. Décharger le travail sur le GPU et rendre le processeur plus efficace impactent énormément les performances.
Utilisation des ressources : la création d'un navigateur rapide implique de s'assurer que les ressources du PC entier fonctionnent parfaitement ensemble, notamment l'utilisation du réseau, les modes d'utilisation de la mémoire, le traitement du GPU, les graphiques, la mémoire et des centaines d'autres aspects. Comme les utilisateurs exécutent plusieurs applications en même temps sur leurs PC, il est important que les navigateurs partagent d'une façon responsable ces ressources avec d'autres applications.
Consommation d'énergie : l'optimisation de l'efficacité énergétique entraîne une prolongation de la durée de vie de la batterie dans les scénarios mobiles, une baisse des coûts en électricité pour l'appareil et une réduction de l'impact environnemental.
Le fait de se concentrer uniquement sur une seule mesure entraîne une vision exagérément simpliste des performances. En se concentrant sur une seule mesure, les êtres humains ont naturellement tendance à optimiser cette mesure, au détriment d'autres mesures aussi importantes. La seule façon de combattre cette tendance est de mesurer tous les aspects des performances, puis de faire des compromis de manière consciente, et non implicite.
Au total, le laboratoire de performances mesure plus de 850 données différentes. Chacune procure une partie de l'ensemble des performances du navigateur. Pour donner un aperçu de ce que nous mesurons, voici une liste (non exhaustive) des principales données : jeu de travail privé, jeu de travail total, nombre de requêtes HTTP, octets TCP reçus, nombre de binaires chargés, nombre de commutateurs de contexte, utilisation de la mémoire vidéo DWM, pourcentage de l'utilisation GPU, nombre d'images, temps processeur écoulé en nettoyage de la mémoire JavaScript, temps processeur écoulé en analyse JavaScript, intervalle de mise à jour DWM moyen, jeu de travail total maximal, nombre d'allocations de segments, taille des allocations de segments, nombre des allocations de segments restantes, taille des allocations de segments restantes, temps processeur écoulé à disposer le sous-système, temps processeur écoulé à formater le sous-système, temps processeur écoulé à rendre le sous-système, temps processeur écoulé à effectuer une analyse HTML du sous-système, temps processeur d'inactivité, nombre de threads.
Infrastructure de suivi d'événements Windows
Les mesures sont recueillies à l'aide de l'infrastructure de suivi d'événements Windows (ETW) et de VMMap. ETW est le système de consignation des événements de Windows qui est utilisé par de nombreux composants Windows et applications tierces, notamment le journal des événements Windows. Les API de consignation d'ETW sont d'un niveau extrêmement bas et d'une faible charge, ce qui est primordial pour tester les performances.
La visionneuse de suivi comprise dans WPT, xperfview.exe, est un visualiseur puissant qui permet la corrélation et la superposition d'événements de noyaux, processeur, GPU, E/S, mise en réseau et autres. WPT prend également en charge le parcours de la pile. Le parcours de la pile prend une capture instantanée de la pile d'appels du programme à intervalles réguliers et enregistre la pile dans le cadre du suivi. En mettant en corrélation les événements ETW et les piles, WPT affiche non seulement le travail effectué, mais également la pile d'appels associée à ce travail et le temps passé à ce travail, avec une résolution de 10 microsecondes. Le parcours de la pile peut être activé sur n'importe quel processus, même sur ceux qui n'utilisent pas les événements ETW. L'inconvénient du parcours de la pile est qu'il requiert des symboles de débogage pour décoder les piles, et qu'il est sensible au crénelage.
Test d'un scénario
La dernière pièce du puzzle est le processus de test lui-même. Les tests peuvent se décomposer en 3 phases : installation, test, puis erreurs et nettoyage. Voici un diagramme représentant l'intégralité du processus à suivre.
Installation
Le processus démarre lorsqu'un utilisateur demande une série de tests à travers le site Web du laboratoire ou l'infrastructure d'automatisation. La série de tests est placée dans une file d'attente prioritaire avec d'autres séries en attente. Lorsqu'un client de test devient disponible, il contrôle la file d'attente et commence la tâche ayant la plus haute propriété qui lui est possible de gérer. D'abord, le client de test installe le système d'exploitation de test spécifié. Le laboratoire de performances IE prend en charge les tests sur Vista, Windows 7 et Windows 8. Le client de test installe une nouvelle copie du système d'exploitation de test pour chaque série de tests afin que la machine démarre toujours dans un état connu et satisfaisant.
Une fois le système d'exploitation de test installé, le client configure WPT, VMMap et l'atelier de test. La série de tests spécifie également plusieurs paramètres IE, tels que la page d'accueil, l'utilisation des sites suggérés, la navigation InPrivate et d'autres. Les logiciels tiers sont également installés et configurés à ce stade.
L'étape finale avant le test consiste à s'assurer que le client de test est inactif afin de réduire l'interférence des tests. Windows définit un concept de tâches inactives. Les tâches inactives sont un moyen pour Windows et d'autres développeurs de planifier le travail non essentiel ultérieurement, lorsque l'utilisateur n'utilise pas trop de ressources. Parmi les tâches inactives du système d'exploitation figurent le préchargement ou SuperFetching, la défragmentation du disque, la mise à jour des index de recherche et autres, selon la version du système d'exploitation et les services configurés. Pour s'assurer qu'aucune tâche inactive n'est réalisée au cours des tests, la file d'attente des tâches inactives est vidée. En outre, Windows Defender est interrompu et l'emplacement du journal pour l'atelier de test est marqué comme exclu du service d'indexation Windows pour empêcher le journal et les fichiers de trace de déclencher le démarrage de l'indexeur au cours d'une série de tests. Les tests s'effectuent en plusieurs passages afin de réduire le nombre de fournisseurs requis, car les fournisseurs supplémentaires augmentent l'effet d'observateur. Le premier passage est toujours destiné à réaliser une activation. Il s'assure que les binaires du navigateur sont actifs et que la quantité maximale de contenu de page pouvant être mis en cache est disponible dans le cache WinINET. Les passages suivants se concentrent chacun sur un type spécifique d'instrumentation, tels que le parcours de la pile, le suivi de la mémoire et le suivi d'E/S et du registre.
Erreurs et nettoyage
Si à un moment donné du test, le navigateur connaît un blocage, le test est considéré comme ayant échoué et la série passe au prochain passage de test. Si à un moment donné des tests, Windows connaît un blocage, l'ordinateur redémarre et le système d'exploitation est réinstallé, étant donné que son état ne peut pas être garanti. Si le nombre de tentatives dépasse le seuil, la série de tests entière est considérée comme ayant échoué et la machine passe à un autre test pour empêcher de tester sans fin une version logicielle instable.
Une fois tous les tests terminés, le client de test charge les journaux et les suivis pour l'analyse. Le client de test retourne à un état inactif et commence à s'enquérir d'une nouvelle série de tests.
Investigation des résultats
Chaque mesure fait l'objet d'un suivi changement après changement. Nous exécutons chaque cas de test au moins dix fois et dupliquons les tests sur au moins deux machines pour créer les échantillons. À l'aide d'outils statistiques, les résultats non caractéristiques peuvent être automatiquement signalés pour faire l'objet d'une investigation ultérieure. Un changement d'écart est également considéré comme une régression. Les utilisateurs interagissent avec IE dans différentes circonstances et sur une grande diversité de matériels, et un de nos objectifs est d'assurer une expérience homogène et prévisible à chaque fois.
Outre l'analyse automatique, une équipe de triage étudie les résultats quotidiens afin d'observer les tendances et d'autres comportements intéressants. L'investigation manuelle ne peut pas être éliminée, car de nombreux outils statistiques supposent une distribution normale et que tous les échantillons soient indépendants. Aucune de ces deux suppositions n'est strictement vraie pour nos mesures. Certaines activités d'IE sont gérées par une minuterie du système d'exploitation, ce qui signifie que les résultats dépendent également du moment (selon le cycle de la minuterie) où le chargement de la page commence. Un chargement de page qui commence juste avant ou juste après une interruption de la minuterie peut réaliser plus ou moins de travail, car IE doit traiter l'interruption à différents points du processus de chargement de la page. Cette interruption peut avoir une répercussion qui entraîne une distribution bimodale. En outre, comme nous utilisons des essais répétés (et nous ne nettoyons pas la machine entre les itérations), le prochain essai est influencé par les essais précédents. Voici un graphique d'exemple du temps écoulé pour Bing Maps afin de comparer les différents changements.
La série rouge montre la valeur médiane de chaque série de tests et les barres grises montre la plage. Le fait de laisser le curseur sur la série de tests permet d'afficher les itérations de la mesure (en bleu), ainsi qu'une info-bulle qui fournit les valeurs minimale, médiane et maximale exactes, ainsi que la différence absolue et relative avec la série de tests précédente. L'info-bulle qui apparaît dans cette image fournit également un contexte supplémentaire, tel que la version logicielle testée, et un lien rapide vers notre système de contrôle source pour afficher les changements de la version.
La combinaison de l'analyse automatique et de l'investigation manuelle donne à l'équipe IE des données fiables et productives pour optimiser les performances.
Test de logiciels tiers
De nombreuses applications tierces dépendent de Trident, de la pile réseau et d'autres composants IE. Les extensions comme BHO et les barres d'outils se chargent dans le contexte d'IE. D'autres applications, telles que les logiciels de sécurité, peuvent s'immiscer entre les composants IE. Ces applications finissent par faire partie de la pile IE et peuvent entraîner une dégradation des performances. Le laboratoire de performances est capable de mesurer l'impact des logiciels tiers sur la navigation du contenu réel dans un environnement contrôlé. Ces études sont importantes pour IE et pour l'écosystème, car les utilisateurs ne peuvent généralement pas quantifier l'impact d'un logiciel connu sur leur expérience de navigation.
Lorsque nous testons l'impact des logiciels tiers, nous comparons une série de tests avec les logiciels tiers installés, avec une nouvelle série avec seulement IE installé, pour déterminer l'impact des logiciels. En particulier, nous nous intéressons à mesurer deux données : temps de démarrage et temps de navigation. Le temps de démarrage mesure le temps requis pour lancer le navigateur et accéder à une URL, tandis que le temps de navigation mesure le temps requis pour accéder à une URL lorsque le navigateur est déjà lancé. Le démarrage inclut également le temps requis par les applications tierces pour charger leurs extensions IE.
L'utilisation du contenu mis en cache permet à nos mesures d'être répétées. En outre, en mesurant un site mis en cache, nous pouvons déterminer qu'une régression des performances est provoquée par les logiciels tiers et non par les différences du site. Lorsque nous mesurons l'impact des logiciels tiers, nous validons également nos découvertes en testant le démarrage et la navigation sur une connexion directe à Internet, pour vérifier que l'environnement de test n'est pas responsable des deltas.
De nombreuses applications tierces se déchargent du travail sur des services de cloud computing lors de la navigation sur une page. Bien que la mise en parallèle du travail et l'utilisation des services de cloud computing soient d'excellentes techniques pour améliorer les performances, certaines applications attendent de manière synchrone les résultats du réseau, ce qui bloque la navigation dans le processus. Il existe de nombreux scénarios réels, tels que les pare-feux stricts, les connexions WAN et les scénarios hors connexion, dans lesquels ces modes peuvent entraîner des performances médiocres pour les utilisateurs. Les logiciels tiers ne doivent jamais fonctionner de manière synchrone en réponse à une action d'IE ou de l'utilisateur et doivent traiter par lots les mises à jour de l'interface utilisateur et du DOM pour minimiser les perturbations.
Création d'un navigateur rapide pour les utilisateurs
Les performances des navigateurs réels sont importantes. La mesure des performances à l'échelle nécessite un investissement important et un travail à temps plein, mais les résultats le valent bien. Les données rassemblées par le laboratoire de performances Internet Explorer sont instrumentales dans notre compréhension des performances des navigateurs et du matériel du PC sous-jacent, et dans le développement d'une expérience Web rapide, fluide et réactive pour les utilisateurs.
—Matt Kotsenas, Jatinder Mann et Jason Weber pour l'équipe Internet Explorer Performance
Comments
- Anonymous
February 26, 2012
Pourtant, lors de la sortie d'Internet Explorer 9, Microsoft a été accusé d'avoir triché dans son code dans le seul but d'avoir de meilleures notes au test sunspider. www.actualite-francaise.com/.../microsoft-accuse-tricher-performances-navigateur-internet-explorer-9,9573.htmlQuant aux "mesures fiables des performances des navigateurs", je ne doute pas de vos compétences en la matière, pourtant la page de test que Microsoft a mis en ligne est assez risible, car seul Internet Explorer obtiendra la meilleurs note. Les navigateurs Chrome ou Firefox, habituellement mieux notés, obtiennent ici des notes inférieures. Là où c'est risible, c'est qu'en utilisant Firefox, et en changeant seulement le user-agent, pour se faire passer pour Internet Explorer 9, on obtient la meilleure note, ce qui veut dire que le "test" mis en ligne, n'analyse aucune performance du navigateur, mais lit simplement le nom et la version du navigateur.