Ir para conteúdo
  • Cadastre-se

dev botao

TFDQuery.Append Lento


Ver Solução Respondido por matheusguerra,
  • Este tópico foi criado há 2262 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Append lento. TFDQuery ao aplicar valor em um field com SGDB na nuvem, consome 144 milésimos de segundos, alterando a property TFDQuery.AutoCalcFields para false, esse tempo chega a 071 milésimos de segundos. Usando o SGDB na rede local, o tempo fica 004 milésimos de segundos. Exemplo: qry.Append; qryCODITEM.AsInteger := 1; //Aqui fica lento com o SGDB na nuvem.

Acredito que o firedac vai até o SGDB a cada alteração do field. Aguêm já teve cenário igual? Tem como melhorar?

Link para o comentário
Compartilhar em outros sites

  • Consultores

O "Append" carrega outros registros para apenas depois fazer a inserção no final do TDataSet.

Se o problema for esse e você usar o "insert", possivelmente será mais rápido.

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link para o comentário
Compartilhar em outros sites

  • Moderadores

Como assim na nuvem?

tu não colocou seu banco na internet e está acessando diretamente ele?

imagine o quanto de banda de internet vai comer seu sistema e na maioria paga por trafego de dados.

Consultor SAC ACBr Juliomar Marchetti
 

Projeto ACBr

skype: juliomar
telegram: juliomar
e-mail: [email protected]
http://www.juliomarmarchetti.com.br
MVP_NewLogo_100x100_Black-02.png
 

 

Link para o comentário
Compartilhar em outros sites

1 hora atrás, EMBarbosa disse:

O "Append" carrega outros registros para apenas depois fazer a inserção no final do TDataSet.

Se o problema for esse e você usar o "insert", possivelmente será mais rápido.

Com insert a performance fica a mesma. A conta dos milésimo de segundos ocorre em qryCODITEM.AsInteger := 1;  Acredito que o FireDac neste momento vai até o SGDB fazer alguma validação. Em TFDQuery.UpdateOptions já até coloquei a property FastUpdates = True.

Com o SGDB na rede local, é muito rápido, já em cloud parece gastar o tempo de acesso ao servidor.
Olhei a documentação do FireDac e não encontrei nada falando sobre, nem nos fóruns.
Minha aplicação trabalha assim em muito lugares e perde um pouco devido a isso.

1 hora atrás, Juliomar Marchetti disse:

Como assim na nuvem?

tu não colocou seu banco na internet e está acessando diretamente ele?

imagine o quanto de banda de internet vai comer seu sistema e na maioria paga por trafego de dados.

Sim na nuvem, consome sim bastante banda, mas nada fora do comum. Tem muitos que usam desta forma e no caso estou usando com o Firebird 3.0 que melhorou bastante com a compressão de dados. Tem a falta de tempo para converter tudo para um servidor em rest, mas com tempo vai convertendo.

Link para o comentário
Compartilhar em outros sites

  • Consultores
2 horas atrás, matheusguerra disse:

, alterando a property TFDQuery.AutoCalcFields para false, esse tempo chega a 071 milésimos de segundos

Isso acontece porque o evento OnCalcFields é chamado sempre que algum campo é alterado. Está na documentação, veja:

Citar

If an application permits users to change data, OnCalcFields is frequently triggered. In these cases an application may set AutoCalcFields to False to reduce the frequency with which the OnCalcFields event occurs and with which lookup values are fetched.

 

10 minutos atrás, matheusguerra disse:

Com o SGDB na rede local, é muito rápido, já em cloud parece gastar o tempo de acesso ao servidor.
Olhei a documentação do FireDac e não encontrei nada falando sobre, nem nos fóruns.

Não sei ao certo que tipo de documentação você quer encontrar. Contudo, é natural que um BD na nuvem vai demorar mais pra responder por causa da latência.

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link para o comentário
Compartilhar em outros sites

22 minutos atrás, EMBarbosa disse:

Isso acontece porque o evento OnCalcFields é chamado sempre que algum campo é alterado. Está na documentação, veja:

Já alterei a property AutoCalcFields.

2 horas atrás, matheusguerra disse:

alterando a property TFDQuery.AutoCalcFields para false

 

 

22 minutos atrás, EMBarbosa disse:

Isso acontece porque o evento OnCalcFields é chamado sempre que algum campo é alterado. Está na documentação, veja:

 

Não sei ao certo que tipo de documentação você quer encontrar. Contudo, é natural que um BD na nuvem vai demorar mais pra responder por causa da latência.

Além da que você passou também olhei essa.

http://docs.embarcadero.com/products/rad_studio/firedac/frames.html

