Jump to content

Promoção de Natal SAC Mensal

Contrate e ganhe 1 Kit agenda + Caneta
Saiba mais

LANÇAMENTO
Curso Completo - Dominando o ACBrMonitor

Conheça o Curso

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

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?

Share this post


Link to post
Share on other sites

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
Ajude o Projeto ACBr crescer - Assine o SAC

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.

Share this post


Link to post
Share on other sites

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
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

skype: juliomar
telegram: juliomar
http://www.juliomarmarchetti.com.br
Embarcadero MVP

Share this post


Link to post
Share on other 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.

Share this post


Link to post
Share on other sites
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
Ajude o Projeto ACBr crescer - Assine o SAC

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.

Share this post


Link to post
Share on other 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. :)

 

Edited by matheusguerra

Share this post


Link to post
Share on other sites
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

 

 

Share this post


Link to post
Share on other 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.

Share this post


Link to post
Share on other 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.

Share this post


Link to post
Share on other sites
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
Ajude o Projeto ACBr crescer - Assine o SAC

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.

Share this post


Link to post
Share on other 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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...