Bienvenido, me llamo Miguel y para hoy les traigo un post.
Supongamos que necesita guardar 10000 libros en un servicio de libros. La API del servicio solo nos permite guardar 100 libros por solicitud. Mi primera idea sería dividir todo en trozos de 100 libros y disparar todo en paralelo.
La desventaja es que creará un pico en la carga del servicio de libros. Por lo general, significa que el servicio tendrá dificultades para procesar tal pico o estará sobreaprovisionado para manejar cargas como esa.
El sobreaprovisionamiento generalmente significa pagar por la potencia informática que no se usa la mayor parte del tiempo.
Así que queremos aplanar un poco el pico. Para hacer eso usaremos lo que se llama ejecución paralela limitada. Básicamente, enviaremos lotes de libros en paralelo, pero no más de 10 a la vez.
Probablemente ya sepa que este código tiene un problema. En cada iteración, tenemos que esperar a que se complete la operación más lenta.
Resolvamos eso también con un grupo de promesas. Un grupo de promesas le permite limitar el número máximo de funciones que se ejecutan en paralelo esperando a que se establezcan las promesas.
Voy a usar el paquete @supercharge/promise-pool, pero hay muchas alternativas.
Sin embargo, debe agregar un manejo de errores adecuado.
Como puede ver, ya no esperamos a que se complete la función más lenta e iniciamos una nueva ejecución tan pronto como una finaliza la ejecución.
En este ejemplo particular, el tiempo total de ejecución fue reducido en un tercio.
Por supuesto, no hay límite para la perfección. ¿Qué pasa si el servicio de libros tiene un límite de tarifa? ¿Y si hay más de un productor?
El siguiente paso sería configurar una cola como RabbitMQ, Apache Kafka o Amazon SQS. Pero ese es otro tema.
Espero que hayas aprendido algo nuevo y gracias por leer.
Añadir comentario