Desempenho do SSRS

O tempo adicional pode dever-se aos Serviços de informação que prestam o relatório, para além de questionar os dados. Por exemplo, se você tiver 55.000 linhas retornadas para o relatório e o servidor de relatório então tem que agrupar, ordenar e/ou filtrar essas linhas para renderizar o relatório, então isso poderia levar tempo adicional.

Eu daria uma olhada na forma como os dados estão sendo agrupados e filtrados no relatório, em seguida, rever o seu procedimento armazenado para ver se você poderia descarregar algum desse processamento para o código SQL, talvez usando alguns parâmetros. Tentar reduzir a quantidade de linhas devolvidas ao relatório para ser o mínimo necessário para renderizar o relatório e, de preferência, tentar evitar fazer o agrupamento e filtragem no próprio relatório.

Use os relatórios de desempenho do SSRS para depurar os seus problemas.

No servidor de relatórios irá encontrar uma tabela chamada ExecutionLog. você tem que procurar o id do Catálogo do seu relatório e verificar a última instância de execução. isto pode dizer-lhe a quebra dos tempos tomados - para recuperação de dados, para processamento, para renderização etc.

Arcaico pergunta, mas por causa de coisas como essa são bem recorrentes, o meu "rápida e suja" solução para melhorar o SSRS, que funciona perfeitamente em ambientes empresariais de grandes dimensões (eu sou a renderização de relatórios que podem ter até 100.000+ linhas diárias) é definir corretamente o InteractiveSize da página (por exemplo, a configuração de tamanho A4 -21 cm ). Quando InteractiveSize é definido para 0, então todos os resultados serão renderizados como uma única página e isso literalmente mata o desempenho do SSRS. Em casos como este, consultas que podem levar alguns segundos em seu DB pode levar uma eternidade para renderizar (ou causar uma exceção fora da memória, a menos que você tenha toneladas de H/W redundante em seu servidor SSRS). Então, em casos de consultas/ SP's que executam razoavelmente rápido em chamada direta e recuperar um grande número de linhas, definir Interativesize e você não vai precisar se preocupar com outras soluções mais sofisticadas.

Obviamente obter o relatório a correr correctamente (isto é, ter a mesma ordem de grandeza de tempo para seleccionar os dados como SSMS) seria preferível, mas como um trabalho em torno, o seu relatório suportaria instantâneos de execução (isto é, sem parâmetros ou parâmetros predefinidos armazenados no relatório)?

Isto permitirá obter e armazenar previamente uma fotografia agendada dos dados, o que significa que o SSRS só precisa de processar e renderizar o relatório quando o utilizador o abrir. Deve reduzir a espera a alguns segundos (dependendo do processamento que o relatório requer. YMMV, teste para ver se você tem uma melhoria de desempenho).

Vá para a página de propriedades do relatório no Gestor de relatórios, seleccione a execução, mude para desenhar este relatório a partir de uma imagem de execução de relatórios, indique o seu calendário.

A solução primária para acelerar os relatórios do SSRS é cache os relatórios. Se alguém fizer isso (ou meu pré-carregamento do cache às 7:30 am, por exemplo) ou caches os relatórios em-hit, um vai encontrar enormes ganhos na velocidade de carga.

Por favor, note que eu faço isto diariamente e profissionalmente e não estou simplesmente a depilar poético em SSRS

Caching em SSRS http://msdn.microsoft.com/en-us/library/ms155927.aspx

Pré-carregamento do Cache http://msdn.microsoft.com/en-us/library/ms155876.aspx

Se não gosta que os relatórios iniciais demorem muito e os seus dados são estáticos, ou seja, um registo geral diário ou algo do género, o que significa que os dados são relativamente estáticos ao longo do dia, pode aumentar a duração de vida da 'cache' .

Finalmente , Você também pode optar por gerentes de negócios para receber estes relatórios através de assinaturas de E-mail , que irá enviar-lhes um ponto no tempo Excel relatório que eles podem encontrar mais fácil e mais sistemático.

Você também pode usar parâmetros em SSRS para permitir uma análise fácil pelo Usuário e consultas mais rápidas. No tipo de construtor de consultas(@SSN) sob a coluna de filtros que deseja parameterizar, irá então encontrá-lo criado na pasta de parâmetros logo acima das fontes de dados na parte superior esquerda da sua GUI de ofertas. [Se não vir a secção fonte de dados no SSRS, carregue em CTRL+ALT + D.

Poucas coisas podem ser feitas para melhorar o desempenho do relatório, que são as seguintes:: 1. Activar o cache no Gestor de relatórios e definir um período de tempo para actualizar a 'cache'. 2. Aplicar a indexação em todas as tabelas de banco de dados da infra-estrutura que são usadas como fonte no relatório, embora o seu procedimento armazenado já esteja a demorar muito menos tempo a renderizar os dados, mas ainda a aplicar a indexação pode melhorar ainda mais o desempenho ao nível da infra-estrutura. 3. Usar conjuntos de dados partilhados em vez de usar os incorporados conjuntos de dados no relatório e aplicar cache em todos esses conjuntos de dados também. 4. Se possível, defina os parâmetros para carregar valores padrão. 5. Tente reduzir os dados que são selecionados pelo procedimento armazenado, por exemplo, se o relatório contém dados históricos que não é de uso, um filtro pode ser adicionado para excluir esses dados.

Tive o mesmo problema. A consulta correu em SQL muito bem, mas foi lenta como qualquer coisa em SSRS. Está a usar um parâmetro SSRS no seu conjunto de dados? Descobri que se você usar o parâmetro do relatório diretamente em certas consultas, há um enorme sucesso de desempenho.

Em vez disso, se tiver um parâmetro de relatório chamado @reportParam, no conjunto de dados, basta fazer o seguinte:

declare @reportParamLocal int
set @reportParamLocal = @reportParam

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

Por exemplo, encontrei enormes diferenças de tempo de execução ao converter entre os dados. Algum elemento no relatório usa a função CDate? Se assim for, você pode querer considerar fazer a sua formatação no nível sql.

As conversões em geral podem causar uma enorme desaceleração, por isso, dê um tempo para olhar para o seu conjunto de dados e ver qual pode ser o problema.

Este é um pouco de uma mistura das respostas acima, mas faça o seu melhor para obter os dados de volta de seu procedimento armazenado no formato mais simples e acabado. Faço toda a minha triagem, agrupamento e filtragem no servidor. O servidor é construído para isso e eu apenas deixar os Serviços de relatórios fazer o trabalho de exibição bonito.

OPTION (RECOMPILE)

Até ao fim da sua consulta principal no procedimento armazenado.

Isto irá garantir que a consulta é recompilada para diferentes parâmetros de cada vez, no caso de diferentes parâmetros necessitarem de um plano de execução diferente.

Eu tive um problema semelhante: uma consulta que retorna 4.000 linhas e corre em um segundo em seu próprio estava levando tanto tempo em SSRS que ele cronometrou.

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

Para corrigir isso, acabei passando o parâmetro para a consulta através de uma expressão, de modo que eu mesmo poderia controlar o filtro. Ou seja, na janela" Propriedades do conjunto de dados", no ecrã" parâmetros", substituí o valor do parâmetro por esta expressão:

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

... (Eu também dei resultado um novo nome: filelist) e, em seguida, eu atualizei a consulta para ficar assim:

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

Eu diria que mover a consulta para um procedimento armazenado também seria uma maneira eficaz de aliviar o problema (porque o SSRS basicamente faz a mesma junção antes de passar um parâmetro multi-valor para um procedimento armazenado). Mas, no meu caso, era um pouco mais simples tratar de tudo no relatório.