Internet Explorer Performance Lab: medindo confiavelmente o desempenho do navegador

Uma das funções principais deste blog é ir aos bastidores para mostrar todo o trabalho que envolve a engenharia do Windows 8. Nesta postagem, damos uma olhada em algo com o que nos preocupamos muito, como engenheiros e como usuários finais: o desempenho da Web no mundo real. Fazemos um grande esforço para ir além do básico das anedotas e impressões enquanto trabalhamos para estabelecer um alto desempenho na navegação da Web. Esta postagem é criada por Matt Kotsenas, Jatinder Mann e Jason Weber da equipe do IE, embora o desempenho seja algo em que cada membro da equipe esteja trabalhando. --Steven

O desempenho da Web é importante para qualquer pessoa e um objetivo da engenharia do Internet Explorer é ser o navegador mais rápido do mundo. Para atingir esse objetivo, precisamos medir confiavelmente o desempenho do navegador em cenários do mundo real importantes para os nossos clientes. Nos últimos cinco anos, projetamos e construímos o Internet Explorer Performance Lab, um dos sistemas de medição de desempenho da Web mais sofisticados do mundo.

O IE Performance Lab coleta dados confiáveis, precisos e acionáveis para dar suporte a decisões durante o ciclo de desenvolvimento. Medimos o desempenho do Internet Explorer 200 vezes por dia, coletando mais de 5,7 milhões de medições e 480 GB de dados de tempo de execução todo dia. Entendemos o impacto de cada alteração no produto e garantimos que o Internet Explorer ficará ainda mais rápido. Esta postagem do blog examina detalhadamente a forma em que o IE Performance Lab é projetado e como usamos o laboratório para garantir que estamos continuamente tornando a Web mais rápida.

Nesta postagem, apresentamos:

• a visão geral do IE Performance Lab
• a infraestrutura do laboratório
• o que (e como) medimos
• teste de um cenário
• investigação dos resultados
• teste de softwares de terceiros
• criação de um navegador rápido para os usuários

Visão geral do IE Performance Lab

Um sistema precisa ser capaz de simular de forma reprodutiva os cenários de usuário do mundo real para medir confiavelmente o desempenho da Web ao longo do tempo. Essencialmente, o nosso sistema precisa criar uma “miniversão da Internet”.

O IE Performance Lab é uma rede privada completamente isolada da Internet pública e da rede intranet da Microsoft, e contém mais de 140 máquinas. O laboratório contém as peças principais da Internet real, incluindo servidores Web, servidores DNS, roteadores e emuladores de rede, o que simula cenários diferentes de conectividade de cliente.

Embora isso pareça ser complexo à primeira vista, essa abordagem permite que todas as fontes de variância sejam removidas. Controlando cada aspecto da rede, até os saltos e latências de pacote individual, nossos testes se tornam determinísticos e repetitivos, o que é crítico para tornar os resultados acionáveis. No IE Performance Lab, a atividade é medida com resolução de 100 nanossegundos.

Esse tipo de configuração de rede também fornece uma ótima flexibilidade. Como estamos simulando uma configuração do mundo real, nosso laboratório pode acomodar basicamente qualquer tipo de máquina de teste ou conteúdo de site da Web. O IE Performance Lab dá suporte a desktops, laptops, netbooks e tablets com processadores x86, x64 e ARM, todos simultaneamente. Semelhantemente, como o laboratório usa as Windows Performance Tools (WPT), podemos executar os mesmos testes usando navegadores da Web diferentes, barras de ferramentas, produtos antivírus ou outro software de terceiros e comparar diretamente os resultados.

As WPT se aprofundam no hardware subjacente. Usando as WPT, podemos capturar tudo, desde a atividade de alto nível de CPU e GPU, a informações de baixo nível, como eficiência de cache, estatísticas de rede, padrões de uso de memória, e muito mais. As WPT nos permitem medir e otimizar o desempenho na pilha para garantir que o hardware, os drivers de dispositivo, o sistema operacional Windows e o Internet Explorer estejam todos otimizados eficientemente juntos.

Uma única execução de teste leva 6 horas para ser concluída e gera mais de 22 GB de dados durante esse tempo. Esse sistema altamente automatizado é gerido por uma pequena equipe que monitora as operações, analisa os resultados e desenvolve novos recursos de infraestrutura.

Infraestrutura do laboratório

A infraestrutura do Performance Lab pode ser dividida em três categorias principais: Rede e servidor, clientes de teste e análise e relatório. Cada categoria é criada para minimizar a interação entre componentes, aprimorar a escalabilidade de teste e reduzir a possibilidade de introduzir ruído no ambiente de laboratório.

Aqui está uma visualização do IE Performance Lab, incluindo inúmeras máquinas de teste e de análise em nossa rede privada.

Infraestrutura da rede e do servidor

Vamos começar discutindo os servidores DNS, os emuladores de rede e os servidores de conteúdo; todos os componentes que juntos criam uma mini-internet. Nas próximas três seções, analisaremos o diagrama de arquitetura da direita para a esquerda.

Servidores de conteúdo

Os servidores de conteúdo são servidores Web que servem como milhões de hosts da Web na Internet. Cada servidor de conteúdo hospeda páginas da Web do mundo real que foram capturadas localmente. As páginas capturadas passam por um processo que chamamos de sanitarização, onde pegamos partes de conteúdo da Web para garantir um determinismo reproduzível. Por exemplo, as chamadas das funções Date do JavaScript ou Math.Random() serão substituídas por um valor estático. Além disso, as URLs dinâmicas criadas por estruturas de publicidade são bloqueadas para a URL que foi usada primeiro pela estrutura.

Depois da sanitarização, o conteúdo é servido semelhantemente para conteúdo estático através de um filtro ISAPI que mapeia um hash da URL para o conteúdo, permitindo pesquisa instantânea. Cada servidor Web é uma máquina de 16 núcleos com 16 GB de RAM para minimizar a variabilidade e garantir que o conteúdo esteja na memória (não é necessário o acesso ao disco).

Os servidores de conteúdo também hospedam aplicativos Web dinâmicos como o Outlook Web Access ou o Office Web Apps. Nesses casos, o servidor de aplicativos e quaisquer dependências de multicamada são hospedados em servidores dedicados no laboratório, assim como em ambientes do mundo real.

Emuladores de rede

Já que muitas fontes de variabilidade foram removidas, as velocidades da rede não refletem mais as experiências de muitos usuários com conexões mais lentas. Para simular ambientes de cliente no mundo real, um teste pode tirar vantagem da emulação da rede para compreender o desempenho na ampla gama de redes usadas hoje em dia. O laboratório dá suporte à emulação de várias configurações DSL, modems de cabo, modems 56k, assim como alta largura de banda, ambientes de alta latência como ambientes WAN e 4G. Conforme as solicitações HTTP são passadas para o emulador, ele simula as características da rede, tais como o atraso de pacote e a reordenação e, em seguida, encaminha a solicitação para os hosts da Web. Ao receber uma resposta, a emulação é aplicada novamente e, em seguida, passada de volta para o cliente de teste.

Usar hardware dedicado para a emulação da rede proporciona o ambiente de teste mais realístico possível e reduz significativamente o efeito de observador. Embora ter hardware dedicado adicione custo e complexidade comparados às soluções baseadas em proxy ou em software, essa é a única forma de medir com precisão o desempenho. Os navegadores limitam o número de conexões proxy simultâneas para evitar a saturação do proxy, portanto, usar um proxy para a emulação da rede tem o efeito inesperado de colocar de lado a fragmentação de domínio e outras otimizações feitas pela página da Web. Além disso, a emulação de rede local competirá com o navegador por recursos da máquina local, especialmente em máquinas de baixo consumo de energia.

Servidores DNS

Como servidores DNS do mundo real, os servidores DNS do laboratório vinculam os servidores de conteúdo com os clientes de teste. O laboratório usa um servidor DNS diferente para cada emulador de rede, o que significa que mudar de uma velocidade de rede para outra é tão simples como mudar de servidor DNS. Nesses casos, em vez de resolver os nomes de domínio para os hosts da Web, o servidor DNS resolve todos os nomes de domínio para o emulador de rede associado.

Configurações de cliente de teste

Desejamos garantir que o Internet Explorer seja consistentemente executado com rapidez em todas as classes de hardware de computador. O laboratório contém mais de 120 computadores usados para medir o desempenho do Internet Explorer. Chamamos isso de clientes de teste; eles variam de desktops de alto desempenho de x64 a netbooks de baixo consumo de energia, assim como dispositivos tablet sensíveis ao toque, e tudo que esteja no meio. Como a repetitividade das medições é fundamental, todos os clientes de teste são máquinas físicas.

