Post on 30-Jul-2015
Application Server
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.
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.
CGI Code#!/usr/bin/perl print "Content-type: text/plain\r\n\r\n"; for my $var ( sort keys %ENV ) { printf "%s = \"%s\"\r\n", $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"
CGINem 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.
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.
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
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.
SocketBlocking I/O
SocketNonblocking I/O
SocketAssíncrono
SocketSignal-driven I/O
RubyApplication Servers
• Unicorn;
• Phusion Passenger;
• Puma;
• Webrick.
Unicorn• Rack based;
• Modelo Blocking I/O para requisições;
• Múltiplos Processos pré forked;
• Single Thread;
• Necessita um proxy reverso a sua frente.
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.
Puma• Rack based;
• Blocking I/O para requisições;
• Múltiplos processos;
• Multi-threading;
• Necessita um proxy reverso a sua frente.
Mundo afora• SCGI;
• Web server módulos;
• NodeJS;
• uWSGI
SCGI• Baseado em FastCGI;
• Implementação mais fácil;
• Importante na criação de futuros App Servers como WSGI e uWSGI.
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.
NodeJS• Nonblocking para requisições;
• Assíncrono para requisições externas;
• Multi conexões, single thread;
• Utiliza V8 Engine.
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.
Conclusão• Não existe a melhor fórmula;
• Cada caso pede um App Server diferente;
Fim
Obrigado pela atenção! =)