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! =)