Alterações para otimização dos leitores

[Matheus Rodrigo Koch]

Bom dia pessoal,

Me deparei com uma situação na busca de NFS-e da cidade de Porto Alegre em que o leitor do ACBr estava demorando demais para ler o arquivo de retorno do Web Service.

Foram identificadas duas rotinas que estavam extremamente lentas, a primeira seria na primeira linha da função  TNFSeWebService.ExtrairRetorno, onde ele realizava o seguinte comando: 

Ele ficava horas rodando esta linha devido ao tamanho do XML de retorno, a partir disso foi implementado a rotina HTMLStringReplace para realizar o mesmo comando porém através de uma TStringList, de forma que ele realizasse o comando linha por linha e o resultado foi impressionante. Esta rotina está no fonte 

 

A segunda rotina seria o TLeitor.rExtrai, onde sempre que ele é chamado dentro da rotina TRetornoNFSe.LerXml é passado um parâmetro "item" e que com esse parâmetro toda vez que a função é chamada ele vai apagando todo meu XML de retorno desde o início até chegar no meu XML correspondente ao meu parâmetro "item". Com isso foi implementado um novo parâmetro chamado "UsarCache" onde quando é passado como TRUE a rotina armazena a posição final do meu último XML já extraído e na próxima vez que o rExtrai for chamado com o parâmetro como TRUE ele irá apagar o meu XML de retorno até a posição que tenho armazenada, assim sendo muito mais rápido do que a forma que ocorria anteriormente.

 

Obs: Temos algumas alterações também no leitor para extrair notas de algumas cidades como Joinville por exemplo, onde o leitor não conseguia extrair o XML, e estão no mesmo fonte, assim estou devolvendo tudo, hoje já utilizamos e está funcional sem problema algum. Também estou enviando alguns ArqINI que realizamos alterações e funcionam a consulta de NFS-e. A função HTMLStringReplace está dentro do fonte uStringReplaceACBR.pas.

pcnLeitor.pas pnfsLerListaNFSe.pas pnfsConversao.pas ACBrNFSeWebServices.pas ACBrUtil.pas pnfsNFSeR.pas WebISSv2.ini SimplISS.ini Cidades.ini

uStringReplaceACBR.pas

Editado 2 Outubro, 2019 por rk matheus
Faltou adicionar um fonte

[Juliana Tamizou]

Bom dia Matheus,

Obrigada pela contribuição, qual foi o ganho de tempo com estas alterações?

Att.

[Matheus Rodrigo Koch]

Boa tarde Juliana,

Em uma consulta que retornava cerca de 1500 notas, utilizando o leitor da forma que estava se passavam 6 horas e ainda não terminava de extrair o XML, já com as alterações realizadas levou cerca de 2 minutos. Confesso que olhando assim parece até uma mentira, porém realmente a rotina estava extremamente lenta.

A busca era realizada no Web Service da cidade de Porto Alegre.

[Italo Giurizzato Junior]

Boa tarde Matheus,

Muito obrigado pela colaboração, passei para os demais consultores e moderadores para que eles possam avaliar e ver se não vai gerar nenhum efeito colateral com os demais DF-e, uma vez que você fez alterações no pcnLeitor e ACBrUtil.

[EMBarbosa]

5 horas atrás, rk matheus disse:

Bom dia pessoal,

Me deparei com uma situação na busca de NFS-e da cidade de Porto Alegre em que o leitor do ACBr estava demorando demais para ler o arquivo de retorno do Web Service.

Foram identificadas duas rotinas que estavam extremamente lentas, a primeira seria na primeira linha da função  TNFSeWebService.ExtrairRetorno, onde ele realizava o seguinte comando: 

Ele ficava horas rodando esta linha devido ao tamanho do XML de retorno, a partir disso foi implementado a rotina HTMLStringReplace para realizar o mesmo comando porém através de uma TStringList, de forma que ele realizasse o comando linha por linha e o resultado foi impressionante. Esta rotina está no fonte 

 

A segunda rotina seria o TLeitor.rExtrai, onde sempre que ele é chamado dentro da rotina TRetornoNFSe.LerXml é passado um parâmetro "item" e que com esse parâmetro toda vez que a função é chamada ele vai apagando todo meu XML de retorno desde o início até chegar no meu XML correspondente ao meu parâmetro "item". Com isso foi implementado um novo parâmetro chamado "UsarCache" onde quando é passado como TRUE a rotina armazena a posição final do meu último XML já extraído e na próxima vez que o rExtrai for chamado com o parâmetro como TRUE ele irá apagar o meu XML de retorno até a posição que tenho armazenada, assim sendo muito mais rápido do que a forma que ocorria anteriormente.

 

Obs: Temos algumas alterações também no leitor para extrair notas de algumas cidades como Joinville por exemplo, onde o leitor não conseguia extrair o XML, e estão no mesmo fonte, assim estou devolvendo tudo, hoje já utilizamos e está funcional sem problema algum. Também estou enviando alguns ArqINI que realizamos alterações e funcionam a consulta de NFS-e. A função HTMLStringReplace está dentro do fonte uStringReplaceACBR.pas.

pcnLeitor.pas 14 kB · 2 downloads pnfsLerListaNFSe.pas 53 kB · 1 download pnfsConversao.pas 942 kB · 1 download ACBrNFSeWebServices.pas 217 kB · 1 download ACBrUtil.pas 144 kB · 1 download pnfsNFSeR.pas 222 kB · 1 download WebISSv2.ini 9 kB · 1 download SimplISS.ini 9 kB · 1 download Cidades.ini 86 kB · 1 download

uStringReplaceACBR.pas 610 B · 1 download

É possível anexar um xml e descrever um passo a passo para verificar mais a fundo?

Notei que o método HTMLStringReplace o que foi alterado é mudar de ReplaceString para StringReplace e executar ele em partes da string por vez...

Só que ele não está fazendo os casts originais... Acho que isso pode explicar seu ganho de performance. Mas pode acarretar outros problemas.

Antes...
ReplaceString(AnsiString(S), AnsiString(OldPatern), AnsiString(ACBrStr(NewPattern)))

Agora
StringReplace(wSL[w], OldPattern, NewPattern, Flags);

[Matheus Rodrigo Koch]

Bom dia Elton,

Alterei o HTMLStringReplace para utilizar o ReplaceString e estou enviando novamente os fontes.

Estou tentando enviar um projeto que fiz para testar essa rotina, nele é possível verificar o tempo de processamento de como está a rotina hoje e o tempo de processamento com o HTMLStringReplace, porém ele zipado tem 9,17 MB, como poderia enviar isso para vocês? Pois facilitaria bastante nos testes.

Estou enviando logo em seguida o XML com o nome "Retorno.zip" pois o post só permite 2 MB de arquivos por vez.

pcnLeitor.pas pnfsNFSeR.pas pnfsConversao.pas pnfsLerListaNFSe.pas ACBrNFSeWebServices.pas ACBrDFeXsLibXml2.pas ACBrUtil.pas Cidades.ini SimplISS.ini WebISSv2.ini

Segue o XML zipado.

Retorno.zip

[EMBarbosa]

Em 03/10/2019 at 08:26, rk matheus disse:

porém ele zipado tem 9,17 MB, como poderia enviar isso para vocês? Pois facilitaria bastante nos testes.

Estou enviando logo em seguida o XML com o nome "Retorno.zip" pois o post só permite 2 MB de arquivos por vez.

Como nós mesmos podemos compilar, geralmente basta remover os arquivos .exe e .dcu. Daí o tamanho do arquivo compactado cai drasticamente.

[Matheus Rodrigo Koch]

Bom dia,

 

Segue projeto.

 

Lembrando que o XML deve estar na mesma pasta do .exe.

StringReplace otimizado.rar

[EMBarbosa]

Em 07/10/2019 at 10:45, rk matheus disse:

Bom dia,

 

Segue projeto.

 

Lembrando que o XML deve estar na mesma pasta do .exe.

StringReplace otimizado.rar 57 kB · 0 downloads

Olá.

   Só gostaria de informar que estou analisando o seu código.

[Matheus Rodrigo Koch]

Opa,

Beleza, fico no aguardo de um retorno.

[EMBarbosa]

Em 02/10/2019 at 09:07, Matheus Rodrigo Koch disse:

Obs: Temos algumas alterações também no leitor para extrair notas de algumas cidades como Joinville por exemplo, onde o leitor não conseguia extrair o XML, e estão no mesmo fonte, assim estou devolvendo tudo, hoje já utilizamos e está funcional sem problema algum. Também estou enviando alguns ArqINI que realizamos alterações e funcionam a consulta de NFS-e.

Olá Matheus.

   Queria te pedir o favor de dividir em tópicos separados as sugestões. Porque é muita informação e estamos dividindo as tarefas aqui.

   Queira por favor postar os arquivos INI em outro tópico para que o @Italo Jurisato Junior possa analisar.

   As alterações relacionadas a Joinville também, se possível, queira postar em ainda um outro tópico específico para elas. Assim, além do Italo, pessoas dessas cidades poderão testar também.

[Matheus Rodrigo Koch]

Olá Elton,

Certo, irei abrir um novo tópico com as alterações relacionadas a NFS-e, porém acaba sendo complicado de fazer um tópico somente para cidade de Joinville, pois já realizamos diversas alterações no leitor de NFS-e para diversas cidades.

[EMBarbosa]

41 minutos atrás, Matheus Rodrigo Koch disse:

Olá Elton,

Certo, irei abrir um novo tópico com as alterações relacionadas a NFS-e, porém acaba sendo complicado de fazer um tópico somente para cidade de Joinville, pois já realizamos diversas alterações no leitor de NFS-e para diversas cidades.

   Ahh claro, entendi... Você pode criar um tópico pra as "diversas alterações da NFS-e  para atender as diversas cidades".

   A questão é que no momento esse tipo de alteração eu não consigo validar tão bem... Não queremos que nada passe despercebido.

[Italo Giurizzato Junior]

Bom dia Matheus,

Dependendo da alteração feita no arquivo INI de um provedor não tem nada haver com o código do componente, sendo assim não impede de você criar um novo tópico.

Quero lembrar que agora temos um tópico exclusivo para postagens de alterações e acréscimos de cidades.

 

[Matheus Rodrigo Koch]

Certo,

Já criei o tópico 

 

Irei adicionar os arquivos INI no tópico mencionado pelo @Italo Jurisato Junior para facilitar.

Peço desculpas pela confusão, sou novo aqui no fórum e não conheço sobre os tópicos padrões.

Editado 23 Outubro, 2019 por Matheus Rodrigo Koch

[EMBarbosa]

Em 07/10/2019 at 10:45, Matheus Rodrigo Koch disse:

Bom dia,

 

Segue projeto.

 

Lembrando que o XML deve estar na mesma pasta do .exe.

StringReplace otimizado.rar 57 kB · 1 download

Olá Matheus,

   Muito obrigado pela contribuição. Com base no que você passou, eu investiguei mais a fundo o problema. A sua função ajudava em alguns casos, mas não resolvia totalmente o problema em outros (como no Lazarus).

   Adicionamos a unit do Alexandre Machado do IntraWeb.

   Subi as alterações para o SVN na Revisão  18013.
   Pelo que vi está tudo certo.
   Queira por favor atualizar, testar e reportar qualquer problema.

Mais uma vez obrigado.

   Com respeito a função  TLeitor.rExtrai, ainda tenho que analisar melhor... mas se você tiver um exemplo de lentidão seria útil.

[Matheus Rodrigo Koch]

1 hora atrás, EMBarbosa disse:

Olá Matheus,

   Muito obrigado pela contribuição. Com base no que você passou, eu investiguei mais a fundo o problema. A sua função ajudava em alguns casos, mas não resolvia totalmente o problema em outros (como no Lazarus).

   Adicionamos a unit do Alexandre Machado do IntraWeb.

   Subi as alterações para o SVN na Revisão  18013.
   Pelo que vi está tudo certo.
   Queira por favor atualizar, testar e reportar qualquer problema.

Mais uma vez obrigado.

   Com respeito a função  TLeitor.rExtrai, ainda tenho que analisar melhor... mas se você tiver um exemplo de lentidão seria útil.

Boa tarde Elton,

De nada, estamos aqui para sempre deixar o componente cada ver melhor.

Em relação as suas alterações temos um problema, no fonte ACBrNFSeWebService.pas temos o seguinte trecho de código que foi alterado:

O problema é que ele não está realizando da mesma forma que era anteriormente a conversão, na verdade este trecho de código deveria estar desta forma:

Realizei esta alteração e ao realizar os teste funcionou normalmente.

Em relação ao TLeitor.rExtrai é possível realizar o teste com o XML que foi enviado, onde se for utilizado a rotina que temos atualmente no ACBr veremos que a cada loop executado o processo fica mais lento, pois o mesmo precisa apagar cada vez mais texto. Utilizando o que lhe enviei conseguimos guardar a posição do último XML que foi extraído, assim apagamos direto na posição dele para que assim o próximo já seja o que desejamos.

Não sei se fui claro, qualquer coisa pode perguntar aqui que lhe respondo.

Editado 24 Outubro, 2019 por Matheus Rodrigo Koch

[EMBarbosa]

17 minutos atrás, Matheus Rodrigo Koch disse:

O problema é que ele não está realizando da mesma forma que era anteriormente a conversão, na verdade este trecho de código deveria estar desta forma:

Realizei esta alteração e ao realizar os teste funcionou normalmente.

Você tem toda a razão. Acabei de enviar uma correção. Revisão 18023.

19 minutos atrás, Matheus Rodrigo Koch disse:

Em relação ao TLeitor.rExtrai é possível realizar o teste com o XML que foi enviado, onde se for utilizado a rotina que temos atualmente no ACBr veremos que a cada loop executado o processo fica mais lento, pois o mesmo precisa apagar cada vez mais texto. Utilizando o que lhe enviei conseguimos guardar a posição do último XML que foi extraído, assim apagamos direto na posição dele para que assim o próximo já seja o que desejamos.

