Olá Roberto, Seguindo o mesmo raciocínio colocado por Leandro Dutra, há alguns emails atrás, de que não importa qual a marca da placa de rede a ser colocada, mas sim seu desempenho em relação ao processo em si, coloquei o comentário sobre a criação de processos pra esse modelo de aplicação onde há a necessidade de um grande volume de consultas.
Atente-se que não estou defendendo a idéia de que é "ruim" ou "inapropriado" a criação de vários processos pra cada conexão, em todos os casos. Acho-as necessárias por vezes, onde há a necessidade de separá-las dessa forma. Estou defendendo que pra esse tipo de aplicação seria mais viável uma outra abordagem, que não essa. Não me importa o montante de dados pra demonstrar o que estou defendendo, que graças a sua má interpretação, foi definido como fruto da ignorância. O simples fato de alocar mais memória, paginá-la, ou mesmo, mais uma interrupção no kernel pra relocá-la (no caso de ambientes unix-like), gastaria tempo e memória que, uma simples camada intermediária resolveria o mesmo problema de uma outra forma. Colocando dessa forma, ainda seria possível a construção de uma estrutura de cache que pudesse ser "avisado" sobre mudanças na base de dados, ou mesmo, de uma maneira mais "burra", questionar sobre mudanças no sgbd. Bruno. 2008/3/12 Roberto Mello <[EMAIL PROTECTED]>: > 2008/3/12 Bruno Simioni <[EMAIL PROTECTED]>: > > Uma camada intermediária entre as requisições (SQL do PHP) e o acesso ao > > banco, que se posicionasse de forma a receber requisições, utilizar uma > > conexão persistida para as queries (através de uma singleton, por > exemplo), > > e devolver as respostas, logando as ações de cada usuário que fez a > > requisição. > > PHP já tem conexões persistentes. Já vi várias aplicações em PHP mal > escritas que simplesmente não funcionam quando têm conexões > persistentes habilitadas. Mas isso é um problema da aplicação, não do > PHP ou do banco de dados. > > Além das conexões persistentes, há também intermediários como o > pgbouncer, que mantém um pool de conexões persistentes ao banco, > asssim eliminando a necessidade de modificações na aplicação. > > Para evitar ir ao banco de dados toda hora para solicitar dados > freqüentes que não mudam, ora a solução é um bom uso de cache. Não é > trabalho do banco de dados adivinhar quais dos seus dados ele deve > fazer cache. Ele tenta, mas obviamente é a um nível bem menos > específico do que você pode criar conhecendo os detalhes e nuances da > sua aplicação. > > Existem várias soluções nessa área, o memcache sendo uma que vem à > mente que é bem suportada no PHP. > > > Seria uma forma bem viável de resolver o problema da criação de > processos do > > postgres, que realmente é grave e inapto pra soluções desse tipo. > Envolve um > > overhead desnecessário pra criação de processos que inviabilizaria a > > solução. > > Você tem algum conjunto de dados que demonstre que o uso de múltiplo > processos do PostgreSQL é um "problema" e ainda por cima "grave"? Me > desculpe, sem ofensa, mas dizer que o fato de uma aplicação ser > desenhada ao redor do modelo de múltiplos processos é um "problema" é > pura e exclusiva ignorância. > > Informe-se antes de fazer afirmações de tamanha grandiosidade e > consequência. Isso simplesmente não é verdade, e há centenas de > aplicações e dados que demonstram isso. Vide o link que postei > anteriormente dos testes da tweakers.net. > > Roberto > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
