TFDQuery.Append Lento

[matheusguerra]

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?

[EMBarbosa]

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.

[Juliomar Marchetti]

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.

[matheusguerra]

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.

[EMBarbosa]

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.

[matheusguerra]

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 17 Janeiro, 2018 por matheusguerra

[BigWings]

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?

 

 

[Juliomar Marchetti]

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

[matheusguerra]

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.

[matheusguerra]

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.

[EMBarbosa]

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"...

[matheusguerra]

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.

[matheusguerra]

Descobri, o problema é que tem o evento OnDataChange no TDataSource.

Falha minha deixar isso ter passado batido.