Sim, sei que não vai ter a mesma performance com o SGDB sendo consumido em uma rede local, mas os milésimos de segundo demorando que citei, está ao aplicar valor em um field do dataset, que está na memória. Ai vem a duvida, será que estar indo até o SGDB para fazer alguma validação? É possível não comportar desta forma?
Um TFDQuery com 30 fields perde quase 3 segundos alterando dados na memória local. :(

Muito Obrigado pela atenção. :)

 

Editado por matheusguerra
Link para o comentário
Compartilhar em outros sites

  • Moderadores
2 horas atrás, matheusguerra disse:

Usando o SGDB na rede local, o tempo fica 004 milésimos de segundos.

Fiz um teste com 100.000 alterações num TField do TFDQuery conectado em um banco na rede local e ficou num total de 56 ms.

Tem algum evento no OnChange ou OnValidate desse TField que possa estar consumindo banda?

 

 

Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Link para o comentário
Compartilhar em outros sites

  • Moderadores

Sinceramente o tempo e problemas que vai causar a seu cliente/usuário é o mesmo que programador sua aplicação para trabalhar corretamente na nuvem

Consultor SAC ACBr Juliomar Marchetti
 

Projeto ACBr

skype: juliomar
telegram: juliomar
e-mail: [email protected]
http://www.juliomarmarchetti.com.br
MVP_NewLogo_100x100_Black-02.png
 

 

Link para o comentário
Compartilhar em outros sites

1 minuto atrás, BigWings disse:

Fiz um teste com 100.000 alterações num TField do TFDQuery conectado em um banco na rede local e ficou num total de 56 ms.

Tem algum evento no OnChange ou OnValidate desse TField que possa estar consumindo banda?

Não tem nenhum evento ligado em nenhum TField.

Sim na rede local fica muito rápido, agora na nuvem acredito que vai até o SGDB e devido a latência tem essa pequena demora.

Link para o comentário
Compartilhar em outros sites

9 minutos atrás, Juliomar Marchetti disse:

Sinceramente o tempo e problemas que vai causar a seu cliente/usuário é o mesmo que programador sua aplicação para trabalhar corretamente na nuvem

Certo.
Referente ao tempo. É uma aplicação muito grande e legada que passou por muitos programadores desde 1999. Vai demorar muito para migrar tudo para servidor rest.
Em pesquisas, existem muitos casos de sucesso usando desta forma, não é o Oracle 12c, mas o Cantu brigou muito para melhorar o Firebird usando neste cenário.
Com o firebird 3.0 com a compressão ligada, estamos trabalhando normalmente, parece local, mas veio essa questão que citei aqui no fórum.

Link para o comentário
Compartilhar em outros sites

  • Consultores
1 hora atrás, matheusguerra disse:

Já alterei a property AutoCalcFields.

Não quis dizer que você não tinha alterado. Na verdade, eu estava explicando o motivo do tempo ser menor quando a propriedade é false, já que você disse que não tinha nada na documentação.

1 hora atrás, matheusguerra disse:

Ai vem a duvida, será que estar indo até o SGDB para fazer alguma validação? É possível não comportar desta forma?
Um TFDQuery com 30 fields perde quase 3 segundos alterando dados na memória local. :(

Não é isso o que a propriedade cachedUpdates faz?

De qualquer forma, talvez seja a hora de remover os componentes "DBDataAware"...

[]'s

Consultor SAC ACBr

Elton
Profissionalize o ACBr na sua empresa, conheça o ACBr Pro.

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Um engenheiro de Controle de Qualidade(QA) entra num bar. Pede uma cerveja. Pede zero cervejas.
Pede 99999999 cervejas. Pede -1 cervejas. Pede um jacaré. Pede asdfdhklçkh.
Link para o comentário
Compartilhar em outros sites

8 minutos atrás, EMBarbosa disse:

Não quis dizer que você não tinha alterado. Na verdade, eu estava explicando o motivo do tempo ser menor quando a propriedade é false, já que você disse que não tinha nada na documentação.

Desculpa, não tinha prestado atenção.

8 minutos atrás, EMBarbosa disse:

Não é isso o que a propriedade cachedUpdates faz?

Sim.

8 minutos atrás, EMBarbosa disse:

De qualquer forma, talvez seja a hora de remover os componentes "DBDataAware"...

Tem razão.
Fiz uma aplicação de teste no mesmo cenário e o tempo foi 0 (Zero).

Vou continuar aqui e se descobrir algo que estou fazendo ou entendendo errado posto aqui.
Obrigado.

Link para o comentário
Compartilhar em outros sites

  • Este tópico foi criado há 2262 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.