Oi Leonardo,

Já muito se falou sobre o assunto em questão, mas acho que nunca ninguem parou para explicar as opções que existem no mundo Zope quando se fala em servir arquivos do filesystem, principalmente arquivos grandes e considerando arquiteturas que sejam baseadas em ZEO. Vejamos se eu consigo dar uma resposta razoavel...

Historicamente falando, havia um mito que foi corrigido no core do Zope por mim e pelo Sidnei a partir da versao 2.7.8: o mito da alocação de memória para arquivos grandes. Esse bug de implementação/arquitetura do ZPublish fazia com que arquivos de 50 MB alocassem pelo menos 50 MB de memoria para serem servidos via HTTP. Acessos via FTP e WebDAV sofriam do mesmo problema (e com WebDAV, era ainda pior). A correção consistiu em usar um laço e iterar sobre objetos PDATA, algo que passou a existir nas versões mais recentes do Zope para todos os objetos do OFS.

Esse mito tinha criado uma boa pratica que consistia em, para sites com muito trafego, delegar a um servidor apache o trabalho de servir arquivos binários atraves do filesystem. Isso trazia 2 vantagens: a primeira era a economia de memoria que o bug acima criava e a segunda vantagem era que as threads do servidor Zope não ficavam ocupadas servindo esses arquivos binários (pois quem fazia isso era o apache). A parte ruim dessa abordagem era que estavamos fugindo do Zen do Zope, que prega que objetos teriam que ficar no ZODB e não como arquivos no filesystem. Na pratica, optar por uma solução assim implicava num trabalho chato fazer o setup do Apache funcionar transparentemente  com o Zope e manter isso devidamente atualizado. Aqui as formas de fazer são diversas, mas no geral as soluções giram em torno do mod_rewrite do apache e redirects no Zope.

O ponto aqui é que o Zope tem poucas threads. Todo e qualquer tipo de cache que voce fizer, que evite que algum tipo de conteudo seja servido pelo Zope, será muito util. Isso ira economizar processamento do servidor de aplicação e deixara suas threads livres para processar o que realmente importa. Dai saiu a heuristica que o CacheFu usa hoje: cachear conteudo binario no SQUID e nao perder todo o gerenciamento que o CMS nos dá. Para arquivos binarios pequenos (CSS, JS, imagens) essa ainda é a melhor opção. Obviamente, esse setup não é simples e exige que voce customize sua aplicação para que os headers HTTP sejam corretamente setados (senao o SQUID não da nenhum ganho). Essa tem sido a heuristica mais bem aceita ultimamente (pois alem de melhorar a performance por causa do cache, permite instalacoes tolerantes a falha e com alta escalabilidade) e é a arquitetura que outros servidores de aplicações corporativos usam, como o Oracle AS e o Oracle webcache, onde tudo é baseado em Java.

No entanto, se voce realmente precisa servir arquivos grandes do filesystem (digamos imagens ISO de 650 MB) usar o Zope para servir isso não é uma boa solução. Não adianta, nesses casos, usar um Product que mapeie uma area do filesystem dos servidores Zope como se fosse uma pasta com objetos do ZODB (e não faz diferença se os arquivos estão num local unico, num filesystem de rede, por exemplo), pois esse Product apenas evitaria que o ZODB inchasse demasiadamente para armazenar esses arquivos e nada mais. Nessa abordagem (usando PloneLocalFolderNG, por exemplo) considerando que não teriamos problemas de alocação de memória, ainda continuariamos ocupando nossas threads do Zope enquanto alguem estivesse baixando os 650 MB dos ISOs (algo que pode levar horas se o request vem de uma linha discada). Basta voce imaginar a situação onde 4 pessoas baixam 4 ISOs ao mesmo tempo. Nesse caso um servidor Zope com o numero de threads padrao praticamente travaria até um dos downloads ser encerrado. O ZEN do Zope diz que um request deve processar rapido, para nao deixar outros requests esperando muito tempo.

Pois entao, qual seria a solucao se alguem estivesse precisando servir arquivos ISO de uma aplicacao Zope? Eu acredito que a melhor solução seria o Zope gerar um redirect. Esse redirect apontaria para um servidor apache onde todos os ISOs estariam. Essa solucao sera otima se na frente desse apache houvesse um SQUID fazendo cache e se o apache estivesse com o mod_expires devidamente configurado (gerando os cabecalhos de cache para que o squid cacheasse os ISOs). Essa abordagem é a pregada por Products como o Railroad, da Infrae.

Eu já peguei aplicações Zope tão mal escritas que a latencia de processamento de páginas praticamente me obrigou a fugir de todas as heuristicas que citei acima e criar soluções alternativas (deploy estatico). Se a aplicação está bem feita, problemas so ocorrem com arquivos grandes. Se a aplicação nao está la aquelas coisas, os problemas que um arquivo grande gera podem ser verificados em simples paginas tambem... por incrivel que pareca.

Sendo pragmatico: nao há solução ou arquitetura perfeita para todas as situações. Tudo depende da sua aplicação e as vezes detalhes simples fazem toda a diferença.

Nao sei se me fiz entender, espero que sim.

Um abraco

Xiru

On 4/30/06, Leonardo Santagada < [EMAIL PROTECTED]> wrote:
2006/4/28, xiru < [EMAIL PROTECTED]>:
>
>    Bem... se a instancia acessa arquivos no file system, cada instancia deve acessar sempre o mesmo path. Se estamos num ambiente ZEO, onde podemos ter isso em maquinas separadas, quem fez isso deve usar um filesystem de rede (estilo NFS). Nesses casos, a solucao seria que todas as instancias do zope acessassem os arquivos num unico lugar/maquina.
>
> Ca entre nos... solucao bem ruim essa... mas ja vi algo assim funcionando :-(

Ruim pq? O unico problema que eu vejo é o fato de ter um unico ponto
de falha, mas tu já tem isso por usar o zeo.
Se tu tiver alguma idéia melhor de como fazer isso eu quero saber, pq
eu realmente não sei


--
Leonardo Santagada (http://www.lomohomes.com/retype)

Não se preocupe com o que os outros vão fazer. O melhor jeito de
prever o futuro é inventa-lo.
- Alan Kay

"I am Pentium of Borg. Arithmetic is irrelevant. Division is futile.
You will be approximated."
"Borg will be assimilated. Resistance is futile. We are Microsoft."


Para enviar uma mensagem: zope-pt@yahoogrupos.com.br
Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED]
Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
    http://br.groups.yahoo.com/group/zope-pt/

<*> Para sair deste grupo, envie um e-mail para:
    [EMAIL PROTECTED]

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
    http://br.yahoo.com/info/utos.html





--
Fabiano Weimar dos Santos
Plone Developer and Consultant

Para enviar uma mensagem: zope-pt@yahoogrupos.com.br
Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED]



Yahoo! Grupos, um serviço oferecido por:
PUBLICIDAD


Links do Yahoo! Grupos

Responder a