Una historia sobre cómo resolver el problema de rendimiento de Moment.js

Moment.js es una de las bibliotecas JavaScript más populares para analizar y formatear fechas. WhereTo usa Node.js, por lo que para ellos, usar esta biblioteca fue un movimiento completamente natural. No se esperaban problemas con el uso del servidor de Moment.js. Al final, desde el principio, utilizaron esta biblioteca en la interfaz para mostrar fechas y quedaron satisfechos con su trabajo. Sin embargo, el hecho de que la biblioteca funcionó bien en el cliente no significaba que tampoco habría problemas con el servidor.



El material, cuya traducción publicamos hoy, está dedicado a la historia de resolver el problema de rendimiento Moment.js.

Crecimiento del proyecto y disminución de la productividad.

Recientemente, el número de registros de vuelos devueltos por el sistema WhereTo ha crecido unas diez veces. Luego nos enfrentamos a una fuerte caída en el rendimiento. Resultó que el ciclo de renderizado, que tomó menos de 100 milisegundos, ahora toma más de 3 segundos para mostrar aproximadamente 5,000 resultados de búsqueda. Nuestro equipo ha comenzado la investigación. Después de varias sesiones de creación de perfiles, notamos que más del 99% de este tiempo se gasta en una sola función llamada createInZone .


La función createInZone tarda unos 3,3 segundos en completarse.

Continuando con nuestra investigación de la situación, encontramos que esta función es llamada por la función parseZone de parseZone . ¿Por qué es tan lenta? Teníamos la sensación de que la biblioteca Moment.js estaba diseñada para escenarios de uso comunes y, como resultado, intentará procesar la cadena de entrada de varias maneras. Tal vez deberías limitarlo? Después de leer la documentación, descubrimos que la función parseZone acepta un argumento opcional que especifica el formato de fecha:

 moment.parseZone(input, [format]) 

Lo primero que hicimos fue intentar usar la función parseZone con pasarle información sobre el formato de fecha, pero esto, como lo mostraron las pruebas de rendimiento, no condujo a nada:

 $ node bench.js moment#parseZone x 22,999 ops/sec ±7.57% (68 runs sampled) moment#parseZone (with format) x 30,010 ops/sec ±8.09% (77 runs sampled) 

Aunque ahora la función parseZone funcionó un poco más rápido, para nuestras necesidades esta velocidad claramente no era suficiente.

Optimización específica del proyecto.

Utilizamos Moment.js para analizar las fechas recuperadas de la API de nuestro proveedor (Travelport). Nos dimos cuenta de que siempre devuelve datos en el mismo formato:

 "2019-12-03T14:05:00.000-07:00" 

Sabiendo esto, comenzamos a comprender la estructura interna de Moment.js para (como esperábamos) escribir una función mucho más eficiente que produzca los mismos resultados.

Creando una alternativa más rápida a parseZone

Para comenzar, necesitábamos descubrir cómo se ven los objetos Moment.js. Fue bastante fácil de entender:

 > const m = moment() > console.log(m) Moment {  _isAMomentObject: true,  _i: '2019-12-03T14:05:00.000-07:00',  _f: 'YYYY-MM-DDTHH:mm:ss.SSSSZ',  _tzm: -420,  _isUTC: true,  _pf: { ...snip },  _locale: [object Locale],  _d: 2019-12-03T14:05:00.000Z,  _isValid: true,  _offset: -420 } 

