Talvez mudar a aplicação para gravar em a/b/c/abcdef.jpg seja um problema.<br><br>Com mod_rewrite você consegue fazer com que um retrieve da image (abcdef.jpg) redirecione para um script em PHP que acessa o banco e obtém os dados....<br>
<br>Mas realmente, concordo que o problema não é tão simples devido ao volume de dados e acessos, e principalmente, pela importancia da aplicação....<br><br>Se puder simular um ambiente e fazer as comparações, você poderá tomar uma decisão mais segura e inteligente que os nossos "achismos" ;-)<br>
<br>boa sorte! =)<br><br><div class="gmail_quote">2009/11/27 Giovanni Tirloni <span dir="ltr"><<a href="mailto:tirloni@gmail.com">tirloni@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/11/27 "Fábio Jr." <<a href="mailto:fjuniorlista@gmail.com">fjuniorlista@gmail.com</a>>:<br>
<div><div></div><div class="h5">> Fabio Rampazzo Mathias escreveu:<br>
>> Fabio,<br>
>><br>
>> Vamos com calma....você não tem 4 milhões de figuras....você tem<br>
>> aprox. 1,34 milhão de figuras (4/3).... o resto é resize da mesma, que<br>
>> você pode armazenar no mesmo registro do MySQL. Só programar para<br>
>> trazer a figura conveniente. Depois, você está compartilhando um<br>
>> diretório via NFS. Eu diria que, o gargalo está no NFS, pois ele não é<br>
>> performático como o filesystem.<br>
> Tenho 4 milhões de aquivos no total. Uma imagem tem 3 tamanho diferentes<br>
> e são 3 arquivos diferentes. Ok, acho q foi isso q vc entendeu mesmo, só<br>
> pra confirmar. Concordo com você ao dizer que nfs é gargalo, mas ele é<br>
> um dos gargalos, já que a medida que eu aumento o numero de arquivos no<br>
> mesmo diretório, o próprio filesystem começa a perder performance na<br>
> hora de me retornar o arquivo. Pelo menos foi isso que eu percebi aqui.<br>
>><br>
>> Outro ponto importante é a aplicação. Há a viabilidade de requisitar<br>
>> as 7 ou 10 figuras de uma vez só?<br>
>><br>
> Através de uma conexão ao banco sim, mas não através de uma consulta só.<br>
> Eu posso abrir uma conexão, e fazer as minhas 7 ou 10 consultas nessa<br>
> mesma conexão.<br>
>> Acho que mesmo que a pergunta anterior não seja respondida de forma<br>
>> afirmativa, um banco de dados traria ganhos em termos de performance.<br>
>><br>
>> Você sabe qual é a média de acessos e o pico de acessos (em<br>
>> quantidade) ??? Quanto ao cluster, qual máquina que você possui para o<br>
>> servidor NFS ?<br>
> O pico é de 120 requisições por segundo, e a média do dia é 40 req/seg.<br>
> Isso pq de madrugada a quantidade de requisições é muito baixa. A média<br>
> de requisições em horário comercial é de 60 req/sec.<br>
><br>
> O servidor nfs é um Dual Xeon 5405 com 2 GB de memória com discos SAS de<br>
> 15k RPM com espelhamento.<br>
<br>
</div></div>Todas as soluções apresentadas são ótimas do ponto de vista de cada<br>
um. Entretanto o seu maior problema, pelo que entendi, é o tempo que o<br>
fs demora para buscar o arquivo nesse diretório. Como já sugeriram,<br>
fazendo a simples mudança de criar mais diretórios irá resolver seu<br>
problema.<br>
<br>
abcdef.jpg -> a/b/c/abcdef.jpg<br>
<br>
Essa mudança na aplicação deve ser infinitamente mais fácil que<br>
colocar tudo em um banco de dados e mudar a lógica toda.<br>
<br>
Tenho lá minha dúvidas se adicionar camada de abstração em cima de<br>
camada de abstração vai melhorar a performance. Como sempre, o melhor<br>
é montar um ambiente separado e testar para a sua situação.<br>
<br>
A Internet está cheia de dicas de como otimizar o NFS.<br>
<br>
--<br>
<font color="#888888">Giovanni.<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
CentOS-pt-br mailing list<br>
<a href="mailto:CentOS-pt-br@centos.org">CentOS-pt-br@centos.org</a><br>
<a href="http://lists.centos.org/mailman/listinfo/centos-pt-br" target="_blank">http://lists.centos.org/mailman/listinfo/centos-pt-br</a><br>
</div></div></blockquote></div><br>