Tengo un bullCollections donde guardo información sobre algunos mensajes de ejemplo.
try { let bullPayload = { type: 'message', payload: { messsages: messagesForPreProcessingData, sessionID: this.data['sessionID'], socketID: parseInt(this.data['socketID']), }, await bullConnections[accumulatorQueue].add(bullPayload, { removeOnComplete: true, }); };El código funciona bien, pero me pidieron que cambiara la lógica aquí, según algunas estadísticas, los mensajes tardan demasiado en mostrarse a algunos usuarios (debido a una mala conexión wifi) y se me ocurrió una solución que el front-end calculará el tiempo tomado del servidor al cliente y si eso tomó más de 400 ms, se enviará una nueva solicitud para que el backend sepa que los mensajes tardaron mucho en cargarse.
Hice un tiempo de espera como este
saveBullPayloadWithTimeout(key, timeDuration, bullPayLoad, messages, events) { let redis = this.data.dbRedisConfigur.dataRedis; return new Promise((resolve, reject) => { setTimeout(() => { redisConnections[redis].get(key, (err, result) => { if (err) { reject(err); } else { if (result) { redisConnections[redis].del(key, (err, result) => { if (result == 1) { } else { logErrors({ message: 'CANNOT DELETE KEY' }); } }); } else { bullConnections[accumulator].add(bullPayLoad, { removeOnComplete: true, }); console.log('AFTER'); this.updateCurrentMessages(messages, events); } } }); }, timeDuration); }); }Por lo tanto, este fragmento de código debe esperar 5 segundos para que pueda saber si insertar el mensaje o no. Durante estos 5 segundos, el backend espera una segunda solicitud, si se ha realizado una segunda solicitud, guarda los datos en Redis y después de 5 segundos verificará esos datos si existen, luego no guardará el mensaje, de lo contrario lo guardará.
¿El tiempo de espera afecta el rendimiento, porque el backend manejará millones de usuarios?
¿Hay alguna forma mejor de separar esto como un proceso en segundo plano?
¿El tiempo de espera afecta el rendimiento, porque el backend manejará millones de usuarios?
Los tiempos de espera, en sí mismos, probablemente no afectarán mucho el rendimiento. Pero su uso específico de ellos lo hará, porque todo lo que hace es retrasar el proceso por timeDuration y luego ejecutarlo en el hilo principal , y no tiene nada allí (hasta donde puedo decir) para cancelar uno anterior si se hace una solicitud posterior que la reemplaza.
¿Hay alguna forma mejor de separar esto como un proceso en segundo plano?
setTimeout no funciona como un proceso en segundo plano. Ni siquiera lo hace en un subproceso de fondo. Se realiza en el mismo hilo principal que programó el temporizador. El uso setTimeout solo retrasa el inicio del trabajo, no hace que el trabajo suceda en un hilo diferente.
Si desea que algo se haga en un proceso diferente, deberá generar un proceso secundario .
Si desea que se haga algo en un subproceso diferente, deberá generar un subproceso de trabajo .