Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Apache VS Nginx Giuliano

Comparsion between Apache Web Server and Nginx Software Architectures
by

Luca Giuliano

on 30 May 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Apache VS Nginx Giuliano

Web Server Software Architecture Web Server Struttura Come è fatto un Web Server?

Un Web Server gestisce le richieste da parte di client (tipicamente browser) utilizzando il protocollo HTTP per la comunicazione.

Le richieste solitamente comprendono la richiesta di file, accesso a database e a contenuti multimediali, richieste di connessioni crittografate, ecc.

Tipica comunicazione tra client e server. Apache Web Server VS nginx Funzioni implementate da un Web Server Le funzioni implementate da un web server sono principalmente:

I protocolli di comunicazione (TCP/IP, HTTP, UDP)
Controlli di sicurezza e degli accessi
Gestione delle sessioni
Gestione dei contenuti dinamici Autenticazione e controllo delgli accessi L’autenticazione è il processo di verificare se qualcuno è effettivamente “chi dice di essere”, mentre autorizzazione significa controllare se ad una persona o una macchina identificata è consentito accedere a una risorsa.

I meccanismi si possono implementare in vari modi:
Accesso tramite UserID e Password
Certificati
Meccanismi di controllo degli accessi Apache HTTPD Web Server Nginx Contesto e Descrizione L'Apache Web Server è il web server più conosciuto nel panorama di internet.
Implementato dall'Apache Web Foundation e dalla comunità open-sources, fornisce l'implementazione dell'architettura tipica di un web server. Struttura L'apache Web Server è generalmente strutturato da due processi: il Master Server e i Child Server.

Il Master Server ha il compito di instanziare (utilizzo di una fork() ) l'esecuzione di nuovi Child Server, di leggere la configurazione di questi e mantenerli attivi all'interno di un loop-run di esecuzione.

Un Child Server ha il compito attendere una richiesta, attraverso un canale di connessione instaurato, di servire la richiesta e chiudere la connessione. Funzioni e Comportamento L'Apache Web Server ha due tipi di implementazioni, le così dette MPM (Multi Processing Module): Worker e Preforker.

Ogni implementazione si basa sulla gestione e creazione di processi multipli di Server Child.

Ogni Server Child a sua volta imlementa le funzioni per gestire le connessioni e le richieste pervenute al processo Child che è in ascolto di quella determinata porta. Worker Vengono creati vari processi Child Server di Apache, ognuno dei quali può contenere più thread, che a loro volta possono servire più connessioni. Questa modalità di esecuzione utilizza un quantitativo modesto di memoria.
La modalità MPM Worker, in virtù dell’utilizzo dei thread multipli, è molto adatta a sistemi multiprocessore.
Apache, in modalità MPM Worker, avvia il numero di processi figli indicati nella direttiva StartServers e per ogni processo vengono avviati un numero di threads in accordo con il valore indicato in ThreadsPerChild.
Ogni thread serve le richieste HTTP finchè raggiunge il numero di richieste massime indicate in MaxRequestsPerChild, dopodichè viene spento e sostituito da un thread nuovo. Preforker Vengono creati vari processi figli di Apache, ognuno dei quali può contenere un solo thread, che a sua volta può servire una sola connessione. MPM Prefork utilizza più memoria rispetto al modulo MPM Worker.
MPM Prefork in virtù dell’utilizzo di thread singoli, è più adatto a sistemi a processore singolo.
Apache, avvia il numero di processi figli indicati nella direttiva StartServers. Ogni processo serve le richieste HTTP finchè raggiunge il numero di richieste massime indicate in MaxRequestsPerChild dopodichè il processo viene spento e sostituito da un processo nuovo. Con MPM Prefork, ogni processo alloca la sua quantità di memoria, risultando più impattante di MPM Worker in termini di utilizzo delle risorse. Razionale L'Apache Web Server rappresenta diversi stili architetturali al suo interno. Si può dire che questo software sia un "ibrido di architetture".

La prima architettura che si può notare è l'architettura Client-Server, dove il componente Client sono le richieste fatte dai browser, mentre il server è identificato dal Child Server.
Si può identificare anche l'architettura Event-Driven, dove ad un evento corrisponde una determinata azione.
Questo è tipico della versione Worker di Apache.

È possibile identificare anche l'architettura a Layer, dove il primo strato è dato dal Master Server, mentre il secondo strato è dato dal Child Server che implementano a loro volta gli strati per la comunicazione e la gestione dei vari componenti. Contesto e Descrizione Nginx è un web server implementato con lo scopo di aumentare le prestazioni e diminuire il carico di risorse di un web server, scritto da Igor Sysoev, system and software engineer russo

Nginx si colloca in uno scenario in cui il minor utilizzo di risorse da parte del web server aumenta le prestazioni di questo, fornendo un web server completo e funzionale sia in ambito privato che aziendale.
Alcuni nomi noti:
Groupon, LivingSocial, Playdom, Zappos, Hulu, TechCrunch, Dropbox, Yandex, WordPress.

