Relatório demorado

Mensagem por **asimoes** » 06 Fev 2018 07:01

Olá Rocinha,

TEMPORARY ADDITIVE faz parte do Harbour 3.2 e 3.4

Poka · Mensagem por **Poka** » 06 Fev 2018 08:24

Olá a todos

Esta semana ainda respondo a todos. Já vi a parte demorada e vou postar a rotina aqui.

Fico muito agradecido em saber que tem tantos colegas querendo resolver os nossos problemas aqui postados.

Obrigado por enquanto.

Poka

dbdc5554 · Mensagem por **dbdc5554** » 07 Fev 2018 15:23

Boa tarde.

deixarei anota aqui antes que Eu esqueça (rs)
uma conclusão que descobri de tornar lento os relatórios ...

EU ao pesquisar produtos la na venda faço:
o nome do produto ou Partes do nome separados por (:) === .or. ou por (;) === .and.

:madeira :90 :roxa localizara todos os produtos que tenham alguma das 3 palavras em qq lugar do nome
;madeira ;90 ;roxa localizara todos os produtos que tenham TODAS as 3 palavras em qq lugar do nome

Ate ai tudo bem.

uma base de dados de 10.000 produtos
eu dou um zap em uma base auxiliar, Varro os 10.000 produtos verificando as condicoes
e.... gravo a base auxiliar e exibo em um browser
1 segundo, 2 no máximo é o tempo de fazer TUDO

Uso isso a muito tempo.

Estou postando aqui agora porque abri outro POST sobre a LENTIDÃO do Win server 2010 2012
REALMENTE eles são BEM + BEM + lentos que o 2003 e 2008 a nível de server
também é MUITO + lento em comparação com o w 7

neste relatório especifico eu crio um índice tipo:

Empresa+filial+nome(o nome vem de um relacionamento coma base de cliente)+dtos(data)

e varria a base usando o índice para fazer o relatório

ao varrer filtrava algumas condições básicas ...
operacao <> [C] skip loop
situacao <> [A] skip loop

no w7 11 minutos para criar o indice e + 14 para processar o relatorio
no 2012 33 para o indice e + 1min 15 para processar o relatorio

fiz o mesmo teste em 3 pc com w server 1012 +_ o mesmo tempo entre eles
basicamente eram 64 Bits 2.8 a 3.1 clock e 4GB e 6GB de memoria

em um w2003 celereon (rs) de 1.0 clock e 2 GB de memoria Obteve o mesmo tempo dos w2012

Para Tentar Melhorar o tempo do relatório MUITO usado resolvi da seguinte forma:

implementei as condicoes operacao <> [C] skip loop situacao <> [A] skip loop
no proprio indice alem da faixa de datas
tudo na clausula FOR

ao executar o relatorio no w7 praticamente INSTANTANEO
idem nos w2012

CONCLUSÃO: Credito que ao colocar TODAS as condicoes na clausula FOR só foram criados POUCOS reg no índice +- umas 5 paginas de registros chutando uns 250 registros

Mesmo que para gerar o índice ele tenha que ter LIDO a base todas MUTO GRANDE por sinal,
o mesmo exemplo la encima que falei com a pesquisa de produtos

o que afeta REALMENTE NÃO é Leitura, e SIM criar íIndice(registros selecionados) e depois Ler a base pelo índice.

Vou ver se ressucito uma função que tinha a uns 15 anos de filtrar a base corrente em um sistema já abandonado

ou então identificar os relatórios + demorados e implementar os índices ou ate mesmo Criar novo inice
quando for gerar o realtorio

Paiva

Mensagem por **JoséQuintas** » 08 Fev 2018 12:33

Só uma coisa que faltou:

Acesso pela rede SEMPRE é mais lento do que local.
A velocidade do HD é de 3 gigabits por segundo, e a da rede, geralmente é 100 megabits por segundo, isso já dá 30 vezes de diferença.
A transferência pela rede é em blocos, quanto mais informação transferir por vez melhor.
Tipo: é mais rápido transferir 3.000 caracteres de uma vez do que 3.000 vezes 1 caractere.
É por isso que SQL é mais rápido, porque transfere tudo de uma vez.
É por isso que DBF é mais lento, transfere UM registro por vez.

