Manejo de informes de ejecución larga

Question

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 maneja 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 una manera más simple que no estoy viendo?

Answer 1

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.

Answer 2

¿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.

Answer 3

Considero que este informe de alguna manera estará 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 separado para el manejo de la cola.

Actualización: enviando al usuario pueden ser correo electrónico o pueden tener una página de 'informes', donde pueden consultar el estado de sus informes y descargarlos si están listos.

Answer 4

Sus usuarios no pueden aceptar este enfoque, pero:

cuando solicitan un informe (haciendo clic en un botón o un enlace o lo que sea), se puede iniciar el proceso de generación de informes en un hilo separado, y volver dirige al usuario a una página que dice "gracias, tu informe te será enviado por correo electrónico en unos minutos".

Cuando finaliza el proceso de generación del informe, puede enviar el PDF directamente (probablemente no funcionará debido a su tamaño) o guardar el informe en el servidor y enviar un enlace al usuario por correo electrónico.

Como alternativa, puede ingresar a IIS y aumentar el tiempo de espera a> 3 minutos.

Answer 5

Aquí es algunas de las cosas que haría si se presentaría este problema:

1- Detener a los tiempo de espera! Son un desperdicio total de recursos.(Abre el valor de tiempo de espera de las páginas asp)

2- Centraliza todo el acceso a bases de datos en un solo punto, luego reúne 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).

Con el tiempo, va a ser más fácil para que usted pueda "caché" memorias Si usted pasa por este punto de acceso único (ejemplo, misma consulta misma fecha volverá misma PDF generado previamente)

3- Sé que esto realmente no era 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 pantalla cuando el informe está listo parece genial ... si su usuario generalmente envía un lote de informe que se generará quizás un pequeño tablero indicando la progresión de "su" cola podría construirse en el aplicación Un pequeño control de ajax actualizaría periódicamente el estado ... Sugerencia: si usó ese acceso de acceso centralizado y tiene suficiente información sobre qué se ejecuta cuando por qué y por cuánto tiempo, con el tiempo podrá estimar aproximadamente el tiempo que le llevará a un informar para ejecutar

Si el tiempo de respuesta es crítico para la misión, ¿algunos usuarios deberían estar limitados en el rango de datos (por ejemplo, el rango de fechas) durante algunas horas del día?

Buena suerte y por favor publicar más detalles sobre su escenario si desea obtener pistas más precisas ...

Answer 6

ajuste de las consultas es probablemente su mejor lugar para empezar. 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, puede que necesite agregar algunos índices, o incluso configurar una tabla para almacenar la información de su informe de manera no normalizada, para que esté disponible más rápido. 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 parámetros variables de entrada del usuario, almacenar en caché el informe antes 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 código de generación de informes es 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 .