Pool de máquinas de comparação de alteração do Internet Explorer Performance Lab

Classes diferentes de máquinas contêm plataformas gráficas discretas e integradas para garantir que o Internet Explorer continue a tirar vantagem total da aceleração de hardware no ecossistema de dispositivos. Acima está nosso principal pool de máquinas. Esses PCs se aproximam com a experiência do consumidor médio em todo o tempo de vida de um PC com Windows 7 ou Windows 8. As máquinas são ordenadas com base no OEM para que sejam idênticas; todas elas são do mesmo fabricante e suas características de desempenho são verificadas antes do uso.

Já que o laboratório funciona 24 horas por dia/7 dias por semana, as falhas de hardware são inevitáveis. Substituir os componentes defeituosos por peças idênticas de um fabricante diferente quase sempre faz com que o computador reparado seja executado mais rapidamente do que outras máquinas do pool. Embora essa diferença não seja notada no mundo real, quando você está medindo em menos de 100 nanossegundos, mesmo alguns ciclos podem impactar os resultados! Se depois de um reparo uma máquina não for mais executada da mesma forma que o resto do pool, ela é removida do laboratório e o tamanho do pool diminui permanentemente. Em resposta, as compras do laboratório incluem máquinas de “buffer” extras, de forma que quando uma máquina defeituosa é removida do pool, a capacidade excessiva oferece um amortecimento, e as operações do laboratório não são afetadas.

Nome do pool	Número de máquinas	Fator forma	Processador	Arco	Velocidade do relógio	RAM	Placa gráfica
Pool principal	32	Desktop	Núcleo i5 750 (Lynnfield)	64 bits	2,66 GHz	4096 MB DDR3	NVIDIA GeForce 310

Para acrescentar amplitude de hardware, temos pools de máquinas adicionais que executam o espectro de cenários do consumidor. O bom desempenho dessas máquinas garante que o IE use o hardware subjacente de forma eficiente no ecossistema do PC.

Nome do pool	Número de máquinas	Fator forma	Processador	Arco	Velocidade do relógio	RAM	Placa gráfica
Alto desempenho 1	20	Desktop	Núcleo i7 870	64 bits	2,93 GHz	4096 MB DDR3	ATI Radeon HD 4550
Alto desempenho 2	4	Desktop	Xeon 5150 (Woodcrest)	64 bits	2,66 GHz	8192 MB DDR2	ATI Radeon X1950 Pro
Desempenho intermediário 1	6	Desktop	Núcleo 2 Duo (Wolfdale)	64 bits	3 GHz	4096 MB DDR2	Intel GMA 4500
Desempenho intermediário 2	15	Desktop	Núcleo 2 Duo E6750	64 bits	2,66 GHz	4096 MB DDR2	ATI Radeon HD 2400 XT
Desempenho intermediário 3	25	Desktop	Núcleo i5 2500	64 bits	3,30 GHz	4096 MB DDR3	Placa gráfica Intel HD 2000
Desempenho intermediário 4	6	Desktop	Núcleo 2 Duo (Conroe)	64 bits	2,66 GHz	4096 MB DDR2	ATI Radeon HD 2400XT
Desempenho intermediário 5	4	Desktop	Núcleo 2 Duo (Conroe)	64 bits	2,4 GHz	4096 MB DDR2	ATI Radeon X1950 Pro
Baixo consumo de energia 1	2	Laptop	Atom Z530	32 bits	1,6 GHz	2038 MB DDR2	Intel GMA 500
Baixo consumo de energia 2	4	Netbook	Atom N270	32 bits	1,6 GHz	1024 MB DDR2	NVIDIA ION
Baixo consumo de energia 3	2	Netbook	Atom N450	64 bits	2,66 GHz	1024 MB DDR2	Intel GMA 3150
Baixo consumo de energia 4	4	Netbook	Atom N270	32 bits	1,6 GHz	1024 MB DDR2	Intel GMA950
Baixo consumo de energia 5	4	Slate	ARM	32 bits	—	—	—
Hardware protótipo	—	—	—	—	—	—	—

Máquinas de teste de baixo consumo de energia. Cada uma está em um estado de teste diferente.

