c# - microsoft - telerik reporting documentation
Manejo de informes de larga ejecución (6)
¿Qué hay de enviar el informe por correo electrónico al usuario? Todo lo que debe hacer la página asp es enviar la solicitud para generar el informe y devolver un mensaje de que el informe se enviará por correo electrónico una vez que se haya terminado de ejecutar.
Estoy trabajando en una aplicación ASP.net escrita en C # con la base de datos Sql Server 2000. Tenemos varios informes PDF que los clientes usan para sus necesidades comerciales. El problema es que estos informes tardan un tiempo en generar (> 3 minutos). Lo que generalmente termina sucediendo es cuando el usuario solicita el informe, el tiempo de espera de la solicitud mata la solicitud antes de que el servidor web tenga tiempo de terminar de generar el informe, por lo que el usuario nunca tiene la oportunidad de descargar el archivo. Luego, el usuario actualizará la página y volverá a intentarlo, lo que inicia todo el proceso de generación de informes y aún termina agotando el tiempo. (No, no estamos almacenando informes en caché ahora, eso es algo por lo que estoy presionando ...).
¿Cómo manejas estos escenarios? Tengo una idea en mi mente que implica hacer una solicitud asincrónica para iniciar la generación del informe y luego tener algún javascript para verificar periódicamente el estado. Una vez que el estado indique que el informe ha finalizado, realice una solicitud por separado para el archivo real.
¿Hay alguna manera más simple que no estoy viendo?
Consideraría que este informe, de alguna manera, estaría un poco fuera de línea desde el punto de vista del procesamiento.
Como crear una cola para colocar las solicitudes de informes, procesar los informes desde allí y después de finalizar, puede enviar un mensaje al usuario.
Tal vez incluso crearía un servicio de Windows por separado para el manejo de la cola.
Actualización: el envío al usuario puede ser por correo electrónico o pueden tener una página de ''informes'', donde pueden verificar el estado de sus informes y descargarlos si están listos.
Estas son algunas de las cosas que haría si me presentaran este problema:
1- Detener el tiempo de espera! Son un desperdicio total de recursos. (abre el valor de tiempo de espera de las páginas asp)
2- Centralizar todo el acceso a bases de datos en un solo punto, luego reunir estadísticas sobre qué informes se ejecutaron cuando por quién y cuánto tiempo tomó. Investigue por qué tarda tanto, ¿es por la complejidad del informe? ¿rango de datos? carga del servidor? (En realidad, todos podrían escribir eso en un archivo .csv en el servidor e importar este archivo periódicamente en el servidor sql para analizarlo más adelante).
Eventualmente, será más fácil para usted "cachear" los informes si pasa por este único punto de acceso (por ejemplo, la misma consulta la misma fecha devolverá el mismo PDF generado previamente)
3- Sé que esta no era realmente la pregunta, pero ¿has intentado sumergirte en esas consultas para ver por qué tardan tanto en correr? Afinación de consultas tal vez?
4- El mensaje de correo electrónico / SMS / en la pantalla cuando el informe está listo parece excelente ... si su usuario generalmente envía un lote de informe para generar, tal vez un pequeño tablero que indique la progresión de "su" cola se pueda generar en la aplicación. Un pequeño control de ajax actualizaría periódicamente el estado ... Sugerencia: si utilizó ese acceso de acceso centralizado y tiene suficiente información sobre qué se ejecuta cuando por qué y por cuánto tiempo, eventualmente podrá estimar aproximadamente el tiempo que tomará un informe correr.
Si el tiempo de respuesta es crítico para la misión, ¿deberían ciertos usuarios estar limitados en el rango de datos (por ejemplo, el rango de fechas) durante algunas horas del día?
Buena suerte y, por favor, publique más detalles sobre su escenario si quiere obtener consejos más precisos ...
La sintonización de consultas es probablemente su mejor lugar para comenzar. Aunque no sé si estás generando el informe, ese paso en realidad no debería demorar tanto. Una consulta de bajo rendimiento por otro lado podría matar tu rendimiento.
Dependiendo de lo que encuentre al mirar la consulta, es posible que necesite agregar algunos índices, o posiblemente incluso configurar una tabla para almacenar la información de su informe de manera no normalizada, para que esté disponible más rápidamente. Esta tabla desnormalizada podría actualizarse (a través de un trabajo de SQL Server) cada hora o con la frecuencia que dicten sus requisitos (dentro de lo razonable).
Si se trata de un informe relativamente estático, sin variar los parámetros de entrada del usuario, almacenar en caché el informe más temprano también sería una buena idea, pero es difícil decir más sobre esto sin conocer su situación.
Para un problema como este, realmente debe comenzar en la base de datos a menos que tenga motivos para sospechar que su informe genera el código de ser el culpable. Hay varias tiritas que podrías usar que podrían ayudarte por un tiempo, pero si tu DB es la causa raíz, esas soluciones no se escalarán bien, y es probable que encuentres problemas similares (o peores) en el futuro .
Sus usuarios pueden no aceptar este enfoque, pero:
Cuando solicitan un informe (al hacer clic en un botón o un enlace o lo que sea), puede iniciar el proceso de generación de informes en un hilo separado y redirigir al usuario a una página que dice "gracias, su informe será enviado por correo electrónico a usted en unos minutos ".
Cuando el hilo termine de generar el informe, puede enviarlo directamente por correo electrónico (probablemente no funcionará debido a su tamaño), o guardar el informe en el servidor y enviar un enlace por correo electrónico al usuario.
Alternativamente, puede ingresar a IIS y aumentar el tiempo de espera a> 3 minutos.
Usar el sistema de archivos aquí es probablemente una buena apuesta. Tenga una solicitud que devuelva inmediatamente una url a la ubicación del informe en PDF. Su servidor puede iniciar un proceso externo o enviarse una solicitud para realizar el informe. El cliente puede sondear el servidor (usando http HEAD) para el PDF en la url proporcionada. Si hace que el nombre de archivo del PDF se derive de los parámetros del informe, ya sea mediante un hash o directamente poniendo los parámetros en el nombre, también obtendrá el caché instantáneo del lado del servidor.