<?php
$this->pageTitle = Yii :: app()->name . ' - Sobre';
$this->breadcrumbs = array (
	'Sobre',
	
);
?>
<h1>Sobre o Thunder Snarf</h1>

<p>
	O Thunder Snarf é um software de relatório web para o <a href="http://www.thundercache.com.br/" target="external">Thunder Cache</a> Professional cujo principal objetivo é oferecer uma visão estratégica de como e o quê o Thunder está fazendo Cache, gerando valor agregado no apoio a decisão sobre como melhorar a eficiência geral da aceleração web oferecida pelo Thunder.
</p>
<p>
	O Snarf foi desenvolvido pela <a href="http://www.freebsdbrasil.com.br/" target="_blank">FreeBSD Brasil LTDA</a>, parceira estratégica da equipe <a href="http://www.bmsoftware.org/" target="external">BM Software</a> no desenvolvimento do Thunder Cache. O desenvolvimento foi financiado por Rodrigo de Oliveira Gomes, empresário e usuário Thunder Cache. Algumas partes do sistema foram baseados nas idéias e planejamentos de Marcos A. Ferreira, a pedido do Sponsor do Projeto (Rodrigo).
</p>
<p>
	Thunder Snarf é Software Livre, licenceado sob os termos da <a href="http://www.gnu.org/licenses/gpl-2.0.html" target="_blank">licença GNU/GPL v2.0</a> (sponsor demanded).
</p>
<p>
	<h3>O Thunder Snarf</h3>
</p>
<p>
	O Thunder Snarf é composto essencialmente de cinco componentes principais:
	<ul>
		<li>
			<u>/usr/local/www/thundersnarf</u>: estrutura do sistema de relatórios web, escritos em php;
		</li>
		<li>
			<u>/usr/local/bin/thundersnarf</u>: wrapper que faz o parsing inicial, validação e rotacionamentos dos arquivos access.log do Thunder Cache, e e evoca o poller para importação dos dados; é projetado para ser executado via crontab;
		</li>
		<li>
			<u>/usr/local/bin/thundersnarf-poll.php</u>: rotina principal, chamada pelo thundersnarf, que faz todo o polling dos dados do access.log e adiciona-os em banco de dados;
		</li>
		<li>
			<u>/usr/local/www/thundersnarf/protected/data/db/pgsql.sql</u>: estrutura de modelagem do banco de dados PostgreSQL do qual o thundersnarf depende;
		</li>
		<li>
			<u>/usr/local/www/thundersnarf/protected/config/thundersnarf.conf</u>: variáveis de configuração da base de dados e do diretório do thunderconf.
		</li>
	</ul>
</p>
<p>
	O Thunder Snarf foi projetado originalmente para FreeBSD. Pode ser utilizado em Linux, mas algumas particularidades não são compatíveis (como estatísticas de I/O de disco, por exemplo);
</p>
<p>
	<h5>O Wrapper</h5>
</p>
<p>
	O wrapper (/usr/local/bin/thundersnarf) deve ser evocado por crontab(1) em periodicidades nunca inferiores a 5 minutos; o periodicidade deve ser sempre indicada, em minutos, como argumento a chamada do wrapper. Por exemplo, a cada 5 minutos:
</p>
<p>
	<pre>*/5 * * * * root /usr/local/bin/thundersnarf 5</pre>
</p>
<p>
	Ou a cada hora:
</p>
<p>
	<pre>* */1 * * * root /usr/local/bin/thundersnarf 60</pre>
</p>
<p>
	<h5>O Poller</h5>
</p>
<p>
	O poller (/usr/local/bin/thundersnarf-poll) deve ser evocado através do Wrapper, exceto para propiciar a limpeza do banco de dados. Nesse caso o poller pode ser chamado diretamente em linha de comando através do argumento -d. Dessa forma o processo de limpeza removerá do banco todos os dados gravados há mais de _d_ dias. Por exemplo, para limpar o banco mantendo apenas dados dos últimos 60 dias:
</p>
<p>
	<pre>/usr/local/bin/thundersnarf-poll -d 60</pre>
</p>
<p>
	<h3>Considerações e Cuidados</h3>
</p>
<p>
	O processo de polling apesar de altamente otimizado, é essencialmente um processo de parsing de arquivo de log, o que por si só tem uma natureza de alto consumo de processamento. Dessa forma dependendo da sua carga de acesso ao Thunder Cache pode ser necessário avaliar a melhor periodicidade para o polling.
</p>
<p>
	Alguns ambientes tirarão melhor proveito de uma estratégia de polling mais curta, a cada poucos minutos, garantindo uma janela pequena de tempo onde o access.log é populado e portanto tornando processos de polling mais rápidos (por haver menos dados);
</p>
<p>
	Outros ambientes podem demandar perfis mais longos de pico de acesso, e podem ter menor necessidade de relatório recente, sendo candidatos para um polling único, uma vez por dia, nas madrugadas;
</p>
<p>
	Em todos os casos as seguintes considerações devem ser observadas:
	<ul>
		<li>
			Evite ter o diretório de cache (CACHEDIR) do thunder no mesmo disco que o Banco de Dados PostgreSQL ou o access.log;
		</li>
		<li>
			Evite o polling nos momentos em que as consultas aos relatórios (ambiente web) coincidem
		</li>
		<li>
			Tome cuidado com encavalamento: não adianta colocar o polling em períodos curtos se o equipamento não der conta de processar todas as informações em pouco tempo, pois existe o risco de um novo polling ser iniciado sem o anterior completar
		</li>
	</ul>
</p>
<p>
	<h3>Créditos</h3>
</p>
<p>
	<u>Sponsor</u>: Rodrigo de Oliveira Gomes<br>
	<u>Desenvolvimento</u>: <a href="http://www.freebsdbrasil.com.br/" target="_blank">FreeBSD Brasil LTDA</a><br>
	<u>Desenvolver Principal</u>: <a href="mailto:ricardohfsp@gmail.com">Ricardo Sette</a><br>
	<u>Modelagem da DB em PostgreSQL</u>: <a href="mailto:ricardohfsp@gmail.com">Ricardo Sette</a><br>
	<u>Apoio</u>: <a href="http://www.bmsoftware.org/" target="external">BM Software</a><br>
	<u>Framework</u>: Desenvolvido utilizando o <a href="http://www.yiiframework.com/" target="external">Yii Framework</a> (não Wii, ninguém jogou vídeo-game enquanto programava)
</p>