Se for necessária ainda mais diversidade, o IE Performance Lab também pode usar o Windows Graphics Lab. O Windows Graphics Lab armazena aproximadamente cada chipset de placa gráfica fabricado. Os PCs podem ser configurados praticamente em qualquer permutação imaginável e, sem seguida, usados para teste de desempenho. O Windows Graphics Lab é inestimável para diagnosticar problemas de placa gráfica entre chipsets e revisões de driver.

Servidores de análise e de relatório

A coleta e a análise dos resultados de teste são divididas em duas etapas separadas. Descarregando a análise em máquinas dedicadas, os clientes de teste podem começar outra execução de desempenho mais cedo. E máquinas de classe de servidor mais poderosas podem ser usadas para realizar a análise mais rapidamente. Quanto mais cedo a análise é concluída, mais eficientemente podemos identificar alterações de desempenho.

Usamos 11 máquinas de classe de servidor para a análise, cada uma possui 16 núcleos e 16 GB de RAM. Durante a análise, cada arquivo de rastreamento é inspecionado e milhares de métricas são extraídas e inseridas em um servidor SQL. Durante 24 horas, essas máquinas de análise inspecionarão mais de 15.000 rastreamentos que serão usados para análise de tendência.

São mostrados dois de vários racks de servidor que contêm servidores de arquivos, um servidor SQL e vários servidores de análise e de conteúdo.

O Servidor SQL usado para armazenar as aproximadamente 6 milhões de medições que coletamos todo dia é uma máquina de núcleo lógico 24 com 64 GB de RAM. Os relatórios podem ser gerados diretamente do SQL, ou os resultados podem ser inspecionados por meio de um aplicativo de comparação baseado em HTML ou o serviço WCF que fornece resultados em formatos XML ou JSON.

O que (e como) medimos

Com a infraestrutura estabelecida, vamos revisar os tipos diferentes de cenários medidos no laboratório de desempenho e as ferramentas que usamos para obter as métricas.

Cenários medidos diariamente

O laboratório de desempenho focaliza cenários do mundo real que importam para os usuários. Consequentemente, executamos mais de 20.000 testes diferentes diariamente. Esses testes se encaixam em quatro categorias, às vezes, sobrepostas:

Carregamento de conteúdo – Navegar de uma página para outra ainda é a atividade mais comum dentro de um navegador da Web. Carregar conteúdo da Web é a única categoria que toca em mais de onze subsistemas do navegador. Carregar conteúdo da Web é um pré-requisito para as outras categorias de cenários.

Aplicativos Web interativos – Esta categoria cobre o que às vezes se chama de criação de conteúdo, aplicativos AJAX ou sites da Web 2.0. Isso inclui interagir com notícias populares e sites de rede social, assim como interagir com aplicativos de correio e de documentos, como o Outlook Web Access e o Office Web Apps.

IE, “o aplicativo” – Importantes mas frequentemente esquecidos são cenários que interagem com o próprio navegador. Interações comuns incluem a abertura ou o fechamento do navegador, interações de guias, uso de recursos do navegador como Histórico e Favoritos, e movimento panorâmico e zoom com o teclado e o mouse, e entradas de toque.

Níveis de referência sintéticos – Raramente esquecidos mas frequentemente superestimados são os níveis de referência sintéticos como o WebKit SunSpider. Os níveis de referência podem ser uma ferramenta de engenharia útil, já que são criados para enfatizar subsistemas de navegador e acentuar diferenças entre navegadores. Entretanto, para maximizar essas diferenças, os níveis de referência frequentemente recorrem a padrões de uso atípicos ou casos extremos.

Padrões do mundo real

Ao medir o desempenho, é importante garantir que os testes reflitam padrões de uso do mundo real. A maioria dos livros de texto sobre engenharia de software se refere a esse processo como modelagem de carga de trabalho , ou modelagem de uso de aplicativo. Para garantir a medição de padrões do mundo real, o laboratório de desempenho usa páginas da Web que representam padrões do mundo real e usam subsistemas de navegador diferentes.

Para determinar quais sites são usados para teste, rastreamos regularmente milhões de sites e compilamos uma lista de atributos de site e padrões de codificação. Usamos 68 pontos de dados diferentes para determinar associações entre sites – coisas como a profundidade e a largura dos padrões de layout DOM, CSS resultantes, estruturas comuns usadas, recursos internacionais, e muito mais. Com base nos resultados, escolhemos os sites que melhor representam os padrões comuns e a diversidade da Web mais ampla.

