Em 8 de março de 2016 10:27, Fabrízio de Royes Mello
<[email protected] <mailto:[email protected]>> escreveu:
Apesar de REST ser moderno e flexibilizar a interoperabilidade não sei
se resolveria o problema levantado pelo autor original da thread, até
mesmo porque o payload do REST, por conta do JSON, é maior do que da
libpq.
Mesmo levando em consideração que toda a transferência de dados por
REST será "gzipada".
Pergunto isto, pois tenho um sistema assim(não usando Delphi), a
aplicação que roda no servidor tem um pool de conexões com o PostgreSql.
Eu gostaria de ver um pool de conexões remotas para ter uma idéia do
tipo de coisa linda que seria, principalmente um pool de conexões para
aplicações desktop.
Já foi dito acima que existe muitas coisas que influenciam na velocidade
de uma comunicação remota, payload certamente não me parece ser a mais
relevante.
Nossa gente, como está faltando contexto, técnica e está sobrando flame
nesta discussão!
Outro colega colocou que com REST dá pra usar pool de conexões e com a
libpq não dá, de onde veio isso???
O pgbouncer é feito para a libpq.
Colocar um servidor Web para fazer uma camada REST sobre o protocolo do
PostgreSQL, só vai colocar MAIS UMA camada por cima. A libpq continua lá.
Sim, REST vai adicionar *um monte* de coisas: overhead do http +
json/xml (ou o que você quiser, REST não limita a isso), perda da
capacidade de fazer transações atômicas, entre outras coisas. Vocês
terão de usar prepared transactions, por exemplo, que é outra carga.
REST não serve pra substituir uma conexão direta com um banco de dados.
Se vocês estão tendo problemas de lentidão, difícilmente é a taxa o
problema - o que normalmente causa isso é latência.
A libpq é bastante enxuta.
Se o servidor de banco de dados está longe, e vocês usam ORM, por
exemplo, ou se uma página faz loops com pequenos SELECT, ou se uma
aplicação que abstrai dados faz assim (não sei como os conectores Delphi
fazem), aí é a causa do problema.
1) Manter um pool de conexões, mesmo que 1:1, pode sim melhorar as
coisas por evitar o (baixo, mas importante quando o banco tá longe)
overhead de abrir e fechar conexões.
2) Evite pequenos SELECT pra montar uma página/tela de resposta -
prefiram um grande SELECT que, mesmo que seja mais pesado pra executar
no servidor de dados, a resposta não precisará de várias idas e vindas
via Internet.
3) Testem a latência - PING mesmo. A taxa, provavelmente, não foi saturada.
4) Evitem a todo custo usar ORM/abstração de objetos nesse contexto.
Extra: Comparar PHP com Delphi, libpq com REST, sua comparação aqui =
Flamewar besta.
Foco no problema - latência de rede
Foro na solução - técnicas para eliminar viagens de rede - são inúmeras,
citei algumas.
Vamos subir o nível desta lista?
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
