Relatorio demora muito para processar

Question

Ola, pessoal

Tenho um relatorio que é aberto por um programa (uso o report viewer no Visual Studio).

Ele tem muitos agrupamentos dentro de um agrupamento principal, formulas de visibilidade (para cada linha), conforme o contexto. etc

No servidor do cliente, demora muito, muito tempo mesmo para processar.  Foi relatado 10min, até 60min... 

(mesmo testando em horarios de pouca concorrencia, apos o horario comercial)

No ambiente de desenvolvimento, ele não demora nem 3 minutos. Mesmo sendo um tempo consideravel, seria razoavel, se no cliente ficasse pelo menos assim.

Sera que existe alguma configuração, alguma coisa que poderia mudar para ficar mais rapido no cliente?

Lembrando que é O RELATORIO EM SI, o processamento dele, ordenação, agrupamentos dele, etc. Nada do sistema em si, nem consulta ao BD (essa é rapida).

Obrigado

---

Julio C.

Answer 1

Julio,

Vamos lá, você poderia descrever melhor a sua necessidade respondendo as questões abaixo:

1 - Versão de Windows?

2 - Versão de SQL Server?

3 - Além deste relatório o que mais esta sendo executado no servidor de produção?

4 - Quais os recursos de hardware estão sendo utilizados em cada ambiente?

5 - No ambiente de desenvolvimento você possui o mesmo volume de dados do ambiente de produção?

---

Pedro Antonio Galvao Junior [MVP | MCC | MSTC | MIE | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

Answer 2

Complementando as perguntas do Galvão por favor , responde essas

1) O tempo do processamento no banco está satisfatório, quanto tempo demora ??

2)Quantidade de registros devolvidos do banco pra a aplicação ?

3)posta o Código da aplicação na parte que ele faz a requisição para banco 

e o código do DataSouce  do relátorio. 

Em resumo quero identificar que o relátorio não está fazendo acesso ao banco desnecessariamente

90% do casos são  Querys dentro de um ForEach quase eternos

Wesley Neves - Brasilia-DF

 
https://wesleyneves.wordpress.com/
MTA-SQL Server
MTA- Web Development
Analista Desenvolvedor.NET
Pós-Graduando em Banco de Dados 
"Se a resposta for útil ou ajudar ,não esqueça de marcar"

---

Wesley Neves

Answer 3

Boa noite, avalie no seu ambiente o plano de execução da query referente ao relatório, verifique se há keylookups, lazyspool, eaglespool, tablescan (com muitas linhas), sort (esse é causado por ordenação de registros), também é importante verificar o comando na base do cliente (ou em um ambiente semelhante) pois a base pode estar em situações diferentes (referente a índices ou na quantidade de registros). É importante ressaltar o tempo de uma query pode escalar conforme as quantidades de registros. Caso tenha dúvidas com relação ao plano de execução, ele pode ser gerado no Management Studio (nas teclas CTRL + M).

Answer 4

Ola pessoal,

(acho que me esqueci deste tópico, e o abandonei... revisando meus posts no MSDN agora, eu encontrei ele novamente. Peço desculpas, não foi intencional.)

É o seguinte. Não são acessados dados diretamente DO BANCO DE DADOS no momento da "renderização" (vou chamar assim) do relatório, que é a parte muito demorada.

A aplicação popula um dataset, que é usado no relatório, sendo que as consultas ao BD e a geração do dataset ocorrem antes da renderização do relatório, e de forma muito rápida e eficaz.

Mas o processamento do relatório é que é muito demorado. Ou seja, O problema é após o relatório abrir no Viewer, neste momento ele fica muito tempo processando.

*** Da época em que eu postei a dúvida para cá, efetuamos algumas ações PALIATIVAS visando melhorar um pouco a performance. Algumas bem custosas e bem pouco práticas, como remover algum agrupamento (por exemplo, algum agrupamento que se identificou que causava parte da demora e que fosse pouco utilizado por padrão nos relatórios), e criar um novo .rdlc com este agrupamento.

Neste tempo, também foi implementado Subreports em relatórios com quantidade considerável de dados (antes não havia), e não houve nenhum ganho de performance.

Enfim, não conseguimos resolver este problema de forma eficiente. Há algum tempo atras, usavamos Crystal Reports (feito da mesma forma, sem acessar dados direto do BD durante a construção do relatório, e sim do dataset já popula), e era absurdamente rápido, nenhum relatório do sistema chegava a durar 30 segundos, isso os maiores, com várias paginas.

Estamos pensando em estudar outras tecnologias para implementação dos relatórios.

---

Julio C.

Answer 5

Todas as perguntas tem resposta bem genéricas..

pode ser qualquer versão do Windows e SQL Server, são BDs bem pequenos, em ambientes que "sobra" hardware.

não retorna mais do que 100.000 linhas. não há o que melhorar em relação a infra estrutura. e como mencionei, não são pegos dados do BD no processamento do relatório.

Ocorre tanto no ambiente de produção quanto no de desenvolvimento (baixando backup do cliente).

A demora em algunas casos é de 10~15min para gerar um relatório com 50 páginas por exemplo, em que a execução das querys no BD foram "instantaneas".

os relatórios mais críticos são os que tem vários agrupamentos aninhados.

imagino que, na "renderização", o report viewer "percorra" toda uma tabela para cada registro, para localizar registros do agrupamento (isso várias vezes, pois tem vários agrupamentos).

Algo nesse sentido... 

---

Julio C.

Answer 6

Ola pessoal

estou revendo este assunto, pois preciso resolver isso no sistema. Tem relatórios que estão inviáveis de utilizar.

A solução mais drástica vai acabar sendo trocar de ferramenta, e ir fazendo os relatórios do zero...

-

No caso agora, estou implementando um relatório de exemplo, para tentar descobrir o que acontece. Bem simples, que dá em torno de 130 páginas.

Tirando ele só "mostrando os dados do dataset" (sem fazer todas as alterações que preciso), leva 4 ou 5 segundos para processar. Ok.

Porém, simplesmente colocando uma concatenação e uma fórmula de visibilidade de linha, passa para 25 segundos.

Implementando todas as regras de negócio, com agrupamentos e fórmulas, o relatório demora cerca de 5min para renderizar.

Como já mencionei antes, o report não está conectado diretamente com o  SQL Server. E sim, via programação há um DataSet que é populado, e então é chamado o RDLC.

Até pensei se deveria postar em outro fórum mais específico, mas como já tinha este tópico, resolvi atualizar ele.

---

Julio C.

Answer 7

Julio,

As configurações do ambiente continuam as mesmas? Se sim, ao meu ver o seu problema esta acondicionado ao uso deste DataSet que esta servindo como Middleware entre a aplicação e os relatórios.

Porque não obter por fazer uso de ambiente de gerenciamento de relatórios através do uso mais aplicado e adequado ao Reporting Services?

---

Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

Answer 8

Julio,

As configurações do ambiente continuam as mesmas? Se sim, ao meu ver o seu problema esta acondicionado ao uso deste DataSet que esta servindo como Middleware entre a aplicação e os relatórios.

Porque não obter por fazer uso de ambiente de gerenciamento de relatórios através do uso mais aplicado e adequado ao Reporting Services?

---

Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

Ola.

Me parece ser uma boa idéia.. é de se pensar nessa solução, vou considerar isso e levar para a empresa, para esses relatórios que dão problema, serem tratados de uma forma mais específica, e no Reporting Services.

O problema está especificamente ao gerar o relatório para PDF (ou excel, ou word..).

                    'Adiciona os DataSources
                    For i As Integer = 0 To Rel.LocalReport.DataSources.Count - 1
                        Relatorio.LocalReport.DataSources.Add(Rel.LocalReport.DataSources.Item(i))
                    Next

                    'Adiciona os Parametros
                    Dim parametros(Rel.LocalReport.GetParameters.Count - 1) As ReportParameter
                    For i As Integer = 0 To Rel.LocalReport.GetParameters.Count - 1
                        parametros(i) = New ReportParameter(Rel.LocalReport.GetParameters.Item(i).Name, Rel.LocalReport.GetParameters.Item(i).Values(0))
                    Next

                    Relatorio.LocalReport.SetParameters(parametros)

(até ai, é instantâneo)

                        Dim exportBytes() As Byte = Relatorio.LocalReport.Render(TipoImpressao, deviceInfo, mimeType, encoding, fileNameExtension, streamids, warnings)

O problema ocorre tanto pelo código, quanto exportando PDF pela opção no reportviewer na tela (para ficar claro que não é uma questão do código em si).

Para o momento.. estou vendo uma "alternativa técnica", que inclusive fecha com o que eu ja estava em mente, que é o fato de que o problema se agravou nos últimos anos:

<trust legacyCasModel="true" level="Full"/>

Nesse tópico explica:

https://forums.asp.net/t/1812151.aspx?ReportViewer+too+slow+but+using+report+server+directly+is+fast+

---

Utilizando esta opção no web.config, o tempo de geração do relatório que estavam 57min (nesse caso um relatório bem grande, com quase 3.000 páginas, que é aceitável demorar, mas não tanto assim), para 4min.

Mas não posso simplesmente colocar isso no web.config, pode ter efeitos colaterais.

estamos analisando para fazer desta forma:

https://stackoverflow.com/questions/30511856/local-report-rdlc-to-pdf-very-slow
(run the reportviewer in a separated Appdomain)

---

Julio C.

Answer 9

Julio,

Ok, perfeito, não existe a possibilidade do processamento deste relatório ser então dividido em partes?

Entre os anos de 2005 é 2010 trabalhei em no desenvolvimento de sistemas para área da saúde, controle de qualidade e especificações químicas que seguiam os padrões da Anvisa e Secretaria da Saúde.

Um dos principais relatórios desenvolvidos se chamava Histórico de Rastreabilidade, o qual tinha entre 200 á 1000 páginas, o mesmo foi construido no Report Builder, uma das formas que aplicamos para diminuir a sobrecarga era colocar o processamento do relatório sendo feito de forma separada, gerando arquivos específicos para cada conteúdo e depois no momento da impressão colocamos e ordem na fila de impressão para que o mesmo fosse impresso.

Um detalhe importante que você tem que verificar é justamente as configurações do seu servidor de impressão ou até mesmo da estação de trabalho que esta processamento o mesmo, verifique as configurações de buffer utilizado para gerar o arquivo ou até mesmo a impressão direta.

No começo de 2020 tive uma demanda interessaante que se relacionava com a maneira que a impressão era direcionada para impressora, na empresa que estava com problemas, alteramos a forma de impressão, ao invês de iniciar a impressão após o relatório ser enviado totalmente para impressora, colocamos para que o mesmo fosse sendo impresso diretamente.

Isso pode parecer bobagens mas resolveu 80% dos problemas de impressão ainda mais quando se refere a impressões feitas via Browser.

---

Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]