Ameniza o trabalho do banco de dados em selecionar os dados solicitados ,
mas cada vez que você fizer uma requisição, todos os dados serão
carregados na memória do servidor Web. Eu não entendo nada de PHP, mas o
princípio é o mesmo em qualquer aplicação.

Vou tentar criar um guia:
- Você fará uma interface que faz a solicitação ao banco de dados do que é
 solicitado.
- Essa interface é uma thread;
Por exemplo:
- Você faz uma solicitação de login e senha e carrega num array.
- A toda solicitação, essa interface pesquisa o array.
- Caso o dado pesquisado não esteja no array, é procurado no banco.

Para amenizar o tamanho do array, você criaria uma view com os logins mais
acessados.

Essa interface responde a todas requisições de login.

Agora, deve ter algum framework que possibilita tu fazer isso de forma
mais dinâmica. Esse guia é para tu ter uma idéia da forma como isso
acontence.

O servidor de aplicações JBOSS possui um sistema chamado JBOSS Cache. Não
sei se esse sistema trabalha com outro tipo de servidor de aplicações.

Alecindro

> Vc e o Bruno me deram uma boa visão sobre o problema, e pelo que entendi
> vou
> ter que desenvolver isto por meio do PHP, não e algo que eu possa fazer no
> banco de dados. Correto??
>
> Uma pergunta, a utilização de view amenizaria o problema???
>
> Em 12/03/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> escreveu:
>>
>> Em relação o PostgreSQL ao criar um processo servidor para cada
>> aplicação
>> eu não sei te responder.
>>
>> Em sistemas Web, com grande número de requisições, devemos criar um
>> cache
>> (armazenar na memória do servidor Web) os dados que são mais acessados,
>> para não ter requisições ao banco toda vez que alguém solicitar, por
>> exemplo, uma lista de preços. Em java eu utilizo EhCache. Se houver
>> alguma
>> atualização no banco de dados o cache também é atualizado (tem de
>> programar isso).
>>
>>
>> Vou tentar resumir da forma mais simples. Pela sua explanação, me parece
>> que o seu sistema acessa diretamente o banco de dados pela camada de
>> apresentação. O pool de conexão é tu ter um interface (camada model) que
>> acessa o seu banco de dados através das requisições da camada de
>> controle.
>> Se houver mais de uma mesma requisição, essa camada faz apenas uma
>> chamada
>> ao banco de dados e responde a todas requisições. E o cache nada mais é
>> do
>> que reter essa requisição em memória, respondendo a outras requisições
>> com
>> esses dados. Toda requisição de dados é solicitado a camada model que se
>> tiver as informações em cache essas serão enviadas, ou faz uma nova
>> requisição ao banco.
>>
>> Espero ter respondido sua questão,
>>
>> Alecindro
>>
>>
>> > 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."
>> >
>> >
>> > Obrigado.
>> >
>> > --
>> > []s
>> > Nilson Chagas
>> > ---
>> > Visite:
>> > Fundamental: www.amados.com.br
>> > Dúvidas:http://nilsoftware.blogspot.com/
>> > Obrigatório: www.saopaulofc.com.br
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> 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

Responder a