Patrick Tracanelli escreveu: Rodrigo de Oliveira Gomes escreveu:
Pessoal, Primeiramente, agradeço a todos que ajudaram na empreitada de instalação do ThunderCache no meu ambiente. Graças a Deus está funcionando bem. Já consigo até visualizar os gráficos via web e tals. Meu ambiente ficou assim: Uma máquina proxy (FreeBSD 7.2 amd64, com 8 GB de memória) e uma Máquina Parent Cache (Pentium 4 3.2, FreeBSD 8.0 32bits, com 30 GB de disco para cache). Estou analisando o ambiente para saber como é o desempenho da ferramenta... Nesse momento, estou com algumas dúvidas em relação a quantidades... Vamos lá... Em menos de 4 horas meus usuários já acessaram aproximadamente 500 videos, somando um tamanho total de 1.5G. Alguém possui uma implementação do thundercache com milhares de arquivos em cache que possa falar sobre a agilidade do mesmo? Tipo, será que com 50000 arquivos armazenados, a velocidade continua a mesma? O Banco suporta legal o crescimento? As consultas ficam rápidas? A entrega de arquivos do cache para o cliente continua eficiente? Novamente, muito obrigado por tudo! Atenciosamente, Rodrigo Gomes Akada, Todas as limitações em potencial que você está levantando, são do seu ambiente computacional, e não do Thunder, ou do Lusca. Se demorar para acessar os dados em disco, é gargalo de disco. Se houver limitações você faz upgrade de hardware ou separa o proxy em mais de uma máquina, o que for melhor pro seu ROI. Você pode tomar açoes como colocar em ZFS async, colocr async convencional, pra aumentar a performance. Pode intervir em tuning no FreeBSD, e afins. O Thunder, diferente do Squid, não fragmenta os arquivos e não os indexa em múltiplos diretorios. Então a performance pra acessar o sistema de arquivos é a performance que o sistema operacional te oferecer. Nem mais, nem menos. Outros subsistemas como memória, CPU e rede podem gerar outros gargalos, mas mais uma vez serão limitações do seu servidor, antes da aplicação. Aqui tenho um thunder com 1TB. Quantos arquivos tem? Não faço ideia ;) e é pesado demais mandar calcular. Mas no dia-a-dia o iostat indica picos de 2 L(q), o que é mais que aceitável. Os discos são SATA300 convencionais, rodando com VFS_AIO em kernel. O mesmo iostat e gstat indicam picos de 100% busy mas constantes de 40%-55% busy. Ou seja é ainda mais rápido buscar do disco que da Internet ;) E quando não for, RAID-5, discos SAS, RAID-Z, enfim ha opções pra melhor performance ;) O TC4 tem algumas melhorias nesse sentido (IO-read). Alem disso agora ele cacheia conteudo estatico o que demanda mesmo algum acesso a disco a mais. ------------------------- Histórico: [1]http://www.fug.com.br/historico/html/freebsd/ Sair da lista: [2]https://www.fug.com.br/mailman/listinfo/freebsd Patrick, Boa tarde! Primeiramente, obrigado pela resposta :-) Alongando um pouco mais o assunto, tendo em vista seu conhecimento... :-) Estou com dois servidores distinto... um para o Youtube e outro para o Orkut. O do youtube está ok, sempre maiores problemas. Já o do orkut está com consumo alto de swap, por diversas vezes o cliente recebe uma mensagem de "ERROR!" na página e tals. Estou achando muito estranho o comportamento do servidor no que tange o site do orkut. Tens alguma idéia? Obrigado, Atenciosamente, Rodrigo Gomes References 1. http://www.fug.com.br/historico/html/freebsd/ 2. https://www.fug.com.br/mailman/listinfo/freebsd ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
