2008/3/12 Nilson Chagas <[EMAIL PROTECTED]>: > Desculpe já chegar sugando dos companheiros. > > Mas gostaria de opinião dos colegas sobre esta declaração do administrador > da hospedagem: > > "Que este novo site, use algum sistema de cache entre o site e o banco > (cache de dados + pool de conexão), pois o problema deste site atual, e da > grande maioria dos sistemas em php é a ausência desta camada essencial em > sites com grande volume de acesso. > > Não quero preocupá-los, mas, na minha opinião, com o banco PostgreSQL vai > ficar pior porque ele cria um processo servidor para cada conexão. Deste > modo, se a cada request for criada uma conexão, consumido dados, e fechada a > conexão, diferentemente do MySQL (que usa Threads e não processos do SO) o > servidor do banco vai não literalmente 'explodir'. Passei estas impressões > para o Shiro a muito tempo atras, quando recomendei outra plataforma para > este site. Em resumo, com PostgreSQL sem uma camada de pool + cache (ou, é > claro, redução da dependência do banco para renderizar cada página), não > antecipo um período de tranquilidade."
Seu administrador está redondamente enganado e mal informado sobre as diferenças entre arquiteturas de threads e múltiplos processos. Em sistemas como Linux, threads não passam de processos ligeiramente mais leves, cuja área de memória, descritores de arquivos, etc são compartilhados. Isso torna trocas de contexto entre diferentes threads de um mesmo processo ligeiramente mais rápidas. Há desvantagens também. Um problema numa thread pode vir a trazer o processo inteiro abaixo, já que é o mesmo processo. Sincronização e travas podem ser mais complexas. "Hacks" preguiçosos são mais fáceis de acontecer, visto que programadores são por natureza "preguiçosos" e há a tentação de botar cada vez mais no escopo global para ser ser acessado por todas as threads, eliminando a ligeira vantagem das trocas de contexto. Para comunicação entre processos, como no PostgreSQL, usa-se memória compartilhada, sinais e outros mecanismos que são bem entendidos e definidos. O bom uso de múltiplos processos é mais trabalhoso do que usar threads, daí a popularidade de threads com a nova geração de programadores next-next-finish. O time do PostgreSQL fez uma decisão consciente de continuar a usar múltiplos processos por que eles valorizam as vantagens do modelo de múltiplos processos para escalabilidade, confiabilidade e performance. Dizer que por que um programa usa threads e o outro usa múltiplos processos, que o que usa threads é automáticamente "mais rápido" ou "mais eficiente" é pura burrice. No Linux a criação de processos é extremamente rápida. Em Windows a coisa é diferente. Vide os testes da tweakers.net com escalabilidade do PostgreSQL 8.2 e MySQL 5.0.2 em máquinas com múltiplos processadores com múltiplos cores: http://tweakers.net/reviews/649/7 É óbvio que neste teste quem explodiu foi o MySQL 5.0, enquanto o PostgreSQL segurou muito bem a porrada e manteve escalabilidade linear. O seu administrador está certo que um "connection pooler" (como se diz isso em português?) ajudará, mas ele ajudaria QUALQUER banco de dados, por que o estabelecimento de uma nova conexão com um SGBD é "caro", e não por que o modelo de múltiplos processos do PostgreSQL é ineficiente ou mais lento. Para o PostgreSQL existem vários: pgBouncer, pgpool-2, etc. Roberto _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
