Re: [pgbr-geral] testar latencia AWS

[Douglas Fabiano Specht]

Em 24 de setembro de 2015 01:42, Sebastian Webber 
escreveu:

>
>
> Em 23 de setembro de 2015 09:20, Flavio Henrique Araque Gurgel <
> fha...@gmail.com> escreveu:
>
> Só vou entrar nessa thread pra apoiar a idéia do colega.
>
>
>> Nenhum comentário é inútil ou fútil. O máximo que pode acontecer é gerar
>> mais discussão construtiva.
>>
>
> Muitas vezes alguém trazer um problema "un tanto dificil" gera alguma
> diversão para os curiosos de plantão. Eu particularmente não respondo muita
> coisa nessa lista, mas normalmente quanto mais comentada ou até mais
> complicada for a thread mais vontade de participar eu tenho.
>
>
>> Obrigado por fazer parte desta lista e tentar ajudar aos demais. Não se
>> acanhe se vier outra resposta do pessoal mais experiente reparando ou
>> complementando. É assim que construímos uma comunidade, isso acontece com
>> todo mundo, comigo também.
>
>
> +1
>
> Um abraço!
>
> --
> Sebastian Webber
> http://swebber.me
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

Bom dia Pessoal
para apimentar um pouco mais, ja que fui eu quem iniciou a thread, abaixo
segue as latências enviado pelo pessoal da representante da Amazon no
Brasil.
no nosso caso vai ficar complicado utilizar os datacenter fora do Brasil,
devido nosso ERP (delphi) ser em duas camadas, com o aplicativo na maquina
do cliente apontando o banco para o datacenter. Neste caso teríamos que
utilizar Terminal Server.
Atualmente nosso banco está no datacenter da UOLDIVEO e temos uma latência
media de 40s e os clientes reclamam as vezes da lentidão.



Abaixo as condições de latência solicitadas.

US-East (Virginia) 152 ms
US-West (California) 236 ms
US-West (Oregon) 243 ms
Europe (Ireland) 316 ms
Europe (Frankfurt) 314 ms
Asia Pacific (Singapore) 376 ms
Asia Pacific (Sydney) 336 ms
Asia Pacific (Japan) 327 ms
South America (Brazil) 34 ms


-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] testar latencia AWS

[Danilo Silva]

Em 24 de setembro de 2015 09:30, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Bom dia Pessoal
>> para apimentar um pouco mais, ja que fui eu quem iniciou a thread,
>> abaixo segue as latências enviado pelo pessoal da representante da
>> Amazon no Brasil.
>> no nosso caso vai ficar complicado utilizar os datacenter fora do
>> Brasil, devido nosso ERP (delphi) ser em duas camadas, com o aplicativo
>> na maquina do cliente apontando o banco para o datacenter. Neste caso
>> teríamos que utilizar Terminal Server.
>> Atualmente nosso banco está no datacenter da UOLDIVEO e temos uma
>> latência media de 40s e os clientes reclamam as vezes da lentidão.
>>
>
> Aplicação cliente-servidor sofre muito com latência até o banco de dados,
> normalmente são péssimas candidatas a ir pra nuvem. As diversas consultas
> necessárias para montar uma tela, por exemplo, multiplica a latência.
> Exemplo:
>
> Uma tela que precise de 5 consultas. Se a latência é de 40ms, isso dá
> 200ms, sem contar o tempo de executar as consultas no servidor e mais o
> processamento local com os dados retornados. Se considerarmos BEGIN et
> COMMIT, junta mais 80ms.
>
> No exemplo acima, se a latência for de 200ms (usuário no Brasil e servidor
> nos EUA), seu tempo só de latência sobe para 1,4 segundos! Uma eternidade.
>
> Sim, é inviável no seu caso.
>
> Se vocês gostariam mesmo de ir pra "nuvem", sugiro reescrever uma
> aplicação web, onde o servidor de aplicação fica próximo do banco de dados.
> Nesse caso, o cliente não sente ou sente muito pouco a latência, uma vez
> que a quantidade de idas e vindas se reduz à requisição da página e o
> retorno dela. As idas e vindas aplicação-banco de dados são sempre rápidas,
> normalmente inferiores a 10ms.
>
> Taí, não precisa ser bidu pra calcular o efeito da latência usando dados
> aproximados.
>
> Claro que sua solução de "terminal server" tem um efeito parecido de
> redução de latência, como uma aplicação web.
>
>
> ​No passado tive problema com a latência, mesmo utilizando uma aplicação
web, o usuário reclamava de lentidão, pois fazia-se leitura de código de
barras, e o usuário era mais rápido que a aplicação.