Então, mesmo que a rede esteja maravilhosa, DBF em rede vai ser sempre mais lento do que local.

No geral é tentar uma forma de obter o resultado, processando a menor quantidade de registros possível.
SET FILTER não adianta, porque cada registro vai ter que passar pela rede pra ser testado.
SET SCOPE pode ser, porque limita a quantidade de registros.
SEEK, com DO WHILE para uma parte do arquivo também evita passar por todos os registros.

Resumindo: filtrar a quantidade de registros acessados, mas não serve SET FILTER.
Se é referente a um intervalo de datas, ter um índice previamente criado por data, e usar somente o intervalo de datas necessário.

USEM O SQL COMO BASE.
O que acontece no SQL? é feito o filtro, e depois é criado o índice com o resultado.
O demorado não é colocar em ordem, mas sim pegar a informação necessária.
O ponto chave pra deixar rápido é justamente agilizar a parte de "pegar" a informação necessária.
Colocar em ordem é o de menos, dá pra fazer isso num arquivo local/temporário.

Poka · Mensagem por **Poka** » 12 Fev 2018 13:48

Olá a todos

Utilizo

harbour 3.2 dev(r1510132105)
minigui extend 2.5.4.2015.10.21
DBF CDX

Sygecom disse

Faz o seguinte, melhora o filtro, testa e posta aqui pra dizer se deu certo.

se esta referindo ao set filter, nunca uso.

Itamar disse

é rede mapeada ? etc...

Sim , rede normal

Jose Quintas disse

Deve ser DBF,,,,
- Criar índices pra agilizar
- usar hbnetio e processar relatório no servidor
- processar relatório no servidor
- deixar relatórios prontos a noite
- etc.

sim dbf, estou mudando para firebird.

Rochinha disse

Isso é problema de rede. E se for WIFI piora.
Dica: Se placas de rede, roteadores e hubs forem de mesma marca melhor ainda.

acho que vc tem razão, só´pode ser isso. Precisava testar com Switch / 1000, mas nao tenho.

Asimoes disse

Tenta ver se a configuração da placa de rede tá Full ou half duplex, ou seja uma rede que é 100 MB é placa tá trabalhando como 10 Mbps

Alterei, não melhorou nada.

Nascimento disse

vc usa dbf temporarias? para gerar esse relatório??
ou é direto da dbf?

sempre usei temporário em todos os relatórios.

Rochinha disse

Quando vi que doideira seria trocar meus Set Filters sofisticados quase parei. Mas como já vinha usando o OrdScope() a contendo em meus aplicativos DOS pensei:

sempre que dá , uso sim.

dbdc5554 disse

EU ao pesquisar produtos la na venda faço:
o nome do produto ou Partes do nome separados por (:) === .or. ou por (;) === .and.

nesse caso vou pelo código direto ja indexado com esse campo

José Quintas disse

Acesso pela rede SEMPRE é mais lento do que local.

com certeza, mas de instantâneo para 2 minutos e meio????

José Quintas disse

USEM O SQL COMO BASE.

já fiz um teste aqui com Firebird filtrando "Silva" por exemplo em um milhão de registro.
no terminal é exatamente igual. achei muito bom. na minha rede isso demorou 15 segundos, mas em um cliente 4 segundos. achei ótimo.
no meu sistema sempre separo os arquivos de de contas a receber, a pagar por letra inicial do cliente/fornecedor. sempre vou no arquivo direto. sempre vai ter menos registros.

testando no terminal
dei uma acertada nas rotinas , diminuiu pra dois minutos e meio. No computador que está instalado o sistema é praticamente instantâneo.
relatório de faturamento do mes 12/2017 , nem são tantos registros assim

aqui já criei o dbf temporario tempofat.dbf onde demora 27 segundos
tudo bem , vamos para a próxima rotina

na rotina abaixo demora um minuto e vinte segundos

Código: Selecionar todos

tempofat->(dbgotop())
do while  ! tempofat->(eof()) 
   *--------------calculo o valor do documento
   *------------------------------------------
   vvlCusto:=fcustoDocum(vdocum,vnfci)    // a demora no terminal esta aqui
   *---------------------------------
   tempofat->(dbskip())
enddo

Código: Selecionar todos

FUNC fcustoDocum(Xdocum,xnfci)
   // calcula o custo total do documento, produto por produto
   local xarq, xcustoProd:=0,xcustoDoc:=0 , xabre:=.f.  , mx:={}
   if ! xnfci $ "NF-CI"
      MSGSTOP("erro na funcao fcustodocum, consulte a assitencia")
      retu xcustodoc    // retorno 0 mesmo
   endif
  
   if xnfci="NF"
      xarq:="notam"
   else
      xarq:="notam_ci"
   endif   
   (xarq)->(dbsetorder(1))
   (xarq)->(dbseek(xdocum))
   do while (xarq)->docum = xdocum .and. ! (xarq)->(eof())
		   
      if custo_fixa_doc->(dbseek(  (xarq)->docum  + xnfci+ (xarq)->codprod ))
         // verifico se tem nao arquivo que fixa o custo
	 // tirando este teste aqui cai para  1 minuto e meio
	 // aqui eu testo se no arquivo custo_fixa_doc se o ussuario digitou o produto que não é para mudar o custo.
        // quando  nao existe custo por exemplo.
        xcustoDoc+=custo_fixa_doc->vlcusto* (xarq)->qtd
     else
  	xcustoprod:=fcustoProdx( (xarq)->codprod,(xarq)->emissao)
        xcustoDoc+=xcustoprod* (xarq)->qtd
    endif   
   (xarq)->(dbskip())
enddo   
retu (xcustodoc)

FUNC fcustoProdx(XCOD,xdata)
/*
arquivo produto_prVenda.dbf está na ordem de codigo + data + hora, minuto e seg
neste arquivo são registrados os preços de custo manualmente pelo usuario.
*/
local xcodEncontrado,xCustoEncontrado, xcodAnterior,xCustoAnterior
produto_prVenda->(dbseek(xcod+dtos(xdata+1),.t.))
//
xcodEncontrado:=produto_prVenda->codigo // para testar se anterior não for o pesquisado
xCustoEncontrado:=produto_prVenda->pr_custo
//
produto_prVenda->(dbskip(-1))
xcodAnterior:=produto_prVenda->codigo
xCustoAnterior:=produto_prVenda->pr_custo
//
if xcodAnterior= xcod // o codigo anterior é = o pesquisado , estou no ultimo é o correto
xcusto:=xcustoAnterior
elseif xcodEncontrado = xcod // é o encontrado, mesmo que nao seja a data utilizo este, para nao ficar sem custo
xcusto:=xcustoEncontrado
else
xcusto:=0 // nenhum custo encontrado
endif

retu (xcusto)

Poka · Mensagem por **Poka** » 12 Fev 2018 13:48

Olá a todos

Utilizo

harbour 3.2 dev(r1510132105)
minigui extend 2.5.4.2015.10.21
DBF CDX

Sygecom disse

Faz o seguinte, melhora o filtro, testa e posta aqui pra dizer se deu certo.

se esta referindo ao set filter, nunca uso.

Itamar disse

é rede mapeada ? etc...

Sim , rede normal

Jose Quintas disse

Deve ser DBF,,,,
- Criar índices pra agilizar
- usar hbnetio e processar relatório no servidor
- processar relatório no servidor
- deixar relatórios prontos a noite
- etc.

sim dbf, estou mudando para firebird.

Rochinha disse

Isso é problema de rede. E se for WIFI piora.
Dica: Se placas de rede, roteadores e hubs forem de mesma marca melhor ainda.

acho que vc tem razão, só´pode ser isso. Precisava testar com Switch / 1000, mas nao tenho.

Asimoes disse

Tenta ver se a configuração da placa de rede tá Full ou half duplex, ou seja uma rede que é 100 MB é placa tá trabalhando como 10 Mbps

Alterei, não melhorou nada.

Nascimento disse

vc usa dbf temporarias? para gerar esse relatório??
ou é direto da dbf?

sempre usei temporário em todos os relatórios.

Rochinha disse

Quando vi que doideira seria trocar meus Set Filters sofisticados quase parei. Mas como já vinha usando o OrdScope() a contendo em meus aplicativos DOS pensei:

sempre que dá , uso sim.

dbdc5554 disse

EU ao pesquisar produtos la na venda faço:
o nome do produto ou Partes do nome separados por (:) === .or. ou por (;) === .and.

nesse caso vou pelo código direto ja indexado com esse campo

José Quintas disse

Acesso pela rede SEMPRE é mais lento do que local.

com certeza, mas de instantâneo para 2 minutos e meio????

José Quintas disse

USEM O SQL COMO BASE.

já fiz um teste aqui com Firebird filtrando "Silva" por exemplo em um milhão de registro.
no terminal é exatamente igual. achei muito bom. na minha rede isso demorou 15 segundos, mas em um cliente 4 segundos. achei ótimo.
no meu sistema sempre separo os arquivos de de contas a receber, a pagar por letra inicial do cliente/fornecedor. sempre vou no arquivo direto. sempre vai ter menos registros.

testando no terminal
dei uma acertada nas rotinas , diminuiu pra dois minutos e meio. No computador que está instalado o sistema é praticamente instantâneo.
relatório de faturamento do mes 12/2017 , nem são tantos registros assim

aqui já criei o dbf temporario tempofat.dbf onde demora 27 segundos
tudo bem , vamos para a próxima rotina

na rotina abaixo demora um minuto e vinte segundos

Código: Selecionar todos

tempofat->(dbgotop())
do while  ! tempofat->(eof()) 
   *--------------calculo o valor do documento
   *------------------------------------------
   vvlCusto:=fcustoDocum(vdocum,vnfci)    // a demora no terminal esta aqui
   *---------------------------------
   tempofat->(dbskip())
enddo

Código: Selecionar todos

FUNC fcustoDocum(Xdocum,xnfci)
   // calcula o custo total do documento, produto por produto
   local xarq, xcustoProd:=0,xcustoDoc:=0 , xabre:=.f.  , mx:={}
   if ! xnfci $ "NF-CI"
      MSGSTOP("erro na funcao fcustodocum, consulte a assitencia")
      retu xcustodoc    // retorno 0 mesmo
   endif
  
   if xnfci="NF"
      xarq:="notam"
   else
      xarq:="notam_ci"
   endif   
   (xarq)->(dbsetorder(1))
   (xarq)->(dbseek(xdocum))
   do while (xarq)->docum = xdocum .and. ! (xarq)->(eof())
		   
      if custo_fixa_doc->(dbseek(  (xarq)->docum  + xnfci+ (xarq)->codprod ))
         // verifico se tem nao arquivo que fixa o custo
	 // tirando este teste aqui cai para  1 minuto e meio
	 // aqui eu testo se no arquivo custo_fixa_doc se o ussuario digitou o produto que não é para mudar o custo.
        // quando  nao existe custo por exemplo.
        xcustoDoc+=custo_fixa_doc->vlcusto* (xarq)->qtd
     else
  	xcustoprod:=fcustoProdx( (xarq)->codprod,(xarq)->emissao)
        xcustoDoc+=xcustoprod* (xarq)->qtd
    endif   
   (xarq)->(dbskip())
enddo   
retu (xcustodoc)

FUNC fcustoProdx(XCOD,xdata)
/*
arquivo produto_prVenda.dbf está na ordem de codigo + data + hora, minuto e seg
neste arquivo são registrados os preços de custo manualmente pelo usuario.
*/
local xcodEncontrado,xCustoEncontrado, xcodAnterior,xCustoAnterior
produto_prVenda->(dbseek(xcod+dtos(xdata+1),.t.))
//
xcodEncontrado:=produto_prVenda->codigo // para testar se anterior não for o pesquisado
xCustoEncontrado:=produto_prVenda->pr_custo
//
produto_prVenda->(dbskip(-1))
xcodAnterior:=produto_prVenda->codigo
xCustoAnterior:=produto_prVenda->pr_custo
//
if xcodAnterior= xcod // o codigo anterior é = o pesquisado , estou no ultimo é o correto
xcusto:=xcustoAnterior
elseif xcodEncontrado = xcod // é o encontrado, mesmo que nao seja a data utilizo este, para nao ficar sem custo
xcusto:=xcustoEncontrado
else
xcusto:=0 // nenhum custo encontrado
endif

retu (xcusto)

Poka · Mensagem por **Poka** » 12 Fev 2018 13:52

corrigindo a ultima parte

Código: Selecionar todos

FUNC fcustoProdx(XCOD,xdata) 
   /*
   arquivo produto_prVenda.dbf está na ordem de codigo + data + hora, minuto e seg
   neste arquivo são registrados os preços de custo manualmente pelo usuario. 
   */
   local xcodEncontrado,xCustoEncontrado, xcodAnterior,xCustoAnterior
   produto_prVenda->(dbseek(xcod+dtos(xdata+1),.t.))
   //  
   xcodEncontrado:=produto_prVenda->codigo // para testar se anterior não for o pesquisado
   xCustoEncontrado:=produto_prVenda->pr_custo
   //
   produto_prVenda->(dbskip(-1))
   xcodAnterior:=produto_prVenda->codigo 
   xCustoAnterior:=produto_prVenda->pr_custo
   //
   if xcodAnterior= xcod // o codigo anterior é = o pesquisado , estou no ultimo é o correto
      xcusto:=xcustoAnterior 
      elseif xcodEncontrado = xcod // é o encontrado, mesmo que nao seja a data utilizo este, para nao ficar sem custo 
      xcusto:=xcustoEncontrado
   else
      xcusto:=0 // nenhum custo encontrado
   endif	

retu (xcusto)

Poka

Mensagem por **rubens** » 12 Fev 2018 17:09

Poka...

Essa dança é antiga... e não vi nada que resolva... diretamente no harbour..
Eu uso uma rotina de visualização de orçamentos onde criei um índice com filtro. Mesmo que tenha 20, 30 registros em determinado momento um browse simples fica quase impossível na rede mapeada, principalmente se tiver registros deletados. Na máquina local instantâneo..
O que resolveu... Usar server 2008 com TS.
Venho sempre questionando aqui para quem usa "NetIo", LetoDB e Sql, se a velocidade é comparada ao TS.. a resposta teste...
Removi o Filtro da indexação melhorou, ficou trabalhável... mas mesmo assim lento.

Meios físicos? Hub, Switch, roteadores, Lan ou Gigalan pelos menos aqui não fizeram muita diferença. Lógico que um Switch gigalan e todas as placas gigalan, fazem diferença, mas nem tanto. Pelo menos foi a minha experiência. Sugeria para o cliente trocar e mesmo assim continuou lento... enquanto não fomos para um "Servidor" mesmo (servidor, não máquina comum com windows server) não resolveu o problema...
A última mudança que fiz aqui ainda foi em um terminal que gera NFCe pelo ACBR criar um gerenciador de NFCes, só para isso... e o programa acessa via TS.

acompanhando tópico para ver se surge uma solução que provavelmente não vai ter..

Rubens

Mensagem por **JoséQuintas** » 12 Fev 2018 19:52

Se fosse GTWVG, indicaria pra acrescentar um Inkey() dentro dos DO WHILE.
Se o processo for muito rápido, não dá tempo do Windows fazer a parte que precisa.

Como não é, talvez DO EVENTS ou algo assim.

Parece piada, mas até no Clipper tinha esse problema: se não deixar o Windows trabalhar, dava até erro de rede.

Por acaso a tela do relatório chega a congelar?

Nascimento · Mensagem por **Nascimento** » 13 Fev 2018 20:13

já pensou em modificar de dbf temporária
para usar vetores?
eu usava muito dbf temporárias, mais após passar a usar vetor ,
achei muito melhor
lembrando que vc pode ordenar um vetor como fazemos nos índices...

Mensagem por **asimoes** » 14 Fev 2018 10:23

Eu tentaria o uso do events como o Quintas mencionou, já tive esses problemas de lentidão no processamento e foram resolvidos com hwg_doevents

Pode testar o código abaixo que faz o "do events" função hrb_doevents ou o nome que quiser dar.
Observação tentar colocar a função hrb_doevents onde você diz a "demora no terminal esta aqui" se tem dbskip lá coloca a função após cada skip

Código: Selecionar todos

tempofat->(dbgotop())
do while  ! tempofat->(eof()) 
   *--------------calculo o valor do documento
   *------------------------------------------
   vvlCusto:=fcustoDocum(vdocum,vnfci)    // a demora no terminal esta aqui
   *---------------------------------
   tempofat->(dbskip())
   Hrb_DoEvents() //<<======
enddo

Código: Selecionar todos

#pragma BEGINDUMP

#include "windows.h"

#include "hbapi.h"

#include "olectl.h"

#include "time.h"

HB_FUNC( HRB_DOEVENTS )
{
   MSG Msg;

   while( PeekMessage( ( LPMSG ) &Msg, 0, 0, 0, PM_REMOVE ) )
   {
      TranslateMessage( &Msg );
      DispatchMessage( &Msg );
   }
}

#pragma ENDDUMP

Poka · Mensagem por **Poka** » 15 Fev 2018 14:05

Olá a todos

Com alguns acertos, no cliente está demorando 1 minuto e 10 seg. já melhorou bastante.

Rubens disse

Essa dança é antiga... e não vi nada que resolva... diretamente no harbour..

Também acho. em outro cliente os relatórios não demoram, mas lá a rede é outra.

Quintas disse

Se fosse GTWVG, indicaria pra acrescentar um Inkey() dentro dos DO WHILE.
Se o processo for muito rápido, não dá tempo do Windows fazer a parte que precisa.
Como não é, talvez DO EVENTS ou algo assim.
Por acaso a tela do relatório chega a congelar?

Pesquisando a semana passada aqui mesmo no forum, até tente usar DEFINE TIMER mas não resolveu.

Nascimento disse

já pensou em modificar de dbf temporária
para usar vetores?

estou mudando para Firebird. Não estou mais nem atualizando sistema para não perder muito tempo.

Asimoes disse

Eu tentaria o uso do events como o Quintas mencionou, já tive esses problemas de lentidão no processamento e foram resolvidos com hwg_doevents

Vou testar sim depois reporto aqui.

Obrigado

Poka

Mensagem por **Itamar M. Lins Jr.** » 16 Fev 2018 17:07

Ola!

Venho sempre questionando aqui para quem usa "NetIo", LetoDB e Sql, se a velocidade é comparada ao TS.. a resposta teste...

No TS tem opções de configuração das cores 24,16 etc..
Então até o TS pode ficar lento dependendo da conexão, mas acredito e nos teste que fiz o TS é sempre mais rápido.
Eu uso LETODBF independente do TS posso usar ou não o TS eu não abro mão é do LETODBF.
Em uma rede local o LETODBF roda igual ao TS. Já usando uma rede WAN fica mais lento, mas eu preciso do LetoDbf mesmo assim, pois como vc faz para JUNTAR os dados de 7 filiais ? como vc consulta produto em 2,3,4,5... filiais com o TS em um relatório ?
O Poka se bem souber instala o LetoDbf ai e vai ser só alegria nunca mais vai se preocupar com lentidão no DBF.

Saudações,
Itamar M. Lins Jr.

Poka · Mensagem por **Poka** » 17 Fev 2018 11:26

Olá

O Poka se bem souber instala o LetoDbf ai e vai ser só alegria nunca mais vai se preocupar com lentidão no DBF.

Obrigado Itamar por responder.
Algum tempo atrás tentei usar o Netio. Ficou + lento ainda, então acabei desistindo. O tempo passou e estou a algum tempo mexendo com Firebird.
Dentro de pouco tempo quero ver se passo tudo pra Firebird. DBF vou deixar mesmo de usar. Foi maravilhoso , mas como tem que mudar, então escolhi o Firebird.
Já tenho todas as funções de gravação, alteração tudo como tinha em dbf, então falta os selects da vida para extração de dados para os relatório + complicados. Conforme for aparecendo as dificuldades vou pedindo ajuda aqui no forum.

Obrigado, um abraço.

Poka

portelainfo · Mensagem por **portelainfo** » 30 Set 2019 01:55

Boa madrugada a todos!

Alguem aqui sabe como compilar a subntx no harbour?