Se me reporto el siguiente problema: "La planilla da error de TimeOut y traba todo Evolution. Es necesario cerrar el navegador y volver a entrar para seguir trabajando. Al consultar el estado de generación de planilla dice 'Finalizada'". Al revisar los log del GenPla, verifique que en efecto el proceso finaliza sin problemas pero Evolution queda colgado hasta que cierra el navegador y vuelven a entrar. No hay registro de error en ningún lado salvo el que se presenta en Evolution (TimeOut) |
Al revisar todos los procedimientos GenPla, note que el genpla_inicializacion tardaba demasiado por dos procedimientos específicos: genpla_horas_extra_reevalua y genpla_genera_recargos. Ambos realizan una consulta bien pesada a varias tablas para determinar los horarios diarios para cada uno de los empleados en cada día de la quincena o catorcena, según sea el caso ya que la mayoría tienen jornadas no administrativas. De tal forma que los cálculos salariales se realizan según la jornada diaria así como los recargos y horas extra. Realice una creación de índices a ciertas tablas lo cual mejoró el rendimiento de los proceso y logre bajar la ejecución del genpla_inicializacion a 3 segundos y la planilla se generó exitosamente. Sin embargo, al día siguiente, generaron planilla y volvió a dar el mismo problema. Corrí el genpla_inicializacion desde la base de datos y tardó 4.5 minutos. Recompilé el procedimiento de recargos y ejecute nuevamente desde SQLServer y bajo otra vez a 3 segundos. Luego desde Evolution, corrio maravillosamente. Por la tarde generaron planilla y volvió a tronar. Comente con algunos compañeros y Julio Flores me dijo que se le presentó algo similar debido al "Parameter Sniffing" que en pocas palabras, es una especie de técnica de optimización que tiene SQLServer para prevenir que los procesos truenen. Este proceso evalúa la cantidad de datos que se procesan en un procedimiento la primera vez luego de ser compilado y asume que esa es la media de datos procesados siempre. Cuando los datos procesados son pocos, funciona pero en mi caso, se procesaban mas de 10,000 registros lo cual lo volvía lentísimo. La solución es no usar los parámetros como variables dentro del script del procedimiento, sino mas bien almacenarlas dentro de otras variables y procesar el resto del script con estas variables de "segundo nivel". Algo asi: Ademas de realizar un buen analisis de indexación de datos considero que también esta es una buena práctica sobre aquellos procesos que manejan gran cantidad de datos. El rendimiento de la planilla se mejoró en un 84% ALTER proc [sv].[genpla_genera_ingresos_retroactivos] @sessionId varchar(36) = null, @codppl int, @userName varchar(100) = null as --Variables de segundo nivel declare @sessionId1 varchar(36), @codppl1 int , @userName1 varchar(100)
Les dejo el link que habla sobre Parameter Sniffing: https://blogs.technet.microsoft.com/mdegre/2011/11/06/what-is-parameter-sniffing/ Interesante. Muchas gracias por compartir |
Adicional a la respuesta a esta pregunta, también se sugiere actualizar al menos al hotfix 1.9.2.2, ya que se implementó un cambio en el código fuente que mejora la eficiencia en el llamado a los procedimientos de inicialización del cálculo de planillas. |