Métricas de engenharia

O desempenho é um problema multidimensional. A única forma de obter uma visão apurada do desempenho é entender o cenário que você está testando, e como o hardware e o sistema operacional interagem com o navegador. Aqui está uma observação mais próxima das cinco métricas de desempenho mais importantes no contexto de carregamento de um grande site de esportes pela primeira vez.

Tempo de Exibição - O Tempo de Exibição mede o tempo entre a execução de uma ação pelo usuário até que ele veja o resultado dessa ação na tela.

Tempo Decorrido - A maioria dos sites continua a realizar trabalho de segundo plano depois que o conteúdo é exibido na tela. Os exemplos devem incluir baixar o próximo email em um aplicativo de correio da Web ou enviar análises de volta para um provedor. Da perspectiva do usuário, o site deve parecer finalizado; entretanto, frequentemente ocorre um trabalho significativo que pode causar impacto na capacidade de resposta geral.

Tempo de CPU - Os navegadores da Web modernos são quase sempre limitados exclusivamente pela velocidade da CPU. Descarregar dados para a GPU e tornar a CPU mais eficiente causa um grande impacto no desempenho.

Utilização do Recurso - Criar um navegador rápido significa garantir que os recursos funcionem bem juntos em todo o PC, incluindo utilização da rede, padrões de uso da memória, processamento da GPU, placa gráfica, memória e centenas de outras dimensões. Já que os usuários executam vários aplicativos ao mesmo tempo em seus PCs, é importante que os navegadores compartilhem esses recursos responsavelmente com outros aplicativos.

Consumo de Energia - Aumentar a eficiência do consumo de energia resulta na duração mais longa da bateria em cenários móveis, custos de energia mais baixos para o dispositivo e um impacto ambiental menor.

Concentrar-se unicamente em uma única métrica cria uma visão muito simplista do desempenho. Focalizando apenas uma métrica, as pessoas tendem a otimizar apenas essa métrica, frequentemente menosprezando métricas igualmente importantes. A única forma de combater essa tendência é medir todos os aspectos do desempenho e, em seguida, fazer as trocas conscientemente, em vez de implicitamente.

No total, o laboratório de desempenho mede mais de 850 métricas diferentes. Cada uma mostra parte da imagem do desempenho do navegador. Para dar uma ideia do que medimos, aqui está uma lista de métricas (não exaustivas): conjunto de trabalhos privados, conjunto de trabalhos totais, contagem de solicitações HTTP, bytes TCP recebidos, número de binários carregados, número de alternâncias de contexto, uso de memória de vídeo DWM, utilização percentual da GPU, número de pinturas, tempo da CPU na coleta de lixo JavaScript, tempo da CPU na análise de JavaScript, intervalo médio de atualização de DWM, conjunto de trabalhos totais de pico, número de alocações de heap, tamanho das alocações de heap, número de alocações de heap pendentes, tamanho das alocações de heap pendentes, tempo da CPU no subsistema de layout, tempo da CPU na formatação do subsistema, tempo da CPU na renderização do subsistema, tempo da CPU no subsistema do analisador HTML, tempo inativo da CPU, número de threads.

Infraestrutura de rastreamento de eventos do Windows

As métricas são coletadas por meio da Windows Event Tracing Infrastructure (ETW) e VMMap. A ETW é o sistema de log de eventos do Windows usado por muitos componentes do Windows e aplicativos de terceiros, incluindo o Log de Eventos do Windows. As APIs de log da ETW são de nível extremamente baixo e de baixa sobrecarga, o que é crítico para o teste de desempenho.

O visualizador de rastreamento incluído na WPT, xperfview.exe, é um visualizador poderoso que permite correlação e kernel subjacente, CPU, GPU, E/S, rede e outros eventos. A WPT também dá suporte à pilha em andamento. A pilha em andamento faz um instantâneo da pilha de chamadas do programa em intervalos regulares e salva a pilha como parte do rastreamento. Correlacionando os eventos da ETW com as pilhas, a WPT exibirá não apenas o trabalho que estava sendo feito, mas a pilha de chamadas associadas com esse trabalho e o total de tempo decorrido para fazer esse trabalho, com resolução de 10 microssegundos. A pilha em andamento pode ser habilitada em qualquer processo, mesmo um que não use eventos da ETW. O problema da pilha em andamento é que ela requer símbolos de depuração para decodificar as pilhas, e é suscetível a nome alternativo.