Nesse processo de leitura, a aplicação fazia algumas validações, o problema
era que cada validação representava uma requisição ao banco de dados, então
multiplicando cada requisição pela latência, esse processo todo levava
quase 2 segundos (que eternidade)...

A solução foi tirar as validações da aplicação e colocar no banco de dados,
pois assim a aplicação fazia apenas uma requisição, o banco de dados
processava e retornava o que tinha que retornar, com isso, conseguimos
reduzir para apenas alguns milissegundos o processo e deixar o cliente
feliz :)

Douglas, analise todo o processo e tente reduzir a quantidade de
requisições que a aplicação faz ao banco de dados, com isso você conseguirá
reduzir o tempo total do processo.

[]s
Danilo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] testar latencia AWS

[Matheus de Oliveira]

2015-09-24 8:21 GMT-03:00 Douglas Fabiano Specht :

> Atualmente nosso banco está no datacenter da UOLDIVEO e temos uma latência
> media de 40s e os clientes reclamam as vezes da lentidão.


Tem certeza que usou a unidade correta? Não quis dizer 40ms?

40s de latência é insano...

Atenciosamente,
-- 
Matheus de Oliveira
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] testar latencia AWS

[Flavio Henrique Araque Gurgel]

Bom dia Pessoal
para apimentar um pouco mais, ja que fui eu quem iniciou a thread,
abaixo segue as latências enviado pelo pessoal da representante da
Amazon no Brasil.
no nosso caso vai ficar complicado utilizar os datacenter fora do
Brasil, devido nosso ERP (delphi) ser em duas camadas, com o aplicativo
na maquina do cliente apontando o banco para o datacenter. Neste caso
teríamos que utilizar Terminal Server.
Atualmente nosso banco está no datacenter da UOLDIVEO e temos uma
latência media de 40s e os clientes reclamam as vezes da lentidão.


Aplicação cliente-servidor sofre muito com latência até o banco de 
dados, normalmente são péssimas candidatas a ir pra nuvem. As diversas 
consultas necessárias para montar uma tela, por exemplo, multiplica a 
latência. Exemplo:


Uma tela que precise de 5 consultas. Se a latência é de 40ms, isso dá 
200ms, sem contar o tempo de executar as consultas no servidor e mais o 
processamento local com os dados retornados. Se considerarmos BEGIN et 
COMMIT, junta mais 80ms.


No exemplo acima, se a latência for de 200ms (usuário no Brasil e 
servidor nos EUA), seu tempo só de latência sobe para 1,4 segundos! Uma 
eternidade.


Sim, é inviável no seu caso.

Se vocês gostariam mesmo de ir pra "nuvem", sugiro reescrever uma 
aplicação web, onde o servidor de aplicação fica próximo do banco de 
dados. Nesse caso, o cliente não sente ou sente muito pouco a latência, 
uma vez que a quantidade de idas e vindas se reduz à requisição da 
página e o retorno dela. As idas e vindas aplicação-banco de dados são 
sempre rápidas, normalmente inferiores a 10ms.


Taí, não precisa ser bidu pra calcular o efeito da latência usando dados 
aproximados.


Claro que sua solução de "terminal server" tem um efeito parecido de 
redução de latência, como uma aplicação web.


[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] testar latencia AWS

[Eurides Baptistella]

> Douglas, analise todo o processo e tente reduzir a quantidade de requisições
> que a aplicação faz ao banco de dados, com isso você conseguirá reduzir o
> tempo total do processo.

Não sei se é o caso, mas ele falou em ERP, nesse caso duvido que tenha
um ponto apenas que precisara ser melhorado... Acredito que seja
inviável adaptar o software para que atenda de forma razoável

O problema é o Delphi, seus componentes e drivers, não são otimizados
para se trabalhar com uma base remota. Se você esta utilizando
Datasnap sugiro que coloque seu Srv de Aplicação o mais próximo do
banco de dados possível (use protocolo TCP). Conheço apenas um caso em
que uma determinada empresa que utiliza Delphi + Datasnap + PostgreSQL
migrou para AWS com sucesso (até onde sei...).
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral