Melhorar o desempenho da nossa tecnologia em benefício dos nossos clientes e das suas audiências é um curso contínuo na Verizon Media, agora Edgio. Por exemplo, nos últimos dois anos, nossos engenheiros de desempenho e kernel eliminaram praticamente todas as quedas de pacotes (mais de 98% removidos), melhoraram as verificações de integridade de desempenho em nossos servidores de borda em 50% e aumentaram a capacidade do servidor em até 40%.
Também juntámos o acima com automação de rede e expansão de rede orgânica – atualmente mais de 250 Tbps – para melhorar a experiência do utilizador. Ajustar cuidadosamente o nosso desempenho tem desempenhado um papel importante na nossa capacidade de suportar picos de rede em rápida mudança e, por vezes, imprevisíveis à medida que entregamos atualizações de software para milhões de consolas de jogos, transmissões de vídeo ao vivo para grandes eventos desportivos e quando os equilibradores de carga multi-CDN movem a carga para a nossa rede.
Manter a qualidade em escala envolve otimizar o desempenho em todas as partes da pilha tecnológica da Edgio Media Platform: Desde as suas camadas inferiores, na CPU e na placa de rede, até ao sistema operativo e às aplicações. Em última análise, o nosso objetivo é sempre o mesmo: Excelente desempenho. Para lá chegar, realizamos análises baseadas em dados, baseando-nos em mudanças mensuráveis de desempenho para validar a nossa tomada de decisões.
Otimizações de cache da CPU
Nós executamos 20 000 servidores em todo o mundo, em grande parte os chipsets Broadwell e Haswell, tipicamente com 32 a 40 núcleos. Adicionamos 12 000 servidores apenas nos últimos três anos. No entanto, a maioria dos servidores não está otimizada para expandir as nossas cargas de trabalho. Simplesmente adicionar mais servidores não cria uma operação mais eficiente e pode criar desafios adicionais. A escala eficaz requer uma otimização cuidadosa dos componentes existentes. Ser capaz de otimizar um servidor para que ele seja capaz de processar duas ou três vezes (ou mais) solicitações do que com a configuração padrão pode fazer uma diferença poderosa no desempenho geral da rede.
A mudança do snoop precoce para o snoop doméstico
As CPUs modernas empregam um protocolo snoop para garantir que o cache local da CPU seja consistente com a memória. Isto permite que os caches ouçam modificações a variáveis em qualquer CPU e atualizem as suas versões destas variáveis de acordo com as mesmas. Não surpreendentemente, a técnica específica usada pode ter um impactos significativo no desempenho da memória.
Por padrão, nossos fornecedores de hardware usam um protocolo chamado Early Snoop. Tem uma latência mais baixa para resolver a coerência do cache, já que todos os núcleos podem fazer solicitações de coerência do cache simultaneamente e enviar transmissões. Descobrimos que os nossos sistemas geram grandes quantidades de atividade simultânea de disco e placa de rede durante cenários de pico de carga. Estas atividades resultam em emissões de snoop elevadas, levando a estrangulamentos na comunicação. Isto faz com que o dispositivo de E/S abrande e pode eventualmente levar a que o processamento pare completamente.
Ao mudar para o modo Home Snoop, uma abordagem que faz coalescos pedidos de snoop, vimos uma redução significativa no tráfego de transmissão. O QPI (Quick Path Interconnect) do processador já não está faminto durante períodos de operações simultâneas de E/S em disco pesado e rede; além disso, as quedas de pacotes que vimos com o Snoop precoce reduziram significativamente em número.
Alterar o protocolo snoop depende simplesmente de alterar uma configuração do BIOS. No entanto, reiniciar 20 000 servidores sem interromper os clientes requer automação. Podemos fazer com que este tipo de mudança de implementação em larga escala funcione na produção, em parte graças à nossa plataforma de AUTOMAÇÃO DE TI baseada no StackStorm, o Crayfish.
Um evento inesperado de falha
Ao testar a mudança para o Home Snoop, ocorreu um failover: Um dos nossos maiores clientes de mídia, que tem uma implantação de vários CDN , experimentou um problema com outro fornecedor e moveu uma parte significativa do seu tráfego para a nossa CDN. Isso proporcionou uma oportunidade para testar as melhorias em larga escala do Home Snoop, que foram extremamente impactantes.
A figura acima mostra o efeito da mudança. O grupo que ainda usava o Snoop teve um aumento de quedas de 13,75x (55K pacotes de gotas por servidor por dia), enquanto o grupo que tinha mudado para o Home Snoop viu um aumento de apenas 4,23x (27K pacotes de gotas por máquina por dia). Home Snoop provou imediatamente o seu valor durante o evento de ativação pós-falha.
Otimização da interface de rede e afinações do condutor
Outro conjunto importante de ajustes de desempenho envolveu a interface de rede e o driver. Aqui, concentrámo-nos em reduzir as gotas de pacotes que normalmente ocorrem com o tráfego em sequência. Durante grandes eventos, o tráfego de entrada era tão pesado que a placa de rede não conseguia manter-se, e vimos quedas de pacotes mais cedo do que o esperado. À medida que descobrimos o porquê, encontramos vários parâmetros na própria placa de rede que precisavam de ajustar, incluindo o número de filas, o tamanho da fila e o agendamento de interrupções. Para otimizar estas especificações para a nossa carga de trabalho e configuração de hardware em particular, concentramo-nos em ajustar o Receive Side Scaling (RSS), tornando as filas de entrada mais longas, reduzindo o seu número geral e equilibrando as interrupções nos nós DE UMA.
O gráfico acima mostra um teste que fizemos na América do Norte, no qual cada pop é dividido em um grupo de controle (ou seja, untuned) e um grupo de teste (ou seja, tuned). Aqui, apresentamos o número de gotas somadas diariamente durante uma semana. Após as afinações, o nosso grupo de testes viu cerca de 95% menos quedas de pacotes do que o grupo de controlo, permitindo o processamento de pedidos significativamente mais. Isto também significa que é necessária menos ação para gerir manualmente a saúde da rede durante os surtos, deixando os nossos engenheiros livres para se concentrarem noutras áreas.
Sintonizações de programação da CPU
Enquanto a afinação do nível de controlador e da placa de rede concentraram-se em melhorar a capacidade total que podemos fornecer, as afinações de programação da CPU concentraram-se em melhorar a forma como podemos fornecer conteúdo de forma consistente.
Sem estas afinações, as mensagens recebidas e enviadas têm de competir por recursos. Quando começamos a investigar a causa raiz, descobrimos que a contenção sobre os recursos resultou de como o kernel estava programando o tratamento dessas mensagens. Isso significava que a carga não foi migrada durante o pico de tráfego até que as CPUs em questão estivessem saturadas. Para corrigir isso, definimos a afinidade da CPU dos nossos processos de servidor web para excluir CPUs dedicadas ao processamento do tráfego de entrada da rede.
Os gráficos acima mostram o impactos de permitir as afinações de programação da CPU globalmente na CDN de 21 a 22 de março. Avaliamos o impactos com base no percentil 95 e nos valores medianos de uma métrica de verificação de integridade de desempenho, uma métrica composta que demonstra o tempo de resposta relativo de um servidor. Como esperado, os vales de baixo tráfego não foram significativamente reduzidos; no entanto, os picos revelam uma redução significativa da contenção entre o tráfego de entrada e de saída. Isto traduz-se numa grande melhoria tanto nos outliers como nos medianos, particularmente durante as cargas de pico. Agora podemos lidar melhor com picos de tráfego e problemas relacionados com alto comportamento de outlier, como rebuffers em fluxos de vídeo ou a capacidade de resposta geral de um servidor para todos os utilizadores.
Actualizações de desempenho do kernel
Otimizar as camadas superiores da nossa pilha tecnológica é igualmente tão importante como ajustar os elementos da camada inferior. No processo de atualizar recentemente o nosso sistema operativo, também atualizámos os nossos kernels Linux para tirar partido do trabalho de engenharia a montante da comunidade do kernel Linux. O novo kernel teve cerca de quatro anos de desenvolvimento além da versão anterior implementada, incluindo melhorias no sistema de gestão de memória, que reduz as alocações de páginas de bloqueio e melhora a distribuição e o desempenho da carga ao usar a API epoll e o armazenamento de socket.
No gráfico acima, você pode ver o efeito do processo de atualização do final de novembro para o início de janeiro como um declínio nas verificações de integridade de desempenho do percentil 99. As melhorias subjacentes ao kernel levaram a uma distribuição de carga mais uniforme em todos os nossos processadores de solicitação de servidor web. Isto resultou numa queda substancial nestes valores, tornando os pedidos para todos os nossos clientes mais fiáveis.
Afinações de desempenho têm um efeito significativo
Nos últimos dois anos, as afinações de longo alcance do sistema que o desempenho e a engenharia do kernel implantaram eliminaram praticamente todas as quedas de pacotes (mais de 98% removidos) e reduziu para metade as nossas verificações de desempenho nos nossos servidores de borda. A nossa capacidade de servidores aumentou de 10 a 40% (a quantidade exata varia de acordo com o perfil do cliente e o evento), permitindo-nos entregar mais tráfego mais rapidamente. O comportamento mais avançado melhorou significativamente, tornando-se uma experiência mais consistente, e temos visto uma boa melhoria nas medianas, particularmente durante o pico de carga. Em resumo, o ajuste de desempenho para toda a pilha de tecnologia nos permitiu lidar melhor com quaisquer picos de tráfego inesperados (seja de uma atualização de consola de jogos muito antecipada ou de um popular evento de streaming de vídeo ao vivo) e oferecer um desempenho mais consistente para todos os nossos utilizadores.
