Primeiro gostaria de agradecer todo feedback positivo que tenho recebido em relação ao artigo. Estou aqui disponibilizando o código fonte dele, ou explicar como ele está disposto e por fim vou fazer alguns comentários sobre o artigo.
O arquivo zip contem 5 diretórios: deps, versao-inicial, versao-replicacao, versao-particionamento e versao-caching. Em deps, você encontrará os jar que são as dependências do projeto, eles contém tudo, inclusive a API de servlets. Os demais diretórios são quatro versões do mesmo site, cada um com recursos de escalabilidade distintos, eu recomendo ler na seguinte ordem, pois cada um constroi em cima do anterior:
- versao-inicial, sem nenhum dos recursos descritos no artigo, apenas o básico do sistema;
- versao-replicacao, adicionei aqui o suporte a replicação master-slave;
- versao-particionamento, particionei a tabela posts nessa versão; e
- versão-caching, contempla suporte a caching local para o DAO Blog.
Esses fontes estão disponíveis sob a licensa do MIT, que significa que você pode fazer qualquer coisa, menos me culpar se algo der errado.
Quanto ao artigo, acho que ficou faltando falar sobre tolerância a falhas, em um ambiente distribuido as chances de um servidor falhar é muito maior, por exemplo, o Mean Time Between Failure dos HDs SATA modernos gira em torno de 300mil horas, em um parque com 200 máquinas usando espelhamento (dois discos por servidor), vamos ter pelo menos um disco falhando por mês, com sorte. Esse assunto, porém, não foi abordado porque merece por sí só um artigo inteiro.
Eu gostaria de ter também discutido sobre o uso de caches distribuidos, como memcached, mas também é um assunto bem delicado, do qual não seria simples para incluir nos exemplos, já que a questão de resiliência e adaptabilidade seriam mais gritantes.
Apesar desses dois pontos que gostaria de ter discutido melhor, acho que o artigo conseguiu seu objetivo (meu objetivo), que era abrir os olhos de quem o lê que escalabilidade não é responsabilidade exclusiva do servidor de aplicação e que não se trata de um assunto intangível.
Update: O Lucas me lembrou que esqueci de colocar um link para o arquivo, use este aqui, valeu Lucas!
2 responses so far ↓
1 Luca Bastos // Sep 20, 2006 at 3:23 pm
O site não cumpre os SLAs, o throughput é ruim, o tempo fora do ar está acima do esperado e poucos sabem por onde começar a mexer.
Estes problemas todos que você abordou com clareza nem sempre na prática são claramente identificados.
Se os problemas não estão na base de dados onde um bom DBA geralmente consegue apontar os gargalos, nem sempre há uma ferramenta fácil de usar que aponte logo exatamente onde estão os 80% da regra 80-20 do Pareto.
Aliás a Amazon publicou um artigo sobre a ferramenta deles em http://www.cs.berkeley.edu/~bodikp/publications/hotac06.pdf
Encontrei isto em: http://www.artima.com/forums/flat.jsp?forum=276&thread=177021
Pela dificuldade e muitas vezes pela falta de tempo de usar ferramentas de testes de stress, é importante já ter estas técnicas que você citou bem dominadas como armas do cinto de utilidades do BatServerMan. Acredito que com o tempo se pode desenvolver o “feeling” de perceber qual projeto já deve partir logo de cara com as técnicas que citou. Você já deve sentir estes gargalos pelo odor.
Em tempo: o zip com os fontes não aparece.
2 kumpera // Sep 20, 2006 at 4:38 pm
Lucas, não é preciso muito feeling para saber se um projeto ira necessitar ser muito escalavel ou não.
Se no planejamento inicial estiver previsto que o volume esperado será muito grande, já é bom construir desta forma.
Achei interessante o link, vou ler com mais atenção assim que possivel
Leave a Comment