Teste de um cenário

A peça final do quebra-cabeças é o processo de teste real. O teste pode ser dividido em 3 fases: instalação, teste e erros e limpeza. Aqui está um fluxograma do processo inteiro para ser seguido.

Instalação

O processo começa quando um usuário solicita uma execução através do site da Web do laboratório ou da estrutura de automação. A execução é colocada em uma fila de prioridades com outras execuções pendentes. Quando um cliente de teste fica disponível, ele verifica a fila e começa o trabalho de maior prioridade possível. Primeiro, o cliente de teste instala o sistema operacional de teste especificado. O IE Performance Lab dá suporte a teste no Vista, Windows 7 e Windows 8. O cliente de teste instala uma nova cópia do sistema operacional de teste para cada execução, de forma que a máquina sempre começa em um bom estado conhecido.

Quando o sistema operacional de teste é instalado, o cliente configura a WPT, o VMMap e o agente de teste. A execução também especifica inúmeras configurações do IE, tais como homepage, uso de Sites Sugeridos, Navegação InPrivate, e outros. Qualquer software de terceiros também é instalado e configurado nesse ponto.

A etapa final antes do teste é garantir que o cliente de teste esteja inativo para minimizar a interferência do teste. O Windows define um conceito de tarefas inativas. Tarefas inativas são uma forma de o Windows e outros desenvolvedores programarem trabalhos que não sejam fundamentais para ocorrerem em um momento posterior, quando o usuário não estiver competindo por recursos. As tarefas inativas do sistema operacional incluem pré-busca ou SuperFetching, desfragmentação de disco, atualização de índices de pesquisa, e outros, dependendo da versão do sistema operacional e dos serviços configurados. Para garantir que nenhum trabalho inativo seja feito durante os testes, a fila de tarefas inativas é liberada. Além disso, o Windows Defender é pausado e o local do log do agente de teste é marcado como excluído do Serviço de Indexação do Windows para evitar que os arquivos de log e de rastreamento façam com que o indexador seja iniciado durante uma execução de teste. O teste é feito em várias passagens para minimizar o número de provedores necessários, já que provedores adicionais aumentam o efeito de observador. A primeira passagem é sempre uma passagem de aquecimento. O aquecimento garante que os binários do navegador estejam “quentes” e que o valor máximo do conteúdo da página armazenada em cache esteja disponível no cache do WinINET. As passagens subsequentes focalizam um tipo específico de instrumentação, como a pilha em andamento, rastreamento de memória, E/S e rastreamento de registro.

Erros e limpeza

Se em qualquer momento durante o teste o navegador falhar, a passagem de teste é considerada falha e a execução vai para a próxima passagem de teste. Se em qualquer momento durante os testes o Windows falhar, o computador reinicializa e o sistema operacional é reinstalado, já que seu estado não pode ser garantido. Se o número de tentativas exceder o limite, a execução inteira é considerada falha e a máquina passa para outra execução para evitar a tentativa infinita de testar uma compilação instável.

Quando todos os casos de teste estiverem concluídos, o cliente de teste carrega os logs e os rastreamentos para análise. O cliente de teste, em seguida, retorna para um estado inativo e começa a sondagem para uma nova execução.

Investigação dos resultados

Cada métrica é rastreada a cada alteração. Executamos cada caso de teste um mínimo de dez vezes e duplicamos as execuções em pelo menos duas máquinas diferentes para criar a mesma população. Usando ferramentas de estatística, resultados não característicos podem ser sinalizados automaticamente para investigação. Uma alteração de variância também é considerada uma regressão. Os usuários interagem com o IE sob várias circunstâncias e em uma ampla gama de hardwares, e um dos nossos objetivos é garantir uma experiência tranquila e previsível a cada vez.

