O documento descreve a história e os tipos de aplicação servers, começando com CGI em 1993 e evoluindo para FastCGI, Rack, e aplicação servers como Unicorn, Phusion Passenger, Puma e uWSGI. É explicado como cada um lida com sockets e threads de forma diferente para melhorar a performance e escalabilidade.

1. Application Server

2. História
• 1993 - NCSA (National Center for Supercomputing Applications)
cria uma especificação;
• 1997 - a especificação acaba gerando a RFC 3875;
• Nasce o formoso CGI.

3. Common Gateway Interface
• Extensão ao sistema de web estática;
• Camada entre Web Server (ex. Apache) e o conteúdo
estático;
• Webserver passa a executar /cgi-bin/index.pl e não
mais /index.htm;
• Permite envio de dados em uma requisição HTTP;
• Webserver passa a criar variáveis de ambiente de
acordo com a especificação, como QUERY_STRING.

4. CGI Code
#!/usr/bin/perl
print "Content-type: text/plainrnrn";
for my $var ( sort keys %ENV ) {
printf "%s = "%s"rn", $var, $ENV{$var};
}
http://example.com/cgi-bin/printenv.pl/foo/bar?var1=value1&var2=with%20percent%20encoding
DOCUMENT_ROOT="C:/Program Files (x86)/Apache Software Foundation/Apache2.2/htdocs"
GATEWAY_INTERFACE="CGI/1.1"
HTTP_ACCEPT="text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
HTTP_HOST="example.com"
PATH_INFO="/foo/bar"
QUERY_STRING="var1=value1&var2=with%20percent%20encoding"
REMOTE_ADDR="127.0.0.1"
REQUEST_METHOD="GET"
REQUEST_URI="/cgi-bin/printenv.pl/foo/bar?var1=value1&var2=with%20percent%20encoding"
SCRIPT_FILENAME=“/var/www/app/cgi-bin/printenv.pl”
SCRIPT_NAME="/cgi-bin/printenv.pl"
SERVER_ADDR="127.0.0.1"

5. CGI
Nem tudo são flores
• A cada chamada ao script -> 1 criação de processo
pelo Web Server;
• Concorrência completamente inviável;
• Trocar Perl (interpretado) por C (compilado) não é
suficiente.

6. FastCGI
• Extensão do protocolo CGI;
• Web Server inicia um processo contínuo do App Server;
• Web Server não é mais responsável pela criação do processo da
aplicação;
• FastCGI inicia o papel de Application Server, com configurações
específicas para otimização deste processo;
• Técnica de pré-fork é utilizada para agilizar a criação de
processos de aplicação.
• Independente de linguagem, permite comunicação por API.

7. Mundo Ruby
• Problemas com padronização na comunicação entre
App Server e Aplicação;
• A aplicação deve poder ser comunicar com todos os
App Servers;
• Solução: Rack

8. Um pouco sobre Sockets
• Técnica responsável pela comunicação entre Cliente/
Servidor;
• Modos de comunicação:
• Blocking I/O;
• Nonblocking I/O;
• Assíncrono;
• Signal-driven I/O.

9. Socket
Blocking I/O

10. Socket
Nonblocking I/O

11. Socket
Assíncrono

12. Socket
Signal-driven I/O

13. Ruby
Application Servers
• Unicorn;
• Phusion Passenger;
• Puma;
• Webrick.

14. Unicorn
• Rack based;
• Modelo Blocking I/O para requisições;
• Múltiplos Processos pré forked;
• Single Thread;
• Necessita um proxy reverso a sua frente.

15. Phusion Passagenger
• Rack based;
• Modelo Blocking I/O;
• Implementa um proxy reverso built-in usando Signal-
driven I/O;
• Multi-threading na versão paga.

16. Puma
• Rack based;
• Blocking I/O para requisições;
• Múltiplos processos;
• Multi-threading;
• Necessita um proxy reverso a sua frente.

17. Mundo afora
• SCGI;
• Web server módulos;
• NodeJS;
• uWSGI

18. SCGI
• Baseado em FastCGI;
• Implementação mais fácil;
• Importante na criação de futuros App Servers como
WSGI e uWSGI.

19. Web server módulos
• Apache, IIS, Netscape web server…
• Elimina o uso de um CGI script separado;
• Interpreta a aplicação no mesmo processo do web
server;
• Processo muito pesado para ser reiniciado.

20. NodeJS
• Nonblocking para requisições;
• Assíncrono para requisições externas;
• Multi conexões, single thread;
• Utiliza V8 Engine.

21. uWSGI
• Baseado no WSGI (python only);
• Suporta várias linguagens (Perl, Python, Ruby…);
• Suporte a Rack Application based;
• Nonblocking para requisições;
• Assíncrono para requisições externas;
• Altamente configurável (multi thread, blocking I/O, síncrono…);
• Integrável com Nginx nativamente.

22. Conclusão
• Não existe a melhor fórmula;
• Cada caso pede um App Server diferente;

23. Fim
Obrigado pela atenção! =)