Lentidão ao abrir formulários em rede.

[Mario Mesquita]

Bom dia, pessoal.

Alguns clientes andam reclamando de lentidão em partes do sistema e isso se dá quando tentam abrir algumas telas enquanto tem outra aberta em outra máquina da rede. Fui testar isso e de fato aconteceram com algumas de demorar 30, 40 segundos pra abrir uma determinada tela. Rastreando, vi que isso ocorre no 'Load Window' e no método 'Activate' do form. Cada um demora um pouco. Até pensei que seria abertura de tabelas de dados mas isso está normal.

Já tentei usar aquele 'DO EVENTS' pra ver se melhora isso e tentando ver se tem alguma coisa que se possa fazer para minimizar esse delay. A minha impressão é que isso se deve à quantidade de coisas que uso nessa tela em especial: dois grids e vários elementos para configurar a operação que ela se propõe. Será que tem a ver?

Alguém já passou por isso? Se sim, resolve como? Uso a HMG clássica, só pra lembrar. Ou pode ser algo do Windows, já que usa a API dele pra isso?

Desde já, agradeço qualquer dica.

Saudações,
Mario.

[JoséQuintas]

provavelmente tabelas.
Diria que está usando NTX ao invés de CDX.
Também a possibilidade de estar usando algum SET FILTER ou algo parecido.

Mencionou 2 grids, isso significa acessando arquivo.

Agora tem uma cobaia legal: O SIMULADOR

Ele abre um único registro, e depois permite fazer o grid/browse.
Vai poder confirmar se tem a ver com o grid/browse.

[Mario Mesquita]

Boa tarde/noite a todos.

Quintas, eu acredito não ser dados. Uso CDX, não uso SET FILTER pq em rede é um veneno. O máximo que uso é SET RELATION e muito pouco.

Eu faço um debug tosco com o MsgInfo(), marcando pontos do programa pra inspecionar alguma coisa. Eu abro as tabelas antes de carregar o formulário e essa parte foi bem. Na hora do Load Form, o programa para por segundos. Aí ele retorna e no Activate demora mais segundos. Eu tenho um reloginho no form principal e ele congela nesses momentos... o ruim é que o usuário deve clicar achando que vai acelerar a coisa e aí trava mesmo.. Os Grids eu carrego em tempo de execução, não faço como um TBrowse, direto na tabela. Pra isso uso alguns Browse da HMG e achava que ele estava causando isso mas não é o que parece. E repara, se não estiver tela aberta em outro computador, só no form principal, funciona normal. Mas se tem uma tela aberta e outro computador abre alguma coisa, já degrada a performance. Não são em todas, e por quê isso não faço ideia.

Pode ser algo no ambiente? Estou testando com dois notes com Windows 10, coisa bem mortadela mesmo...

Saudações,
Mario.

[Itamar M. Lins Jr.]

Olá!
Em quanto não usa LetoDbf, um PACK pode ajudar.
Quando um DBF tem muitos registros deletados ele fica muito lento, até com LetoDbf.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Lembrei de outra coisa:

WARSAW
Antivírus
programa não assinado.

Isso aconteceu comigo, sei lá, talvez há mais de 10 anos atrás.
Foi a partir daí que passei a usar certificado.
Mas isso seria num terminal, e não em todos, ou no servidor talvez, se estiver nele o troço.

Também MANIFEST.
Sem manifest definindo pra rodar com os direitos do usuário, a segurança pode considerar perigoso por precisar rodar como administrador.

Lembro até de um detalhe curioso:
MULTITHREAD.
Meu aplicativo fazia toda a checagem de estruturas, índices, etc. e só depois o antivírus dava o alerta e segurava o aplicativo.
NÃO SEI se os antivírus continuam assim.

O que tem a ver ?
API Windows.
Se o programa acessa API Windows pode controlar tudo, é simples assim.

Que tal um FindWindow() pra procurar uma janela aberta, e o SendKey() pra teclar algo, ou coisa parecida em qualquer janela...

[Mario Mesquita]

Bom dia a todos.

Quintas, quanta coisa a se considerar... mas sinto que pode ser outra coisa. O sistema no form principal em mais de uma máquina e um só abrindo algo tudo funciona normal. Só acontece se outro tentar fazer alguma coisa com outro fazendo algo também. Aí arrasta, fica lento. Se fosse algo como sugeriu aconteceria direto, mesmo com um só usando, penso eu.

Se o sistema estiver no form principal na "máquina 1", o operador na "máquina 2" trabalha normalmente. Ou vice-versa. Se a "máquina 1" abrir algo pra trabalhar junto com outra, aí começa a coisa.

Eu tentei também rodar o .exe a partir da "máquina 2" pra ver se normalizava, sendo que ele só acessa as tabelas via SET PATH na "máquina 1". Mas nada mudou. Como pode? Se fosse algo de memória ou algo assim ao rodar dois programas em máquinas diferentes, não aconteceria em tese. Mas acontece.

Ora, então não daria pra construir uma aplicação tipo PDV com isso? Imagina os caixas com fila e os operadores revezando pra fazer uma venda? Então é uma limitação da ferramenta? Nem no velho Clipper eu tive isso, lembro que fazíamos aquele "overlay dinâmico" e separava o .exe em partes mesmo sendo um arquivo só.

Fico pensando se em outras IDEs, RADs, etc isso acontece. A minha sorte é que o sistema não tem alta demanda de rede, é um programa administrativo e atendo clientes de pequeno porte. Mesmo assim já ouvi críticas. Já tentei umas coisas como declarar o form, abrir sem as tabelas, etc mas com pouco efeito.

Complicado, quando reclamavam disso, achava que era algo na rede do cliente, muitos programas abertos no computador, etc. Mas vejo que é algo do lado de cá.

Se alguém já passou por isso e puder relatar essa experiência, se resolveu ou conseguiu um "quebra galho", aceito qualquer dica. Ficando sem opções.

Saudações,
Mario.

[JoséQuintas]

Precisa analisar.
Com certeza não é normal, mas fica difícil adivinhar.
O servidor é dedicado ou usa o aplicativo nele?
De repente faz lock forçado ou algo assim, aí não tem rede que resolva.
Pode ser qualquer coisa, vai precisar tentar isolar o problema.

[Mario Mesquita]

Olá de novo.

Quintas, verdade. É reavaliar todo o processo e tentar resolver gargalos. Uma pequena vitória: na tela que escolhi para avaliar e resolver isso
tinha um ComboBox ligado direto a uma tabela. Para fazer um filtro na operação que vai ser realizada. Isso estava causando a lentidão no "Load Form" e no método "Activate". Botava a referência ao DBF na propriedade "ItemSource". Então isso resolveu. Mas agora tem outra lentidão ao fazer uma busca que enche os Grids, percorrendo a tabela principal. Na mesma situação, com alguma janela aberta em outro terminal.

Aí dá uma preocupada de ser algo inerente aos DBFs. Mas creio que possa ser algo específico, talvez ligado aos Grids mesmo. Só com mais testes.

Sobre sua pergunta de redes, aqui estou testando com dois notebooks em rede, bem feijão com arroz. Mas ocorre em servidores dedicados com Windows Server, super bem montados. Creio ser mesmo em partes do programa que precisam de testes e possíveis ajustes pra minimizar essas lentidões. Como fiz esse programa há mais de 10 anos e ainda no tempo do Windows 95 pode ser que de lá pra cá isso se acentuou à medida que as
redes ficam mais complexas e com segurança reforçada, aquela parafernália que vão criando pra "melhorar" as coisas.

O jeito vai ser fuçar e ver se dá pra deixar melhor. Já deu uma melhorada de certa forma. Estou centrando numa rotina só que é aparentemente uma das mais críticas nesse aspecto. Resolvendo essa, posso catar coisas semelhantes nas outras e ajustar.

Vou reportando por aqui, pode ser útil pra alguém no futuro, né?

Saudações,
Mario.

[RamonXHB]

Boa tarde, Mário.
Vc carrega os grids com eles ativos ?
Se sim, pode experimentar desabilitar durante a carga, e reabilitar após terminar de carregar.

[Mario Mesquita]

Olá, Ramon.

Então, ao chamar o módulo, eu carrego com o Load Form, faço alguma inicialização e dou o Activate. Como seria isso? Porquê sem ativar, o form não abre. Li que daria pra ativar e usar o método Show. Mas ao dar Activate ele já abre, então o Show fica sem sentido. Ou estou falando uma grande bobagem? rs. Eu fiz testes de ativação sem encher os grids e parece tudo normal. Talvez não sejam problemáticos como o combobox atrelado ao DBF explicado acima.

Se puder detalhar, agradeço.

Abraço,
Mario.

[Itamar M. Lins Jr.]

Olá!

Se alguém já passou por isso e puder relatar essa experiência, se resolveu ou conseguiu um "quebra galho", aceito qualquer dica. Ficando sem opções.

Não sei se foi com vc ou talvez outra pessoa, que eu avisei que com o passar do tempo e aumentando os registros do DBF vai dar problema com rede mapeada.
A solução é usar LetDBf ou servidor via TS.
Cada registro acrescentado, a rede o CPU(win10) tende a ficar lento mesmo.
Eu trabalho com DBF há mais de 30 anos. Ontem troquei um servidor com SSD(inclusive) com o passar do tempo as NFCe xml, mais registros de vendas cerca de 1500 por mês nesse cliente, até o Win10 não suporta gerenciar acima de uma quantidade X de ARQUIVOS, não é nem falha do DBF é a quantidade enorme de arquivos na tabela(NTFS) e o windows começa a falhar. Solução é apagar os arquivos (lógico) depois de fazer backup para outro.
Desligar processos segundo plano, desligar tudo que puder do servidor, mudar HUB para giga(de 100 para 1000) e o que mais puder.

Saudações,
Itamar M. Lins Jr.

[RamonXHB]

Boa tarde, Mário.

Como você está fazendo a carga dos dados no grid ?

Eu faço assim:

Form_CxMovCaixa.Grid_CxMovCaixa.DisableUpdate -> Desabilita o Grid
DELETE ITEM ALL FROM Grid_CxMovCaixa OF Form_CxMovCaixa -> Limpa os dados, se houver

Aqui vai a rotina que carrega o Grid

Form_CxMovCaixa.Grid_CxMovCaixa.EnableUpdate - Habilita o Grid, já carregado.

Um detalhe, eu não uso o loadform, pois minhas telas estão dentro do prg, diferente do seu modo de programar.

Outro detalhe, eu não uso dbf, uso bancos de dados SQL.

Espero ter ajudado.

[Mario Mesquita]

Bom dia pessoal.

Itamar, entendi. Algo inerente ao Windows lidar com tabelas muito grandes e com muitas abertas, né? DBF é isso aí. A meu favor é que minhas tabelas não tem
muitos registros, a maior delas em cliente com mais registros bate na casa dos 200 mil. Para dados é de pequeno porte, né? A ideia é ir pro SQL mas é um
processo lento, quando temos que manter o que se tem funcionando e migrar gradualmente, ainda tendo que dominar o mínimo de SQL pra administrar a BD. Por
hora é que tenho...

Ramon, imagino que tendo o controle do form no programa seja mais flexível, mas com o Load Form do HMG isso fica limitado e mudar isso a essa altura fica complicado.
Vou ter que ir revisando e ajustando onde for necessário.

Mas consegui minimizar bastante fazendo ajustes nas rotinas de leitura das tabelas de dados. Ao invés de encher os grids diretamente eu joguei os resultados para
vetores e aproveitei pra otimizar a leitura das tabelas pra evitar repetir buscas fazendo uma espécie de recordset Tabajara já que não tenho SQL, rsrs

Ficou bem aceitável agora e depois vou fazer isso em alguns pontos que estão com essa perfomance ruim. O curioso é a discrepância entre o uso "exclusivo" das
tabelas e em rede sendo que não necessariamente lendo dados, só o fato de ter forms abertos e apontando para uma tabela. Vivendo e aprendendo...

Agradeço as dicas e se alguém mais teve algo parecido e quiser reportar, sempre ajuda a comunidade com problemas semelhantes.

Saudações e boa semana a todos,
Mario.

[paiva]

uso TS ou emulador dele em TODOS os clientes

+++ se os PC forem BONS e com MUITA memoria em rede ate fica bem rápido
e tem que ter Placas de redes melhores

o + facil é usar o TS ou multi-usuarios (ate o w7 ) é tranquilo no 10 e 11 eles estao tentando Bloquear isso

PAiva

[Itamar M. Lins Jr.]

Olá!

ainda tendo que dominar o mínimo de SQL pra administrar a BD

Usando LetoDBf vc não precisa aprender SQL e terá a mesma performance, talvez até melhor.

Saudações,
Itamar M. Lins Jr.