Não sei se fui claro, qualquer coisa pode perguntar aqui que lhe respondo.

Foi claro sim. Mas pra ter certeza que estamos olhando do mesmo ponto de vista, que método você está usando pra testar? ACBrNFSe.LoadFromFile? Ou algo diferente?

[Matheus Rodrigo Koch]

29 minutos atrás, EMBarbosa disse:

Você tem toda a razão. Acabei de enviar uma correção. Revisão 18023.

Foi claro sim. Mas pra ter certeza que estamos olhando do mesmo ponto de vista, que método você está usando pra testar? ACBrNFSe.LoadFromFile? Ou algo diferente?

Realizei o teste e agora está funcionando normalmente e a velocidade de processamento está extremamente rápida também, muito bom.

Em questão ao rExtrai eu utilizo direto o retorno do Web Service para testar, onde utilizo a seguinte rotina:

Acredito que carregando o XML que lhe enviei para um TStringList e atribuindo a propriedade TStringList.Text ao FNotas.Leitor.Arquivo você consiga simular a situação, porém agora não me recordo se é necessário que o XML já tenha passado pela conversão dos caracteres, mas acredito que sim.

[EMBarbosa]

Em 24/10/2019 at 15:51, Matheus Rodrigo Koch disse:

Acredito que carregando o XML que lhe enviei para um TStringList e atribuindo a propriedade TStringList.Text ao FNotas.Leitor.Arquivo você consiga simular a situação, porém agora não me recordo se é necessário que o XML já tenha passado pela conversão dos caracteres, mas acredito que sim.

Olá, Matheus... eu tentei aqui, mas o que ficou lento foi a parte de carregar num TStringList.

A parte do componente, não ficou lento. 

Tentei também dessa maneira, veja:

procedure TForm1.btn1Click(Sender: TObject);
var
  FNr: TRetornoNFSe;
begin
  FNr := TRetornoNFSe.Create;
  try
    Beep;
    FNr.Leitor.CarregarArquivo('D:\Componentes\teste\Retorno.xml');
    FNr.lerxml;
    Beep;
  finally
    FNr.Free;
  end;
end;

 

[Matheus Rodrigo Koch]

Bom dia Elton,

Acredito que ao depurar a rotina TLeitor.rExtrai você irá perceber que no decorrer do processo da extração das notas a rotina vai ficando cada vez mais lenta, pois cada vez mais o loop é repetido. Abaixo segue imagem do loop que estou me referindo:

Podemos identificar que ele utiliza o parâmetro "item" para determinar o fim do meu loop, porém cada vez mais o valor desse parâmetro aumenta e, em casos com muitas notas, o desempenho da rotina se torna lento. No loop ele vai apagando de nota em nota até chegar na nota ao qual o meu parâmetro "item" se refere, utilizando a rotina que lhe enviei ele vai direto a nota em que o parâmetro se refere, poupando assim tempo e principalmente processamento.

[EMBarbosa]

Em 30/10/2019 at 07:55, Matheus Rodrigo Koch disse:

Bom dia Elton,

Acredito que ao depurar a rotina TLeitor.rExtrai você irá perceber que no decorrer do processo da extração das notas a rotina vai ficando cada vez mais lenta, pois cada vez mais o loop é repetido. Abaixo segue imagem do loop que estou me referindo:

 

Podemos identificar que ele utiliza o parâmetro "item" para determinar o fim do meu loop, porém cada vez mais o valor desse parâmetro aumenta e, em casos com muitas notas, o desempenho da rotina se torna lento. No loop ele vai apagando de nota em nota até chegar na nota ao qual o meu parâmetro "item" se refere, utilizando a rotina que lhe enviei ele vai direto a nota em que o parâmetro se refere, poupando assim tempo e principalmente processamento.

Olá Matheus,

   Mais uma vez obrigado por sua disposição e alterações. Boa parte delas já foram adicionadas ao SVN.

   Eu fiquei "debruçado" sobre esse último problema relacionado ao método TLeitor.rExtrai já há algum tempo. Sei que o código atual talvez não seja o mais otimizado, mas ainda não consegui reproduzir o problema.

   Utilizando o xml que você proveu e o exemplo que citei acima, a função TLeitor.rExtrai sempre tem como parâmetro item = 1. Quer dizer que o código é extremamente rápido mesmo sem as alterações. Por outro lado, o seu código realmente parece fazer sentido.

   Essa parte dos componentes é muito delicada porque afeta todos os documentos eletrônicos. Por isso, seria possível prover um exemplo que demonstra realmente o problema? Não precisa ser uma lentidão exagerada. Apenas um passo a passo pra reproduzir o problema com o código atual.

 

[Juliana Tamizou]

Tópico fechado por falta de retorno do usuário