El siguiente paso fue crear una instancia de Moment sin usar un constructor:

 export function parseTravelportTimestamp(input: string) {  const m = {}  // $FlowIgnore  m.__proto__ = moment.prototype  return m } 

Ahora parecía que teníamos muchas propiedades de la instancia de Moment que podríamos configurar (no entramos en detalles sobre cómo nos enteramos de esto, pero si observa el código fuente de Moment.js lo entenderá):

 const FAKE = moment() const TRAVELPORT_FORMAT = 'YYYY-MM-DDTHH:mm:ss.SSSSZ' export function parseTravelportTimestamp(input: string) {  const m = {}  // $FlowIgnore  m.__proto__ = moment.prototype  const offset = 0 // TODO  const date = new Date(input.slice(0, 23))  m._isAMomentObject = true  m._i = input  m._f = TRAVELPORT_FORMAT  m._tzm = offset  m._isUTC = true  m._locale = FAKE._locale  m._d = date  m._isValid = true  m._offset = offset  return m } 

El último paso de nuestro trabajo fue descubrir cómo analizar el valor de offset de la marca de tiempo. Resultó que esta es siempre la misma posición en la línea. Como resultado, pudimos optimizar esto:

 function parseTravelportDateOffset(input: string) {  const hrs = +input.slice(23, 26)  const mins = +input.slice(27, 29)  return hrs * 60 + (hrs < 0 ? -mins : mins) } 

Esto es lo que sucedió después de ponerlo todo junto:

 const FAKE = moment() const TRAVELPORT_FORMAT = 'YYYY-MM-DDTHH:mm:ss.SSSSZ' function parseTravelportDateOffset(input: string) {  const hrs = +input.slice(23, 26)  const mins = +input.slice(27, 29)  return hrs * 60 + (hrs < 0 ? -mins : mins) } /** *     ISO-8601,    : * - "2019-12-03T12:30:00.000-07:00" */ export function parseTravelportTimestamp(input: string): moment {  const m = {}  // $FlowIgnore  m.__proto__ = moment.prototype  const offset = parseTravelportDateOffset(input)  const date = new Date(input.slice(0, 23))  m._isAMomentObject = true  m._i = input  m._f = TRAVELPORT_FORMAT  m._tzm = offset  m._isUTC = true  m._locale = FAKE._locale  m._d = date  m._isValid = true  m._offset = offset  return m } 

Pruebas de rendimiento

Probamos el rendimiento de la solución resultante utilizando el módulo de referencia npm. Aquí está el código de referencia:

 const FAKE = moment() const TRAVELPORT_FORMAT = 'YYYY-MM-DDTHH:mm:ss.SSSSZ' function parseTravelportDateOffset(input: string) {  const hrs = +input.slice(23, 26)  const mins = +input.slice(27, 29)  return hrs * 60 + (hrs < 0 ? -mins : mins) } /** *     ISO-8601,    : * - "2019-12-03T12:30:00.000-07:00" */ export function parseTravelportTimestamp(input: string): moment {  const m = {}  // $FlowIgnore  m.__proto__ = moment.prototype  const offset = parseTravelportDateOffset(input)  const date = new Date(input.slice(0, 23))  m._isAMomentObject = true  m._i = input  m._f = TRAVELPORT_FORMAT  m._tzm = offset  m._isUTC = true  m._locale = FAKE._locale  m._d = date  m._isValid = true  m._offset = offset  return m } 

Aquí están los resultados de nuestra investigación de desempeño:

 $ node fastMoment.bench.js moment#parseZone x 21,063 ops/sec ±7.62% (73 runs sampled) moment#parseZone (with format) x 24,620 ops/sec ±6.11% (71 runs sampled) fast#parseTravelportTimestamp x 1,357,870 ops/sec ±5.24% (79 runs sampled) Fastest is fast#parseTravelportTimestamp 

Al final resultó que, logramos acelerar el análisis de las marcas de tiempo en aproximadamente 64 veces. Pero, ¿cómo afectó esto al funcionamiento real del sistema? Esto es lo que sucedió como resultado de la creación de perfiles.


El tiempo total de ejecución de parseTravelportTimestamp es inferior a 40 ms.

Los resultados fueron simplemente sorprendentes: comenzamos con 3,3 segundos, entrando en fechas de análisis y llegamos a menos de 40 milisegundos.

Resumen

Cuando comenzamos a trabajar en nuestra plataforma, tuvimos que resolver una cantidad terrible de problemas. Solo sabíamos que nos estábamos repitiendo a nosotros mismos: "Deje que funcione primero, pero luego puede hacer la optimización".

En los últimos años, la complejidad de nuestro proyecto ha crecido enormemente. Afortunadamente, ahora hemos llegado al lugar donde podemos pasar a la segunda parte de nuestro "mantra": la optimización.

Las soluciones de biblioteca ayudaron al proyecto a llegar a donde está hoy. Pero nos enfrentamos con un problema de "biblioteca". Al resolverlo, aprendimos que al crear nuestro propio mecanismo centrado en nuestras necesidades, podemos hacer que el código sea "más fácil" en términos de consumo de recursos del sistema y ahorrar tiempo valioso para nuestros usuarios.

Estimados lectores! ¿Ha encontrado problemas similares a los que se analizan en este artículo?