um pluguinho
Posts tagged ruby on rails
Passenger versos Thin
Jun 9th
Depois ler sobre o Passenger varias vezes no site do Akita, e utilizar ele na minha maquina para o desenvolvimento da aplicação de e-commerce, resolvi fazer alguns benchmarks e vê como ele se saia comparado ao thin.
Os testes a seguir foram executados com a aplicação em environment production, eles caem consideravelmente quando em development:
No / do site:
Thin (MRI) – Produção: 3.68 [#/sec] (mean)
Thin (Ruby Enterprise): 6.72 [#/sec] (mean)
Passenger (Ruby Enterprise): 2.64 [#/sec] (mean)
Em uma página secundaria de produto:
Thin (MRI): 19.11 [#/sec] (mean)
Thin (Ruby Enterprise): 36.49 [#/sec] (mean)
Passenger (Ruby Enterprise) : 5.53 [#/sec] (mean)
Com esses testes descobri algumas coisas:
- Que minha aplicação esta incrivelmente lenta, 6.77 (o melhor resultado) é inaceitável, preciso melhorar muita coisa para chegar onde preciso.
- O Passenger, pelo menos por hora, só compensa no ambiente de desenvolvimento, pois evita ter que ficar levantando processo para testar as aplicações. obs: isto é para a minha aplicação, para sua pode ser completamente diferente.
- Vou trocar o ruby do servidor de produção pela versão “Enterprise”, os resultados são sem duvida motivadores, a diferença no caso da página de produtos foi gritante.
O resultado não quer dizer absolutamente nada sobre o Passenger, se é ou não mais rápido para todos os casos, isto pode, e vai variar muito de aplicação para aplicação, principalmente no meu caso onde a aplicação ainda não passou por nenhum refatoramento nem um analise profunda de performance.
Além dos testes com a página inicial e com a página de produto, fiz um teste com arquivo estático, uma imagem para ser mais preciso, e deixo um aviso os mais eufóricos, o Passenger, sem a correta configuração pode ser um problema com os arquivos estáticos. A questão esta no fato de que apenas a configuração básica da aplicação no apache faz com que o arquivos estáticos sejam servidos através do ruby o que da um perda de desempenho em responder a esse tipo de arquivo violenta, o certo e fazer como é descrito na tópico 5.3.3 do manual do Passenger.
Pelo menos no meu caso a melhor maneira de servir arquivos estáticos tem sido a configuração do Apache para não passar a requisição das pastas estáticas para os cluster thin. Usando a opção “ProxyPass /images !” o Apache não envia a requisição dos arquivos no caminho /images para o cluster, o que evita processamento dos arquivos pelo ruby.
Meu grande problema agora vai ser refatorar aplicação, fiquei decepcionado em saber que do jeito que esta, estou com uma média de 3.68 [#/sec], isso é muito baixo, e depois do lançamento oficial dos sites pode ser um grande problema 
Asset Packger e o problema com pontos
Jun 9th
Como disse no post anterior estamos trabalhando o jQuery e Asset Packger. So que existe um pequena incompatibilidade entre esses dois.
O Asset Packer tem um pequeno bug que dificulta na hora de trabalhar com arquivos javascript ou css que tenham ponto no nome, como em Jquery-1.2.3.js. O que acontece e que ele usa a função File.extname, que busca pela extensão de um arquivo dado seu nome completo. Então quando você insere no arquivo de configuração do Asset como: jquery-1.2.3, ele interpreta que a extensão desse arquivo já foi digita, e que ela é .3, inserido o arquivo com o nome errado no cabeçalho da página.
Um solução é adicionar o nome completo do arquivo: jquery-1.2.3.js, isso funciona, mas apenas em modo desenvolvimento. O Asset Packger compila todos os arquivos de um grupo em um único arquivo, mas a função que processa os arquivos no helper e no compile são diferentes, sendo que o compile não verifica se já existe um extensão no nome do arquivo, ela apenas julga que é necessário adicionar o .js na hora de incluir os arquivos na compilação.
Para resolver esse problema eu fiz um fork do projeto no Github e corrigi com um pequena modificação.
jQuery e Asset Packager
Jun 9th
No projeto de e-commerce que estou trabalhando, estávamos com um problema de sobre peso nas páginas, chegando inclusive a 1.4 MB em algumas partes do site.
O principal motivo desse peso todo eram as imagens e banners, como em quase todo site, uma vez resolvido este problema também tivemos problemas com a biblioteca de Javascript: o Prototype. Que o Prototype é gordinho, quase todo mundo já sabe, a questão era como resolver isso. A resposta veio com o jQuery, uma biblioteca Javascript infinitamente superior tanto em recursos como no fato de oferecer versões compactas das bibliotecas que a constitui.
Antes de tentar o jQuery, experimentei usar algumas ferramentas de “compactação” para Javascript, a mais conhecida foi o YUI Compressor, a ferramenta padrão de compressão do projeto Mootools, mas não obtive sucesso, a compactação não funciona com a Prototype, o código final gerado é invalido, e não há muito o que fazer, o problema esta na maneira com que a Prototype foi feita.
Então depois de alguns dias de pesquisa e substituição, consegui achar todos as funcionalidades e bibliotecas equivalentes para o jQuery, uma vez feita a substituição lembrei de plugin que já tinha visto para Rails que podia deixa a coisa ainda melhor.
O Asset Packer é um plugin para auxiliar na utilização de Javascript e Css, com base em um arquivo de configuração pode-se definir pacotes de css ou javascript, da-lhes um nome, e depois incluir esse pacote com apenas um chamada, além disso ele conta com um tarefa rake que permite gerar uma versão compacta dos pacotes.
O grande atrativo do Asset Packer, e que ele inclui o javascript ou css em sua forma descompactada ou compactada de acordo com environment, permitindo ao desenvolvedor trabalhar com os códigos sem compactação durante a fase de desenvolvimento e inserindo as versões compactadas quando em fase de produção. Além destes recursos o Asset Packer ainda trabalha junto ao controle de versão (infelizmente por enquanto apenas com Subversion) e pode ser configurado para gerar as versões compactadas diretamente no servidor, através de configurações junto ao Capistrano.
Qual o mais legal?
Mar 22nd
Hoje li sobre o nova versão do Zendo Framework, uma das coisas que me chamou atenção foi a nova cara do site, eu conheci as outras versões do site e sempre gostei do trabalho que eles fazem por lá.
Ai me veio uma pergunta: qual dos sites de framework é mais legal? Não que isso faça a menor diferença na qualidade dos frameworks (sem flamers pessoal), mas mesmo assim a pergunta pairava. Eu listo a baixo os frameworks que já utilizei ou utilizo, existem muitos outros, deixe nos comentários qual o seu site preferido:
Por mais que eu goste de trabalhar com o Ruby on Rails, e de por um tempo ter considerado o site do Rails um dos mais legais que conhecia, hoje o site do Zend me salta aos olhos, verdadeira obra prima.
