Mejorar el rendimiento de nuestra tecnología para el beneficio de nuestros clientes y sus audiencias es un curso de acción continuo en Verizon Media, ahora Edgio. Por ejemplo, en los últimos dos años, nuestros ingenieros de rendimiento y kernel han eliminado prácticamente todas las caídas de paquetes (más del 98% eliminadas), mejorado las comprobaciones de estado del rendimiento en nuestros servidores perimetrales en un 50% y aumentado la capacidad del servidor en hasta un 40%.
También hemos combinado lo anterior con la automatización de la red y la expansión orgánica de la red, actualmente más de 250 Tbps, para mejorar la experiencia del usuario. Ajustar cuidadosamente nuestro rendimiento ha jugado un papel importante en nuestra capacidad de soportar aumentos de red rápidamente cambiantes y a veces impredecibles, ya que entregamos actualizaciones de software para millones de consolas de juegos, transmisiones de video en vivo para eventos deportivos importantes y cuando los balanceadores de carga de CDN múltiples mueven la carga a nuestra red.
Mantener la calidad a escala implica optimizar el rendimiento en cada parte de la pila tecnológica de Edgio Media Platform: Desde sus capas inferiores, en la CPU y NIC, hasta el SO y las aplicaciones. En definitiva, nuestro objetivo es siempre el mismo: Un gran rendimiento. Para llegar allí, realizamos análisis basados en datos, confiando en cambios de rendimiento medibles para validar nuestra toma de decisiones.
Optimizaciones de caché de CPU
Operamos 20.000 servidores en todo el mundo, en su mayoría chipsets Broadwell y Haswell, típicamente con 32 a 40 núcleos. Hemos añadido 12.000 servidores solo en los últimos tres años. Sin embargo, la mayoría de los servidores no están optimizados para escalar para nuestras cargas de trabajo fuera de la caja. Simplemente agregar más servidores no hace que el funcionamiento sea más eficiente y puede crear desafíos adicionales. El escalado efectivo requiere una cuidadosa optimización de los componentes existentes. Ser capaz de optimizar un servidor para que sea capaz de procesar dos o tres veces (o más) solicitudes que con la configuración predeterminada puede marcar una gran diferencia en el rendimiento general de la red.
El cambio de snoop temprano a snoop en casa
Las CPU modernas emplean un protocolo snoop para garantizar que la caché de la CPU local sea consistente con la memoria. Esto permite que los cachés escuchen las modificaciones de las variables en cualquier CPU y actualicen sus versiones de estas variables en consecuencia. No es sorprendente que la técnica particular utilizada pueda afectar significativamente el rendimiento de la memoria.
Por defecto, nuestros proveedores de hardware utilizan un protocolo llamado Early Snoop. Tiene una latencia más baja para resolver la coherencia de la caché, ya que todos los núcleos pueden hacer solicitudes de coherencia de la caché simultáneamente y enviar transmisiones. Hemos encontrado que nuestros sistemas generan grandes cantidades de actividad simultánea de disco y NIC durante escenarios de carga máxima. Estas actividades dan lugar a transmisiones de alto espionaje, lo que conduce a cuellos de botella en la comunicación. Esto hace que el dispositivo IO se ralentice y eventualmente puede provocar que el procesamiento se detenga por completo.
Al cambiar al modo Home Snoop, un enfoque que combina las solicitudes de snoop, hemos visto una reducción significativa en el tráfico de difusión. La interconexión de ruta rápida (QPI) del procesador ya no está hambrienta durante los períodos de operaciones simultáneas de disco pesado y de E/S de red; además, las caídas de paquetes que vimos con Snoop temprana se redujeron significativamente en número.
Cambiar el protocolo snoop depende simplemente de cambiar una configuración de BIOS. Sin embargo, reiniciar los servidores 20.000 sin interrumpir a los clientes requiere automatización. Podemos hacer que este tipo de cambio de despliegue a gran escala funcione en producción, en parte gracias a nuestra plataforma de automatización DE TI basada en StackStorm, Cangrejo de río.
Un evento de failover inesperado
Durante la prueba del cambio a Home Snoop, se produjo una conmutación por error: Uno de nuestros clientes de medios más grandes, que tiene una implementación de varias CDN, experimentó un problema con otro proveedor y movió una parte significativa de su tráfico a nuestra CDN. Esto proporcionó una oportunidad para probar las mejoras a gran escala de Home Snoop, que fueron extremadamente impactantes.
La figura anterior muestra el efecto del cambio. El grupo que todavía usaba Snoop temprano vio un aumento en las caídas en 13.75x (55K caídas de paquetes por servidor por día), mientras que el grupo que había cambiado a Home Snoop vio un aumento de solo 4.23x (27K caídas de paquetes por máquina por día). Home Snoop demostró inmediatamente su valor durante el evento de failover.
Optimización de la interfaz de red y ajustes de controladores
Otro conjunto de ajustes de rendimiento importantes involucró la interfaz de red y el controlador. Aquí, nos enfocamos en reducir las caídas de paquetes que generalmente ocurren con el tráfico de ráfagas. Durante eventos grandes, el tráfico entrante era tan pesado que NIC no podía mantenerse al día, y vimos caídas de paquetes antes de lo esperado. A medida que profundizamos en el porqué, encontramos que era necesario ajustar varios parámetros en la propia NIC, incluyendo el número de colas, el tamaño de la cola y la programación de interrupciones. Para optimizar estas especificaciones para nuestra configuración particular de carga de trabajo y hardware, nos concentramos en ajustar el Escalado del lado de recepción (RSS) haciendo las colas de entrada más largas, reduciendo su número total y equilibrando las interrupciones en los nodos NUMA.
El gráfico anterior muestra una prueba que realizamos en Norteamérica, en la que cada pop se divide en un grupo de control (es decir, sin afinar) y un grupo de prueba (es decir, sintonizado). Aquí, presentamos el número de gotas sumadas diariamente durante una semana. Después de las afinaciones, nuestro grupo de prueba vio aproximadamente un 95% menos de caídas de paquetes que el grupo de control, lo que permitió procesar significativamente más solicitudes. Esto también significa que se requiere menos acción para administrar manualmente el estado de la red durante las sobretensiones, dejando a nuestros ingenieros libres para enfocarse en otras áreas.
Sintonizaciones de programación de CPU
Mientras que el ajuste a nivel de NIC y driver se concentró en mejorar la capacidad total que podemos ofrecer, los ajustes de programación de CPU se centraron en mejorar la coherencia con la que podemos entregar contenido.
Sin estas afinaciones, los mensajes entrantes y salientes tienen que competir por los recursos. Cuando comenzamos a investigar la causa raíz, encontramos que la contención sobre los recursos era el resultado de cómo el núcleo estaba programando el manejo de estos mensajes. Esto significaba que la carga no se migró durante el pico de tráfico hasta después de que las CPU en cuestión se saturaron. Para solucionar esto, establecemos la afinidad de la CPU de nuestros procesos de servidor web para excluir las CPU dedicadas a procesar el tráfico de red entrante.
Los gráficos anteriores muestran el impacto de habilitar las afinaciones de programación de la CPU a nivel mundial en toda la CDN del 21 al 22 de marzo. Evaluamos el impacto en función del percentil 95 y los valores medianos de una métrica de comprobación de estado del rendimiento, una métrica compuesta que demuestra el tiempo de respuesta relativo de un servidor. Como se esperaba, los valles de bajo tráfico no se redujeron significativamente; sin embargo, los picos revelan una contención significativamente reducida entre el tráfico entrante y saliente. Esto se traduce en una mejora importante tanto en los valores atípicos como en las medianas, particularmente durante las cargas máximas. Ahora podemos manejar mejor los aumentos en el tráfico y solucionar los problemas relacionados con el comportamiento atípico alto, como los rebuffers en los flujos de vídeo o la capacidad de respuesta general de un servidor para todos los usuarios.
Actualizaciones de rendimiento del kernel
Optimizar las capas superiores de nuestra pila tecnológica es igual de importante que ajustar los elementos de la capa inferior. En el proceso de actualización reciente de nuestro sistema operativo, también actualizamos nuestros kernels Linux para aprovechar el trabajo de ingeniería ascendente de la comunidad del kernel Linux. El nuevo kernel tuvo alrededor de cuatro años de desarrollo más allá de la versión anterior implementada, incluyendo mejoras en el sistema de gestión de memoria, lo que reduce el bloqueo de asignaciones de páginas y mejora la distribución de carga y el rendimiento cuando se utiliza la API epoll y el sharding de socket.
En el gráfico anterior, puede ver el efecto del proceso de actualización desde finales de noviembre hasta principios de enero como una disminución en las comprobaciones de estado del rendimiento del percentil 99. Las mejoras subyacentes del kernel llevaron a una distribución de carga más uniforme en todos nuestros procesadores de solicitudes de servidor web. Esto dio lugar a una caída sustancial en estos valores atípicos, lo que hace que las solicitudes para todos nuestros clientes sean más confiables.
Las afinaciones de rendimiento tienen un efecto significativo
En los últimos dos años, los ajustes de sistema de gran alcance que el rendimiento y la ingeniería del kernel han implementado han eliminado prácticamente todas las caídas de paquetes (más del 98% eliminadas) y han reducido a la mitad nuestras comprobaciones de estado del rendimiento en nuestros servidores perimetrales. Nuestra capacidad de servidor ha aumentado en un 10-40% (la cantidad exacta varía según el perfil del cliente y el evento), lo que nos permite entregar más tráfico más rápido. El comportamiento atípico ha mejorado significativamente, lo que hace que la experiencia sea más consistente, y hemos visto una buena mejora en las medianas, particularmente durante la carga máxima. En resumen, el ajuste de rendimiento de toda la pila tecnológica nos ha permitido manejar mejor cualquier aumento de tráfico inesperado (ya sea de una actualización de consola de juegos muy esperada o de un evento popular de transmisión de video en vivo) y ofrecer un rendimiento más consistente para todos nuestros usuarios.
