Optimización de claimUserTickets: Mejora de rendimiento y refactorización #273
Conversation
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||
| ticketIds, | ||
| }, | ||
| }); | ||
| const [events, tickets] = await Promise.all([ |
There was a problem hiding this comment.
Se paralelizaron las consultas de eventos y tickets usando Promise.all.
| userId: USER.id, | ||
| logger, | ||
| }), | ||
| trx.query.ticketsSchema.findMany({ |
There was a problem hiding this comment.
Se eliminó el bucle for que iteraba sobre cada ticket. Ahora procesamos los tickets en lote, lo que reduce el número de consultas a la base de datos y mejora el rendimiento.
| .execute(); | ||
|
|
||
| // Bulk query for existing ticket counts | ||
| const finalTicketsCount = await trx |
There was a problem hiding this comment.
Reemplazamos múltiples consultas individuales por una única consulta en lote para obtener el recuento de tickets. Esto reduce la carga en la base de datos y mejora el tiempo de respuesta.
| // If the ticket template has a quantity field, means there's a | ||
| // limit to the amount of tickets that can be created. So we check | ||
| // if we have enough tickets to fulfill the purchase order. | ||
| if (ticketTemplate.quantity) { |
There was a problem hiding this comment.
Se eliminó este check inicial ya que estamos haciendo un check final en el recuento de los userTickets existentes.
Esto mejora el rendimiento para el caso de uso más común de éxito en el que no se rebasa la cantidad máxima de stock
| userTicketsSchema.ticketTemplateId, | ||
| ticketTemplates.map((t) => t.id), | ||
| ), | ||
| inArray(userTicketsSchema.approvalStatus, [ |
There was a problem hiding this comment.
Aquí me basé en el código anterior en el que se tomaban en cuenta solo estos dos estados, approved y pending, pero tal vez deberíamos tambien tomar en cuenta a:
- Gifted
- Gifted accepted
- Not required
¿Que piensan?
Este PR optimiza la función
claimUserTicket, mejorando su rendimiento y simplificando su lógica.Los cambios principales incluyen:
Eliminación de verificaciones redundantes:
Paralelización de operaciones:
Optimización de consultas a la base de datos:
Detalle pruebas de rendimiento
Se realizaron 15 iteraciones de los tests encontrados en src/schema/userTickets/tests/claimUserTicket
Se hizo un análisis del rendimiento de los tests y estos fueron los resultados.
Versión main (actual en producción):
Nueva versión (textcode/improve-purchase-order-performance):
Mejora de rendimiento: 1.02%
Resumen de pruebas de rendimiento
La nueva versión muestra una mejora ligera pero consistente en el rendimiento.
Aunque la diferencia es pequeña en los tests actuales, es importante notar que:
Promise.ally la reducción de consultas a la base de datos, deberían proporcionar beneficios más significativos en entornos de producción con mayor carga.Cambios en los tests: