El autor del material, cuya traducción publicamos hoy, dice que él, a mediados de septiembre de 2019, finalmente completó el proyecto en el que ha estado trabajando durante un año. El objetivo de este proyecto era reducir el tamaño del manifiesto requerido para inicializar la canalización asíncrona de JavaScript de Wikipedia. Es decir, el tamaño del manifiesto era 36 Kb. Tenía que caber en menos de 28 Kb, que corresponde a dos fragmentos de 14 kilobytes de la secuencia de paquetes de Internet.
El resultado de este proyecto fue un ahorro diario de 4.3 terabytes de tráfico.
Al principio, el tamaño del manifiesto superó los 36 Kb, y después de la optimización, su tamaño se hizo más pequeño que 28 Kb.El gráfico muestra una disminución gradual en el tamaño del manifiesto. Estamos hablando de datos comprimidos (es decir, es la carga neta en la red, lo que crea la transferencia de estos datos desde el servidor al navegador).
Proceso de optimización
El manifiesto de inicialización está representado por datos que no son fáciles de optimizar. La mayor parte de su código no es algo así como la lógica funcional que se puede optimizar por medios tradicionales. En cambio, casi todo el manifiesto está representado por datos puros. Estos datos son generados automáticamente por el sistema de entrega de contenido
ResourceLoader . Son un registro de paquetes de módulos. Wikipedia utiliza el sistema ResourceLoader para trabajar con JavaScript, CSS y recursos de texto.
El registro incluye metadatos para todas las funcionalidades front-end implementadas en Wikipedia. El manifiesto enumera los nombres de los paquetes, sus versiones actuales, sus dependencias de otros paquetes similares se describen aquí.
Comencé buscando código que nunca se usó en la práctica (
T202154 ). Esto incluyó encontrar piezas de código incompletas u olvidadas relacionadas con características heredadas. El código no utilizado se eliminó de inmediato para garantizar la compatibilidad con los navegadores que ya no pasaron nuestra prueba, lo que aseguró su inclusión en el grupo de navegadores modernos (
Grado A ). También preparé un
documento sobre el rendimiento de carga de la página. Este documento sirvió como referencia, permitiendo a los desarrolladores comprender el impacto de los cambios de varios tipos en las diversas etapas del proceso de carga de la página.
Reduce la cantidad de módulos
El siguiente paso fue colaborar con los equipos de ingeniería de la Fundación Wikimedia y Wikimedia Deutschland. Necesitábamos descubrir qué características del sistema usan una cantidad excesiva de módulos. Por ejemplo, habiendo entendido esto, sería posible combinar paquetes previamente dispersos a partir de los cuales se construyó una cierta funcionalidad. Dichos paquetes, incluso en un estado disperso, siempre se cargan juntos. Esto llevaría al hecho de que habría menos puntos finales en el sistema cuyos metadatos deberían almacenarse en el registro formado por ResourceLoader.
Aquí hay algunos puntos interesantes sobre la aplicación de este enfoque de optimización:
- La extensión WikiEditor ahora tiene 11 módulos menos que antes. Se eliminaron otros 31 módulos de UploadWizard.
- Al optimizar el programa ContentTranslation, se combinaron 24 módulos.
- El proyecto MobileFrontend combina 25 módulos.
- 20 módulos eliminados de RevisionSlider y TwoColConflict.
También es muy importante que el cliente de Wikidata para Wikipedia haya sido optimizado. Esta parte del trabajo en sí fue un proyecto épico (
T203696 ). Inicialmente, 248 módulos individuales fueron responsables de implementar esta característica. Después de que pudimos deshacernos de más de 200 módulos, solo había 42 de ellos.
El diagrama anterior muestra las pequeñas mejoras que se hicieron al proyecto durante el año. Todos ellos nos acercaron a la meta. Especialmente me gustaría notar dos grandes caídas en el tamaño del manifiesto. Una de esas caídas ocurrió en la primera semana de agosto. Fue entonces cuando se implementó una versión mejorada de Wikidata. La segunda caída en el tamaño se puede observar al final del gráfico. Sucedió a mediados de septiembre. Ahora me gustaría contarte sobre él.
Reduce los tamaños de metadatos
La mejora en el manifiesto que ocurrió a mediados de septiembre fue posible gracias a dos cambios globales que apuntaban a una organización de datos más inteligente.
La primera mejora es que, anteriormente, los metadatos del esquema de extensión
EventLogging formaban parte del manifiesto principal. Este mecanismo se refactorizó, por lo que los metadatos del esquema ahora se incluyeron en el paquete JS del cliente EventLogging. Como resultado, la contribución al tamaño del manifiesto realizada anteriormente por EventLogging se ha reducido en más del 90%. ¡Esto significa que la ruta crítica ahora contiene 2 KB menos de datos! Esto, además, significaba que expandir las capacidades de EventLogging ya no conducía a un aumento en el tamaño del manifiesto. Al ensamblar dichos paquetes
, se utilizó una nueva característica de ResourceLoader,
Package Files . Esta característica se introdujo en febrero de 2019, uno de los motivos de interés es el hecho de que podría ayudar a reducir la cantidad de módulos en el registro. Package Files simplifica enormemente el proceso de combinar datos generados y código JavaScript en un solo módulo.
La segunda mejora ocurrió cuando redujimos el tamaño promedio de cada entrada de registro (
T229245 ). El manifiesto contiene dos entradas para cada módulo. Este es el nombre del módulo y el identificador (ID) de su versión. El identificador de versión necesitaba previamente 7 bytes de datos. Después de pensar en
la paradoja del cumpleaños en el contexto de ResourceLoader, decidimos que el espectro de probabilidad para las ID de versión podría reducirse de forma segura de 78 mil millones a "solo" 60 millones. Los detalles sobre esto se pueden encontrar en los
comentarios del código. Pero, para resumir esta mejora, podemos decir que esto nos permitió guardar 2 bytes en la descripción de cada uno de los 1,100 módulos que todavía están en el registro. Como resultado, el tamaño del manifiesto se redujo en otros 2-3 Kb.
A continuación se muestra un fragmento ampliado del diagrama que muestra los últimos días de funcionamiento (estos indicadores se toman del sistema de monitoreo sintético, aquí se utilizan datos sin comprimir).
Cambio de tamaño manifiesto en la etapa final de un proyectoEl cambio fue capturado por el sistema de monitoreo ResourceLoader. La captura de pantalla muestra el panel de
tamaño del manifiesto de inicio ubicado en una instancia pública de Grafana. Aquí puede ver que el tamaño del flujo de datos sin comprimir disminuyó en 2,8 Kb.
El despliegue del sistema, que tuvo lugar a mediados de septiembre, condujo al logro del objetivo original, que era comprimir el manifiesto a un tamaño que no superara los 28 Kb. La implementación de este proyecto a gran escala llevó al hecho de que el manifiesto de inicialización se redujo en 9 Kb (estamos hablando de datos comprimidos). Hace un año, este tamaño era de 36.2 Kb, y después de la finalización del proyecto ya era de 27.2 Kb.
Alrededor de 363,000 visitas a la página se generan cada minuto en Wikipedia y proyectos relacionados. En una hora: 21 millones y 800 mil. Diariamente: 523 millones (
aquí están las estadísticas sobre las visitas a la página). Esa versión del sistema, que se implementó a mediados de septiembre, generó un ahorro de aproximadamente 1,4 terabytes de tráfico por día. Y si compara lo que es hoy con lo que era hace un año, resulta que 4.3 terabytes de tráfico ahora se guardan diariamente.
Que sigue
Logramos ajustar el manifiesto de inicialización de Wikipedia de 28 Kb. Este es el tamaño que se eligió debido al hecho de que es el tamaño más pequeño que es un múltiplo de 14 Kb. Los datos de este tamaño se pueden colocar en fragmentos de la
secuencia de paquetes
de Internet transmitidos al navegador.
Ahora nos enfrentamos a una nueva tarea: no renunciar a los puestos. En el último año, he estado observando de cerca el
manifiesto . Hice esto para asegurarme de nuestros éxitos y descubrir posibles problemas que nos están retrasando. Al final, automaticé este proceso usando el
tablero público de
Grafana .
Si cree en este panel, todavía tenemos muchas oportunidades para mejorar el empaque del código y para resolver problemas que son aún más fuertes que ahora, facilitar la creación de paquetes. Espero que estas próximas mejoras nos sean útiles, pero por ahora estamos trabajando en nuevas características del sistema, mientras nos esforzamos por cumplir con los requisitos para el nivel de rendimiento del proyecto.
Estimados lectores! ¿Alguna vez ha participado en la optimización de grandes proyectos de Internet?
