Olá Euler e amigos! Também estou estudando DBCP para o projeto. Minhas considerações abaixo: > Depende. Você não mencionou a arquitetura do seu sistema. Em uma arquitetura cliente-servidor, o pgBouncer fica junto com o SGBD. Em uma arquitetura web você pode ter tanto o pgBouncer nos servidores de aplicação quanto no servidor do SGBD. Aplicação é WebWebApp (JDBC) + pgBouncer + PostgreSQL
> O que você deve ter em mente é que onde o pgBouncer estiver, a conexão a ele é via socket (que é bem mais rápido do que a conexão TCP). Isso quer dizer que se o pgBouncer tiver que ficar estabelecendo muitas conexões ao longo do dia (para atender os picos de acesso, por exemplo) é melhor você ter o pgBouncer próximo ao SGBD. > Há a opção de colocar o pgBouncer em um servidor separado mas não é recomendado pois (i) é mais um ponto de falha e (ii) você perde o benefício das conexões via socket. > Eu já vi pessoas mencionarem instalar o pgBouncer tanto no servidor de aplicações quanto no servidor do SGBD mas eu não tenho números para afirmar se a diferença é tão grande com relação a um único pgBouncer. Assistindo um vídeo do palestrante Peter Eisentraut no PGConf US 2015, conforme link https://www.youtube.com/watch?v=CAKI_eZiRAU, ele apresentou alguns possíveis cenários que no meu entendimento o PgBouncer estava instalado onde estava a aplicação e também fora, como se fosse algo dedicado. Concordo que realmente não seria uma regra. > Em termos de administração, ter um pgBouncer somente é o melhor cenário. Se sua arquitetura for web e você optou por instalar pgBouncer no servidor de aplicações, você vai precisar instalá-lo em N servidores de aplicação. No cenário com pgBouncer dos dois lados, você terá mais trabalho ainda (a instalação deve ocorrer em N+1 servidores de aplicação). Se bem que o pgBouncer não lança versões com tanta frequência. Em Sexta-feira, 2 de Outubro de 2015 22:57, Euler Taveira <[email protected]> escreveu: On 02-10-2015 16:49, Leonardo Guimarães wrote: > Estou desenvolvendo um projeto e vi apossibilidade de implementar o > PgBouncer. > O projeto atenderia em torno de 200 conexões simultâneas. > O certo seria implantar ele do lado do cliente, no mesmo ambiente do APP ou > no lado do servidor de dados? > Depende. Você não mencionou a arquitetura do seu sistema. Em uma arquitetura cliente-servidor, o pgBouncer fica junto com o SGBD. Em uma arquitetura web você pode ter tanto o pgBouncer nos servidores de aplicação quanto no servidor do SGBD. O que você deve ter em mente é que onde o pgBouncer estiver, a conexão a ele é via socket (que é bem mais rápido do que a conexão TCP). Isso quer dizer que se o pgBouncer tiver que ficar estabelecendo muitas conexões ao longo do dia (para atender os picos de acesso, por exemplo) é melhor você ter o pgBouncer próximo ao SGBD. Há a opção de colocar o pgBouncer em um servidor separado mas não é recomendado pois (i) é mais um ponto de falha e (ii) você perde o benefício das conexões via socket. Eu já vi pessoas mencionarem instalar o pgBouncer tanto no servidor de aplicações quanto no servidor do SGBD mas eu não tenho números para afirmar se a diferença é tão grande com relação a um único pgBouncer. Em termos de administração, ter um pgBouncer somente é o melhor cenário. Se sua arquitetura for web e você optou por instalar pgBouncer no servidor de aplicações, você vai precisar instalá-lo em N servidores de aplicação. No cenário com pgBouncer dos dois lados, você terá mais trabalho ainda (a instalação deve ocorrer em N+1 servidores de aplicação). Se bem que o pgBouncer não lança versões com tanta frequência. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
