Protegendo projetos com o .htaccess

O Apache pode te ajudar a proteger um projeto com seu sistema de autenticação. E isso é mais fácil do que você pensa. Para tal, crie um arquivo .htaccess com o seguinte conteúdo:

  1. AuthUserFile /home/leonardo/public_html/project/.htpasswd
  2. AuthGroupFile /dev/null
  3. AuthName "Restricted Access"
  4. AuthType Basic
  5. <limit GET>
  6. require valid-user
  7. </limit>

Após isso, crie um .htpasswd com os dados de usuário e senha (atenção ao caminho do arquivo). A senha é criptografada e o conteúdo do arquivo é algo como o seguinte:

  1. leo:4tHAiRmQ4OpjM

Para criptografar a senha use um dos vários serviços por aí existentes. Para proteger um projeto em Rails, a solução também funciona bem, desde que seu .htaccess esteja na pasta public de sua aplicação

Usando ApacheBench para testes: Apache/mod_rails e Nginx/mongrel

O ApacheBench é um software do Apache usado para fazer testes de perfomance de servidores web, independente do servidor usado. Isso é muito útil para comparar o desempenho de diversas configurações, mas nem sempre pode apresentar a realidade do ambiente.

O ApacheBench é distribuído nos ambientes Linux pelo pacote apache2-utils – versões para Mac OS e Windows podem ser encontradas no site do software. Em distribuições como o Ubuntu, para instalá-lo basta um apt-get install apache2-utils (como super-usuário). A partir daí, o comando ab fica disponível em seu terminal e é só correr para o abraço!

Um teste pode ser feito com o comando:

  1. ab -n 100 -c 5 http://www.leonardofaria.net/

O Flag ‘-n’ indica o número de requisições, enquanto a opção ‘-c’ indica a ocorrência de conexões simultâneas. A saída do comando acima é semelhante a:

  1. This is ApacheBench, Version 2.0.40-dev < $Revision: 1.146 $> apache-2.0
  2. Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
  3. Copyright 2006 The Apache Software Foundation, http://www.apache.org/
  4.  
  5. Benchmarking www.leonardofaria.net (be patient).....done
  6.  
  7.  
  8. Server Software:        Apache/2.2.8
  9. Server Hostname:        www.leonardofaria.net
  10. Server Port:            80
  11.  
  12. Document Path:          /
  13. Document Length:        0 bytes
  14.  
  15. Concurrency Level:      5
  16. Time taken for tests:   16.460184 seconds
  17. Complete requests:      100
  18. Failed requests:        0
  19. Write errors:           0
  20. Non-2xx responses:      100
  21. Total transferred:      41600 bytes
  22. HTML transferred:       0 bytes
  23. Requests per second:    6.08 [#/sec] (mean)
  24. Time per request:       823.009 [ms] (mean)
  25. Time per request:       164.602 [ms] (mean, across all concurrent requests)
  26. Transfer rate:          2.43 [Kbytes/sec] received
  27.  
  28. Connection Times (ms)
  29.               min  mean[+/-sd] median   max
  30. Connect:      255  291  21.2    287     361
  31. Processing:   442  506 131.1    485    1732
  32. Waiting:      438  492  42.9    484     655
  33. Total:        698  797 137.9    774    2040
  34.  
  35. Percentage of the requests served within a certain time (ms)
  36.   50%    774
  37.   66%    804
  38.   75%    812
  39.   80%    818
  40.   90%    878
  41.   95%    925
  42.   98%    982
  43.   99%   2040
  44.  100%   2040 (longest request)

Dezenas de possibilidades podem ser traçadas com esses testes.
Nos meus benchmarks, realizei basicamente 2 testes: a renderização do index.html default do framework e a renderização de um Time.Now do Ruby. Em ambos os testes, o desempenho do nginx + mongrel_cluster foi superior ao Apache + mod_rails. Esse teste também foi feito por aí, e com resultados semelhantes ao meu.

Desse modo, em uma balança estão Apache/mod_rails e Nginx/mongrel_cluster. De um lado, pesam a facilidade de deployment e o crescente uso em shared hosts. De outro lado pesam a rapidez do servidor e a ‘dificuldade’ do deployment. E aí? De que lado você vai ficar?