Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

111
Vistas
Personalizado para... de usar la cola para resolver la concurrencia en las promesas genera solicitudes más lentas que Promise.all

aquí está mi problema: tengo una pila de x promesas que quiero resolver 5 a la vez (básicamente lo que hace Plimit )

Aquí está el código que implementé usando para... de

 async queuefy(items, concurrency, callback) { console.log(items.length); let queue = []; let singleQueue = []; let now = 0; items.forEach((item, index) => { now++; singleQueue.push(item); if(now === concurrency || index === items.length - 1) { queue.push(singleQueue); now = 1; singleQueue = []; } }); let batch = 0; let ret = []; for(const que of queue) { const currentRes = await Promise.all(que.map(async (q) => { return await callback(q); })); console.log("Resolved batch: ", ++batch); ret.push(...currentRes); } ret = ret.filter(ret => ret !== undefined); return ret; }

Además, al tener una lógica más difícil de resolver, el tiempo aumenta al usar el viejo Promise.all. Solo probado para hasta 15 instancias de "queuefy".

¿Hay algún problema con mi código o el número de tiempo de solicitud se reducirá al usar Promise.all para obtener ejemplos más grandes?

about 4 years ago · Juan Pablo Isaza
1 Respuestas
Responde la pregunta

0

No debería sorprender demasiado que, si elige entre solicitar 15 elementos simultáneamente y solicitar un máximo de 5 solicitudes a la vez, la implementación limitada/en cola lleva más tiempo. Lo que se había hecho en paralelo ahora se está haciendo semi-serie. Presumiblemente, el uso de la limitación o el comportamiento en serie aquí no es para ahorrar absolutamente tiempo de reloj de pared, sino para igualar la carga del servidor o permitir que el navegador o la red prioricen otras conexiones dentro de su propio límite.

Sin embargo, hay un aspecto de su código que quizás no esperaba: su Promise.all . Todos los lotes de 5 ahora tardarán tanto como la solicitud más larga antes de que comience el siguiente lote. En consecuencia, justo antes de que comience un nuevo lote, es probable que haya menos de 5 solicitudes abiertas actualmente.

 (A1-------) (B1-----------)(C1--) | (A2---------) (B2--) (C2-------------------)| (A3---) (B3-------) (C3------) | done (A4--------------------)(B4----) (C4----------) | (A5-----) (B5---------) (C5----) | TIME->--------------------------------------------------------|

En otras implementaciones como PLimit y la mía en SO , no hay llamadas intermedias a Promise.all , por lo que puede completar esas llamadas de manera más óptima y al mismo tiempo asegurarse de que no existan más de 5 promesas abiertas a la vez.

 ( 1-------)( 8-----------)(14--) | ( 2---------)( 9--)(11-------------------) | ( 3---)( 6-------)(10------) | done ( 4--------------------)(13----) | ( 5-----)( 7---------)(12----)(15----------)| TIME->--------------------------------------|

Por esta razón, es posible que desee abandonar el uso de Promise.all para mantener mejor saturados sus canales/hilos abiertos.

about 4 years ago · Juan Pablo Isaza Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda