Analisando lentidão ao trocar de campo no cadastro de Produtos

Se você tem lentidão ao alterar um Produto no Protheus, saiba o que pode ser que esteja impactando.

Obs.: O artigo abaixo pode ser específico da base de um cliente, decidi compartilhar, pois se outros também tiverem problema, saberemos que não é algo único dessa base

Recentemente, vi uma situação estranha, e que até agora fiquei encafifado rs. Um usuário estava reclamando, que no cadastro de produtos, ao digitar a informação em um campo, e trocar de campo com Tab, Enter ou clicar com o mouse, o sistema dava um pequeno delay para poder digitar a informação.

Então eu vi a situação, e basicamente assim, o usuário clicava em um campo e digitava uma palavra, e ao dar o tab, mesmo se o usuário começasse a digitar, o “set focus” no get, dava um pequeno engasgo, e depois até aparecia o texto que o usuário estava digitando.

Começamos a realizar vários testes, e até abrimos um chamado na TOTVS.

Abaixo o que testamos:

  1. Testamos em máquinas diferentes e com usuários diferentes
  2. Testamos na versão 12.1.25 e 12.1.27
  3. Tiramos todos os X3_WHEN no cadastro de Produtos
  4. Testamos em outras telas, e só ocorre na MATA010 (Produtos)
  5. Efetuado testes com IXBLOG=LOGRUN
  6. Efetuado testes com IXBLOG=NORUN
  7. Teste feito aplicando o acumulado do estoque
  8. Testado com dicionário SX3 (campos) novo sem campos customizados
  9. Testado com dicionário SX7 (gatilhos) novo sem campos customizados
  10. Teste realizado atualizando LIB, Binários e DBAccess
  11. Efetuado backup da SB1, Drop Table e depois o Append do Backup
  12. Análise de LogProfiler ativo no AppServer
  13. Efetuado testes removendo todo o profile de usuários
  14. Efetuado testes na MATA010 em outros módulos sem ser o Compras (como Faturamento e Estoque)
  15. Começamos a efetuar testes no pesquisar e filtrar dentro da MATA010

Depois do teste de número 10, descobrimos o que estava causando a lentidão (irei detalhar abaixo), e depois do teste 13, descobrimos como que é “disparado” essa lentidão pelo sistema.

Então, basicamente o que descobrimos:

* Esse delay ocorre, pois ele tenta filtrar via DbAccess registros excluídos (ao alternar de campo) e como a base é grande (cerca de 18 mil registros), ele dá um engasgo. Abaixo o que ele executa no DbAccess:

— Set Driver Deleted Filter OFF

— Set Driver Deleted Filter ON

* O problema ocorre, quando efetuamos o seguinte procedimento:

1) Estamos usando o índice 1 (Filial + Código do Produto)

2) Quando Filtramos ou Pesquisamos algum produto (por exemplo, código 000XYZ)

3) Logo em seguida clicamos em alterar nesse mesmo produto pesquisado

Ou seja, é uma situação inusitada (parece aqueles códigos de Street Fighter para abrir o Akuma rs).

As possíveis soluções para o caso são usuário utilizar outro índice para fazer a busca (como por exemplo a descrição do produto) e se realmente for um erro padrão, a TOTVS corrigir em futuras builds.

Link que encontramos relatando algo similar:

https://tdn.totvs.com/pages/viewpage.action?pageId=381051712

Bom pessoal, por hoje é só.

Abraços e até a próxima.

Dan Atilio (Daniel Atilio)
Especialista em Engenharia de Software pela FIB. Entusiasta de soluções Open Source. E blogueiro nas horas vagas.

6 Responses

  1. George Allan disse:

    Que surra levastes hein Atílio?

    Valeu aí pela análise, e por compartilhar.

  2. Caique disse:

    Já vi isso em algum lugar !!! kkk

  3. Lucimar dos Santos disse:

    Se der um DELETE FROM SB1010 WHERE D_E_L_E_T_ ‘*’ então resolve né.

    • Dan_Atilio disse:

      Então Lucimar, pensamos nisso, mas nesse cliente, eles não excluem produtos, apenas bloqueiam.
      Então seria o mesmo que abrir uma tabela no apsdu, e ficar clicando no set deleted on/off, mesmo que não tenha registros apagados, ele vai dar aquele refresh na table
      Mesmo assim obrigado pelo palpite
      Grande abraço

Deixe uma resposta