reporting-services - rsreportserver - reset reporting services configuration

Rendimiento de SSRS

Question

He creado un Informe SSRS para recuperar 55000 registros usando un Procedimiento almacenado. Cuando se ejecuta desde el Stored Proc toma solo 3 segundos, pero cuando se ejecuta desde el informe de SSRS tarda más de un minuto. ¿Como puedó resolver esté problema?

Answer 1

Esta es una mezcla de las respuestas anteriores, pero haga todo lo posible para recuperar los datos de su procedimiento almacenado en el formato más simple y acabado. Hago todo mi clasificación, agrupamiento y filtrado en el servidor. El servidor está diseñado para esto y solo dejo que los servicios de informes funcionen bien.

Answer 2

El tiempo adicional podría deberse a que Reporting Services representa el informe además de consultar los datos. Por ejemplo, si tiene 55,000 filas devueltas para el informe y el servidor de informes luego tiene que agrupar, ordenar y / o filtrar esas filas para procesar el informe, eso podría llevar más tiempo.

Me gustaría ver la forma en que los datos se agrupan y se filtran en el informe, luego revise su procedimiento almacenado para ver si puede descargar algo de ese procesamiento al código SQL, tal vez usando algunos parámetros. Intente e intente reducir la cantidad de filas devueltas al informe para que sea el mínimo necesario para procesar el informe y, de preferencia, intente evitar agrupar y filtrar en el informe.

Answer 3

en el ReportServerDB encontrará una tabla llamada ExecutionLog. debe buscar la identificación del catálogo de su informe y verificar la última instancia de ejecución. esto puede indicarle el desglose de los tiempos necesarios para la recuperación de datos, el procesamiento, el procesamiento, etc.

Answer 4

Obviamente, sería preferible obtener el informe correctamente (es decir, tomar el mismo orden de magnitud para seleccionar los datos como SSMS) pero, como solución alternativa, su informe respaldaría las instantáneas de ejecución (es decir, no hay parámetros ni valores predeterminados de los parámetros almacenados en el informe). )?

Esto permitirá que una instantánea programada de los datos se recupere y almacene de antemano, lo que significa que SSRS solo necesita procesar y presentar el informe cuando el usuario lo abre. Debería reducir la espera a unos pocos segundos (dependiendo de qué procesamiento requiera el informe. YMMV, prueba para ver si obtienes una mejora en el rendimiento).

Vaya a la pestaña de propiedades del informe en el Administrador de informes, seleccione Ejecución, cambie a Renderizar este informe desde una instantánea de ejecución de informes, especifique su programación.

Answer 5

Use los informes del Panel de rendimiento de SSRS para depurar sus problemas.

Answer 6

Tuve tal problema debido a los parámetros olfateando en mi SP. En SQL Management Studio cuando ejecuté mi SP, lo recreé con un nuevo plan de ejecución (y la llamada fue muy rápida), pero mis informes utilizaron un mal plan anterior (para otra secuencia de parámetros) y el tiempo de carga fue mucho más largo que en SQL MS.

Answer 7

Se pueden hacer pocas cosas para mejorar el rendimiento del informe, que son las siguientes: 1. Habilite el almacenamiento en caché en el administrador de informes y establezca un período de tiempo para actualizar el caché. 2. Aplique indexación en todas las tablas de la base de datos back-end que se utilizan como fuente en el informe, aunque su procedimiento almacenado ya está tardando mucho tiempo en procesar los datos, pero seguir aplicando la indexación puede mejorar aún más el rendimiento en el nivel de back-end. 3. Utilice conjuntos de datos compartidos en lugar de utilizar datasets integrados en el informe y aplique el almacenamiento en caché en todos estos conjuntos de datos. 4. Si es posible, configure los parámetros para cargar valores predeterminados. 5. Intente reducir los datos seleccionados por el procedimiento almacenado; por ejemplo, si el informe contiene datos históricos que no sirven, se puede agregar un filtro para excluir esos datos.

Answer 8

Experimenté el mismo problema. Query se ejecutó en SQL muy bien, pero fue lento como cualquier cosa en SSRS. ¿Estás usando un parámetro de SSRS en tu conjunto de datos? Descubrí que si usa el parámetro de informe directamente en ciertas consultas, se produce un gran golpe de rendimiento.

En cambio, si tiene un parámetro de informe llamado @reportParam, en el conjunto de datos, simplemente haga lo siguiente:

declare @reportParamLocal int
set @reportParamLocal = @reportParam

select * from Table A where A.field = @reportParam

Es un poco extraño. No sé muy bien por qué funciona, pero sí para mí.

Answer 9

Una cosa rápida que quizás desee observar es si los elementos en su informe pueden ralentizar la ejecución.

Por ejemplo, he encontrado diferencias de tiempo de ejecución masivas al convertir entre dateTimes. ¿Algún elemento en el informe usa la función CDate? Si es así, puede considerar hacer su formateo en el nivel sql.

Las conversiones en general pueden causar una desaceleración masiva, así que tómese el tiempo para ver su conjunto de datos y ver cuál puede ser el problema.

Answer 10