Além da análise automatizada, uma equipe de triagem investiga os resultados diários para observar as tendências e outros comportamentos interessantes. A investigação manual não pode ser eliminada porque muitas ferramentas estatísticas presumem uma distribuição normal e que todas as amostras sejam independentes. Nenhuma presunção pode ser estritamente verdadeira para nossas medidas. Algumas atividades no IE são conduzidas por um temporizador do sistema operacional, o que significa que os resultados também dependem de quando (durante o ciclo do temporizador) o carregamento da página começa. Um carregamento de página que comece antes ou depois da interrupção de um temporizador poderá trabalhar em maior ou menor intensidade porque o IE deverá tratar da interrupção em pontos diferentes no processo de carregamento da página. Essa interrupção também pode ter um efeito de ondulação que causa uma distribuição bimodal. Além disso, como usamos tentativas repetidas (não desligamos a máquina entre as iterações), a próxima tentativa é influenciada pelas tentativas anteriores. Aqui está uma amostra do gráfico Tempo Decorrido do Bing Mapas para comparação a cada alteração.

A série vermelha mostra o valor médio de cada execução de teste e as barras cinzas mostram o intervalo. Passar o mouse sobre uma execução de teste mostrará as iterações da métrica (em azul) assim como uma dica de ferramenta que fornece os valores exatos para valores mínimos, médios e máximos, assim como a diferença absoluta e relativa em relação à execução de teste anterior. A dica de ferramenta mostrada nesta imagem também fornece contexto adicional, tal como a compilação que está sendo testada e um link rápido para nosso sistema de controle de origem para exibir as alterações na compilação.

A combinação de análise automatizada e investigação manual fornece à equipe do IE dados confiáveis e acionáveis para o ajuste do desempenho.

Teste do software de terceiros

Muitos aplicativos de terceiros dependem do Trident, da pilha da rede e de outros componentes do IE. Extensões como BHOs e as barras de ferramentas são carregadas no contexto do IE. Outros aplicativos, como o software de segurança, podem se injetar entre os componentes do IE. Esses aplicativos se tornam parte da pilha do IE e podem causar um desempenho ruim. O laboratório de desempenho é capaz de medir o impacto do software de terceiros na navegação de conteúdo do mundo real em um ambiente controlado. Esses estudos são importantes para o IE e para o ecossistema porque os usuários geralmente não podem quantificar o impacto do software popular em sua experiência de navegação.

Ao testar o impacto do software de terceiros, comparamos uma execução com software de terceiros instalado, com uma execução limpa somente com o IE instalado, para determinar o impacto do software. Em particular, estamos interessados em medir duas métricas: tempo de inicialização e tempo de navegação. O tempo de inicialização mede o tempo que leva para iniciar o navegador e navegar para uma URL, enquanto o tempo de navegação mede o tempo que leva para navegar para uma URL quando o navegador já tiver sido iniciado. A inicialização também inclui o tempo que aplicativos de terceiros levam para carregar suas extensões do IE.

Usar conteúdo armazenado em cache permite a repetição em nossas medidas. Além disso, medindo um site armazenado em cache, podemos definitivamente saber que uma regressão de desempenho é causada por software de terceiros e não por diferenças no site. Ao medir o impacto dos softwares de terceiros, também validamos nossas descobertas, testando a inicialização e a navegação em uma conexão direta com a Internet, para verificar se o ambiente de teste não é responsável por quaisquer deltas.

Muitos aplicativos de terceiros descarregam o trabalho durante uma navegação de página para serviços de nuvem. Embora a paralelização do trabalho e o uso de serviços de nuvem sejam técnicas excelentes para aprimorar o desempenho, alguns aplicativos esperam em sincronia pelos resultados da rede, bloqueando a navegação no processo. Existem vários cenários do mundo real, como firewalls estritos, conexões WAN e cenários offline, onde tais padrões podem causar um desempenho ruim para os usuários. O software de terceiros nunca deve processar em sincronia como resposta a uma ação do IE ou do usuário, e devem fazer atualizações em lote da interface do usuário e do DOM para minimizar a interrupção.

Criação de um navegador rápido para os usuários

O desempenho do navegador no mundo real é importante. Medir o desempenho em escala é um investimento significativo e um trabalho de tempo integral, mas os resultados valem muito o esforço. Os dados coletados pelo Internet Explorer Performance Lab são instrumentais em nosso entendimento do desempenho do navegador e do hardware subjacente do PC, e no desenvolvimento de uma experiência da Web rápida, fluida e responsiva para os usuários.

—Matt Kotsenas, Jatinder Mann e Jason Weber da equipe de desempenho do Internet Explorer

Comments

• Anonymous
  May 09, 2012
  Boa Materia.