Il punto di forza di NGINX, rispetto agli altri server web, sta nella sua architettura software, progettata per poter essere utilizzata all’interno di macchine meno recenti grazie ad un utilizzo intelligente delle risorse della macchina. Struttura La struttura di NGINX si basa sull’utilizzo di notifiche di eventi e la gestione asincrona di una serie di azioni connesse con l’accettazione, l’elabora- zione e la gestione delle connessioni di rete e il recupero dei contenuti.

NGINX gestisce due tipi di processi in memoria. Ci sono i worker process, che accettano e gestiscono le connessioni, e un master process unico, che avvia e arresta i worker process e la configurazione dei controlli.

Ogni woker funziona indipendentemente, gestendo le proprie connessioni e dando la possibilità di gestire più connessioni, senza che una sola connessione venga utilizzata per ogni worker. Struttura 2 Le connessioni vengono elaborate da un efficiente loop con un numero limitato di single-thread, i workers.

Ogni worker contiene al suo interno il codice core e i moduli funzionali. Il codice del core è responsabile di mantenere un running loop molto leggero e di eseguire i moduli appropriati per i compiti che gli vengono richiesti.

I moduli in nginx possono essere di vario tipo: core modules, event modules, phase handlers, protocols, variable handlers, filters, upstreams e load balancers

Durante la gestione di una serie di azioni associate con l’accettazione, l’elaborazione e la gestione delle connessioni di rete e il recupero dei contenuti, nginx utilizza meccanismi di notifica di eventi e di operazione di I/O su disco in Linux, Solaris e sistemi operativi basati su BSD, come kqueue, epoll, per poter gestire le richieste pervenute. Funzioni Nginx gestisce diversi processi in memoria, tra cui vi è un processo master unico e diversi processi di tipo worker. Ci sono alcuni processi per usi speciali, in particolare di una cache loading e cache manager.

Il cache-manager è in gran parte responsabile della scadenza della cache e della sua invalidazione.

Il processo cache-loader è responsabile per il controllo delle voci cache su disco e il popolamento del database in memoria di nginx con i metadati della cache
Tutti i processi sono a thread singolo. I processi utilizzano principalmente i meccanismi di memoria condivisa per la comunicazione.
Il processo master viene eseguito come utente root.
Il cache-loader, cache-manager e worker vengono eseguiti come utente senza privilegi. Funzioni 2 Il processo Master è responsabile dei seguenti task:reading and validating configuration
creating, binding and closing sockets
starting, terminating and maintaining the configured number of worker processes
reconfiguring without service interruption controlling non-stop binary upgrades (starting new binary and rolling back if necessary)reopening log files
compiling embedded Perl scripts (and PHP with leatest version) Razionale Se per l’architettura di Apache si era parlato di un misto di stili architetturali, per quanto riguarda nginx si rende pù evidente la strutturazione di tipo Event-driven.

Un client può fare richiesta al server e di conseguenza rispondere alla richiesta fatta, funzionamento simile ad Apache Web Sever, ma in nginx il server stesso aspetta un evento da parte del sistema operativo, in cui ogni chiamata di sistema effettuata dal software genera un evento ed attende un evento da parte del sistema stesso, che scaturirà la risposta da parte del software Conclusioni Mancanze Apache Web Server:
oneroso in termini di risorse e prestazionali
ogni processo deve essere ricreato dal maste server
ad ogni processo è dato l'onere di mantenere la connessione.

Mancanze Nginx:
implementazione per i moduli di linguaggi di script lato server Bibgliografia [1] S. E. . J. M. . W. Z. Emmanuel Cecchet Anupam Chanda. A Comparison of Software Architectures for E-business Applications. 2011 (cit. a p. 2).
[2] R. K. . O. S. Bernhard Grone Andreas Knopfel. The Apache Project Modeling. 2004 (cit. alle pp. 2–8, 11, 12, 14–17).
[3] T. A. S. Foundation. Overview of new features in Apache 2.0. url: https: //httpd.apache.org/docs/2.2/new_features_2_0.html (cit. alle pp. 9– 11).
[4] R. K. Bernhard Grone Andreas Knopfel. Architecture recovery of Apache 1.3 - A case study. 2011 (cit. alle pp. 12, 13).
[5] R. HostingTalk. Ottimizzazione di Apache, dall’analisi ai parametri. 31 Maggio 2010. url: http://www.hostingtalk.it/it/c_000000ut/ottimizzazione- di-apache-dall-analisi-ai-parametri/3 (cit. a p. 15).
[6] O. A. Dragoi. The Conceptual Architecture of the Apache Web Server. January 26, 1999. url: http://www.shoshin.uwaterloo.ca/~oadragoi/cw/CS746G/ a1/apache_conceptual_arch.html (cit. a p. 18).
[7] I. NGINX. What is NGINX? 2012. url: http://nginx.com/papers/nginx- wp.pdf (cit. alle pp. 18–20).
[8] A. Alexeev. The Architecture of Open Source Applications (Volume 2): nginx. 2012. url: www.aosabook.org/en/nginx.html (cit. alle pp. 19, 21–23).
[9] R. Vasan. A Venture Perspective on Cloud Computing. 2011 (cit. a p. 25).
Full transcript