Tuve el mismo problema ... efectivamente fue el tiempo de renderizado, pero más específicamente, fue porque SORT estaba en SSRS. Intente mover su clasificación al procedimiento almacenado y eliminar cualquier CLASIFICACIÓN del informe SSRS. En 55K filas, esto mejorará dramáticamente.

Answer 11

Pregunta arcaica, pero debido a que cosas así son recurrentes, mi solución "rápida y sucia" para mejorar SSRS, que funciona perfectamente en grandes entornos empresariales (estoy representando informes que pueden tener hasta 100.000+ líneas diarias) es configurar correctamente el InteractiveSize. de la página (por ejemplo, configurándola en tamaño A4 -21 cm). Cuando InteractiveSize se establece en 0, todos los resultados se presentarán como una sola página y esto literalmente mata el rendimiento de SSRS. En casos como ese, las consultas que pueden tomar unos pocos segundos en su base de datos pueden demorar una eternidad en renderizar (o causar una excepción de falta de memoria a menos que tenga toneladas de H / W redundantes en su servidor SSRS). Por lo tanto, en casos de consultas / SP que se ejecutan razonablemente rápido en llamadas directas y recuperan gran cantidad de filas, configure InteractiveSize y no tendrá que preocuparse por otras soluciones más sofisticadas.

Answer 12

La solución principal para acelerar los informes de SSRS es almacenar en caché los informes. Si uno hace esto (ya sea precargando el caché a las 7:30 a.m., por ejemplo) o almacena en caché los informes con éxito, uno encontrará aumentos masivos en la velocidad de la carga.

Tenga en cuenta que lo hago a diario y profesionalmente y no estoy simplemente depilando poético en SSRS

Almacenamiento en caché en SSRS http://msdn.microsoft.com/en-us/library/ms155927.aspx

Precargando el caché http://msdn.microsoft.com/en-us/library/ms155876.aspx

Si no le gusta que los informes iniciales tarden mucho y sus datos son estáticos, es decir, un diario general diario o similar, lo que significa que los datos son relativamente estáticos a lo largo del día, puede aumentar la duración de la caché .

Finalmente , también puede optar por que los gerentes de negocios reciban estos informes a través de suscripciones por correo electrónico , que les enviarán un informe puntual de Excel que les resultará más fácil y más sistemático.

También puede usar parámetros en SSRS para permitir un análisis más fácil por parte del usuario y consultas más rápidas. En el generador de consultas escriba IN (@SSN) debajo de la columna Filtro que desea parametrizar, luego lo encontrará creado en la carpeta de parámetros justo arriba de las fuentes de datos en la esquina superior izquierda de su GUÍA BIDS. [Si no ve la sección de fuente de datos en SSRS, presione CTRL + ALT + D.

Vea una pregunta casi idéntica aquí: Problemas de rendimiento con SSRS

Answer 13

Además de la respuesta de @ RomanBadiornyi, intente agregar

OPTION (RECOMPILE)

hasta el final de su consulta principal en el procedimiento almacenado.

Esto asegurará que la consulta se vuelva a compilar para diferentes parámetros cada vez, en caso de que diferentes parámetros necesiten un plan de ejecución diferente.

Answer 14

Tuve un problema similar: una consulta que devuelve 4.000 filas y se ejecuta en 1 segundo por sí misma llevaba tanto tiempo en SSRS que se agotó el tiempo de espera.

Resultó que el problema fue causado por la forma en que SSRS manejaba un parámetro multivaluado. Curiosamente, si el usuario seleccionó varios valores, el informe se procesó rápidamente (~ 1 segundo), pero si solo se seleccionó un valor único, el informe tardó varios minutos en renderizarse.

Aquí está la consulta original que tardaba más de 100 veces en renderizarse de lo que debería:

SELECT ...
FROM   ...
WHERE  filename IN (@file);
-- @file is an SSRS multi-value parameter passed directly to the query

Sospecho que el problema era que SSRS traía toda la tabla de origen (más de 1 millón de filas) y luego realizaba un filtro del lado del cliente.

Para solucionar esto, terminé pasando el parámetro a la consulta a través de una expresión, para poder controlar el filtro yo mismo. Es decir, en la ventana "Propiedades del conjunto de datos", en la pantalla "Parámetros", reemplacé el valor del parámetro con esta expresión:

=JOIN(Parameters!file.Value,",")

... (También di el resultado un nuevo nombre: lista de archivos) y luego actualicé la consulta para que se vea así:

SELECT ...
FROM   ...
WHERE  '','' + @filelist + '','' LIKE ''%,'' + FILENAME + '',%'';
-- @filelist is passed to the query as the following expression:
-- =JOIN(Parameters!file.Value,",")

Supongo que mover la consulta a un procedimiento almacenado también sería una forma efectiva de aliviar el problema (porque SSRS básicamente hace la misma JOIN antes de pasar un parámetro multivalor a un procedimiento almacenado). Pero en mi caso fue un poco más simple manejarlo todo dentro del informe.

Finalmente, debo señalar que el operador LIKE tal vez no sea la forma más eficiente de filtrar en una lista de elementos, pero es mucho más fácil de codificar que un enfoque de cadena dividida, y el informe ahora se ejecuta en aproximadamente un segundo, por lo que se divide la cuerda no parecía valer la pena el esfuerzo extra.