Nginx vs Apache - Esistono confronti e statistiche sull'utilizzo effettivo?


45

Ho un nuovo server con cui giocare e sto fissando una tela bianca. Posso mettere tutto quello che voglio su di esso. Mentre mi sento a mio agio con Apache, continuo a sentire come nginx è in grado di gestire un traffico molto maggiore di Apache, con fattori di 10, 100 e anche di più. Non solo è "molto più veloce".

Quando cerco articoli, riesco a trovare molte cose estranee a Drupal. Oppure, quando trovo un articolo relativo a Drupal, è 1) il file di configurazione di qualcuno con un rapido tentativo di spiegare come configurarlo, oppure 2) è qualcuno che dice "no, non usare nginx, vai con Apache con PHP fcgid "ma non c'è mai una spiegazione del perché.

Quindi, quando si tratta di Drupal, qual è la realtà qui?

Ad esempio, sto cercando qualcosa sulla falsariga di questo articolo di 2bits.com . Qui l'autore ha dato uno sguardo piuttosto ampio ad Apache mod_php vs Apache con fcgid, valutando i pro ei contro di ciascuno, e fornito un case study per illustrare l'impatto nel mondo reale. Ci sono abbastanza informazioni in questo articolo per farmi prendere una decisione consapevole su quale approccio sarebbe meglio per la mia situazione.

Mentre quell'autore confronta mod_php con fcgid, sto cercando lo stesso tipo di sguardo completo e reale su Apache vs Nginx.

Qualcuno è passato a Nginx ed è stato "spazzato via" dalla differenza che ha fatto rispetto ad Apache? Anche per ambienti altamente ottimizzati che stanno già utilizzando APC, Memcache e la cache aggressiva come Varnish, quando l'unica variabile che cambia è la sostituzione di Apache con Nginx, fa abbastanza la differenza da sola per meritare di investire in questa nuova tecnologia alternativa ?

Il sito che andrà su questo server ottiene una media di 2 milioni di PV al mese. Stack LAMP con Cent OS 6. CPU a 4 core con 8 GIGS di RAM. Memcached e APC faranno parte del mix. Niente di speciale sull'installazione di Drupal - fondamentalmente vanilla 7 con circa 50 moduli.


2
Se si desidera ottimizzare un determinato sito per le prestazioni, è meglio eseguire i propri test piuttosto che fare affidamento sul lavoro di altre persone. Il mix di utenti anonimi e utenti connessi, ad esempio, è un fattore importante. Se guardi le statistiche sulle prestazioni di un sito che ottiene traffico prevalentemente anonimo e il tuo non è così, potresti non preoccuparti. Ma se il tuo sito ha un traffico in gran parte anonimo, nella mia esperienza mettere Varnish davanti al tuo server web fa una differenza molto maggiore rispetto al server che esegui dietro di esso.
Alfred Armstrong,

Risposte:


60

A rigor di termini, questo non risponde alla domanda che stai ponendo. Spero comunque sia utile.

Apache / Nginx / Lighttpd / altro web server. Importa quale scelgo? In breve, no .

La risposta molto più lunga:

Se e solo se, hai una percentuale molto grande dei tuoi utenti che hanno effettuato l'accesso, se ti preoccupi delle prestazioni del tuo server web. Se i tuoi utenti sono anonimi, qualsiasi differenza che puoi teoricamente derivare dall'ottimizzazione a quei livelli impallidisce rispetto a rendere le tue risorse meglio memorizzabili nella cache. Se i tuoi file css hanno intestazioni di cache adeguate su di essi, UA non li chiederà nemmeno per la seconda volta. Quello che conta. Se riesci a memorizzare nella cache le tue pagine in Varnish o in una soluzione software simile, allora servire quella pagina è una questione di fare una ricerca di hash e quindi restituire una grande quantità di dati direttamente dalla RAM. Quello che conta. In entrambi questi scenari, il demone HTTP non viene mai coinvolto, PHP non viene invocato. Drupal non si avvia. Nessun set di moduli di grandi dimensioni deve essere caricato nella RAM, non vengono eseguite query di database che richiedono tempo.

Quando si esegue un caricamento di pagina intera, da una cache fredda, per un utente connesso, su una pagina complessa; stanno succedendo molte cose. Sì, il web server è coinvolto nella gestione della richiesta in arrivo, nell'impostazione di alcune intestazioni e nel ritorno della risposta. Ma il tempo necessario, non è nemmeno rilevante nel contesto di Drupal che esegue un bootstrap completo e produce la sua risposta. Potrebbero essere eseguite centinaia di query sul database. La logica altamente complessa in PHP viene valutata dal parser. Molti moduli vengono caricati nella RAM. Migliorare le prestazioni di una di queste cose è molto più probabile che fornisca un contributo serio alle prestazioni.

Per ragioni di argomento: supponiamo che tu abbia speso molto tempo a ottimizzare le prestazioni di tutto il resto.

  1. Esegui APC (o Optimizer + ) e la versione più recente e più veloce di PHP.
  2. Le query DB sono poche.
  3. La logica di PHP è stata ridotta.
  4. Metti in cache ciò che puoi in Varnish.
  5. Hai ri-strutturato il tuo intero sito in modo da poter memorizzare nella cache molto lato client e fare molto lavoro pesante in ECMAScript .

Se hai molti utenti che hanno effettuato l'accesso e hai trattato di tutto quanto sopra, probabilmente puoi fare la differenza ma ottimizzare le prestazioni o sostituire il tuo server web. Tuttavia, indovina un po '. Il tuo sito è così complesso e le modalità di utilizzo dei tuoi utenti particolari sono uniche . Non esiste una risposta generica. Dovrai configurare tutti i diversi server Web dietro un bilanciamento del carico e vedere come si comportano, nel tuo scenario .

Quanto sopra è stato un tentativo di giungere logicamente alla conclusione che impiegare tempo a ottimizzare le prestazioni del web server è probabilmente un cattivo uso del tempo. Mi piacerebbe che qualcuno facesse dei buchi in quanto sopra, probabilmente imparerei qualcosa di nuovo da esso. :)

Alcune altre note:

  1. Durante il keynote di DrupalCon Copenhagen , il creatore di PHP Rasmus Lerdorf , usando lo stesso Nginx, parlando dell'argomento delle prestazioni di Drupal, ha dichiarato: "Le persone mi chiedono sempre dei server Web ... non importa, il server Web è praticamente irrilevante" . (Circa alle 26:30 nel video)
  2. Facebook ha trascorso innumerevoli ore a scrivere Hiphop , una base di codice significativamente più grande di Drupal stesso, per accelerare il codice PHP di un "misero" 100%. Ho esaminato Hiphop con $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1e ho scoperto che consisteva in 1.512.481 righe di codice. Questa è una quantità assolutamente folle di lavoro svolto per migliorare la velocità di PHP. Immagino che sia perché la velocità di PHP conta molto per loro.
  3. Ho già detto che una buona memorizzazione nella cache avrà un effetto molto maggiore rispetto all'ottimizzazione del server Web?
  4. Con il rilascio di Apache 2.4, Jim Jagielski afferma sostanzialmente che Apache 2.4 è più veloce dei server basati su eventi .
  5. Ho attirato Drupal Performance e Scalabilità con The Dream Team , dove è emersa solo questa domanda. Tutte le risposte su cui scegliere, non erano correlate alla performance. Cose come "Quale sai già come configurare" e "Quale ti consentirà di costruire lo stack tecnologico più semplice", sono stati tra i motivi citati per andare avanti rispetto all'altro. La performance non è entrata nell'immagine.

4
Non dimenticare CDN per impedire che la stragrande maggioranza di richieste CSS, JS e di immagini colpisca mai il web server.
mpdonadio

Punto eccellente! Penso che dovrò riscrivere drupal.stackexchange.com/questions/24180/… ad un certo punto. Una discussione su Apache / Nginx non sembra il luogo ottimale per creare un elenco completo di ottimizzazioni delle prestazioni.
Letharion,

1
Questa è un'ottima risposta Un solo pignolo: non dovresti usare "ECMAScript" e "JavaScript" in modo intercambiabile. JavaScript è molto più di ECMAScript.

Stai dicendo che la cache è di gran lunga più importante della velocità del server web. Indovina un po? Se un server Web utilizza meno memoria dell'altro, è possibile utilizzare più RAM per la memorizzazione nella cache. Quindi possiamo dire che è importante ottimizzare il tuo server web in modo che non consumi tutta la tua RAM, giusto?
pqnet,

Ottimizzare il server per utilizzare meno RAM va assolutamente bene, ma se stai cercando di andare in un territorio ad alte prestazioni probabilmente eseguirai la vernice su un server dedicato, quindi il tuo server http e la cache non saranno in competizione per la stessa memoria.
Letharion,

32

OK, anche se a questa domanda è già stata data una risposta, sto negando ancora una volta, principalmente perché non mi piacciono le implicazioni di queste risposte che non fa differenza, e perché come sviluppatore web odio la memorizzazione nella cache con passione .

La differenza tra Apache e nginx non è tanto "quanto velocemente possono servire una richiesta" ma quante richieste possono servire sulla stessa quantità di hardware (specialmente con risorse limitate), che è una cosa leggermente diversa.

Apache è un server basato su processi. Significa che forgia un processo per ogni richiesta. Nginx è un server basato su eventi, il che significa che utilizza un loop di eventi (asincrono) anziché processi o thread.

E mentre un server basato su processo (come Apache) può eseguire più o meno alla pari con un server asincrono basato su eventi (come nginx) con carichi leggeri, con carichi più pesanti come ad esempio 10'0000 richieste simultanee, nginx ne utilizza solo alcune megabyte di RAM, mentre Apache richiede diverse centinaia di megabyte per il solo server Web (esclusa l'applicazione Web, che ha bisogno di molte più risorse), se possibile.

Quindi, sotto carichi più pesanti, vedrai che Apache consuma troppa RAM, il che non sorprende in modo significativo le prestazioni.

Più significativamente, un consumo di RAM più elevato significa che Apache è in grado di servire meno richieste sullo stesso hardware di nginx, il che significa che Apache richiede più hardware per lo stesso numero di utenti, il che significa che hai un TCO più elevato (costo totale di proprietà) con Apache che con nginx, il che riduce il ROI (ritorno sull'investimento).

Memoria totale utilizzata da X connessioni simultanee (meno è meglio)

Utilizzo della memoria

Richieste che possono essere soddisfatte al secondo su X connessioni simultanee su 1 set di hardware (più è meglio)

Richieste al secondo

Fonte: ApacheBench, di dreamhost.com

Vedi anche questo scritto sull'oceano digitale .
Apparentemente, dipende dall'architettura di gestione delle connessioni scelta per Apache.


6
Ti colpisci in testa con "... non quanto velocemente possono soddisfare una richiesta, ma quante richieste possono servire sulla stessa quantità di hardware ..." In effetti, alla fine, voglio ottenere il massimo profitto per il mio dollaro . Data una macchina con lo stesso identico hardware e altre variabili, se posso servire 1.000.000 di utenti al giorno con nginx dove apache potrebbe servire solo 200.000, allora sicuramente la scelta migliore dal punto di vista dei costi è nginx. Data una certa configurazione hardware, hai visto una grande differenza tra ciò che nginx può fare rispetto ad Apache?
blue928,

2
Apache 2.4, la versione corrente, ha un modello basato sugli eventi: httpd.apache.org/docs/current/mod/event.html
Greg

1
Inoltre, per coloro che affermano che non importa perché "andrà bene finché si memorizza nella cache roba": sai cosa devi fare per la memorizzazione nella cache? Hai bisogno di RAM GRATUITA.
pqnet,

Vedo spesso queste affermazioni generali di "Nginx è più fantastico", tuttavia raramente (mai?) Vedo qualcuno sostenerlo con prove concrete. È sempre "La mia istanza nginx altamente configurata ha battuto un server Apache di serie, quindi ora ho dimostrato di essere bravo perché uso nginx come gli altri fighi". Nginx potrebbe essere di gran lunga migliore di Apache per quello che ne so, ma devo ancora vedere qualcuno mostrare davvero che è così.
Letharion,

@Letharion: Fatto (da dreamhost.com) e aggiunto secondo la tua richiesta. Come puoi vedere nei risultati di questo benchmark, nginx è chiaramente più efficiente in termini di memoria. Inoltre è probabilmente: la mia istanza di stock-nginx ha battuto la mia istanza di stock Apache sullo stesso benchmark sullo stesso computer.
Quandary

16

Passo da Apache a Nginx / PHP-FPM qualche mese fa.

Ho realizzato un banco con un sito Web Drupal e testato diversi casi d'uso. Su un server VPS con 1 CPU e 512 Mo RAM

Drupal con solo cache

nginx

ab -n 100 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.775 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2529500 bytes
HTML transferred:       2490200 bytes
Requests per second:    36.04 [#/sec] (mean)
Time per request:       832.394 [ms] (mean)
Time per request:       27.746 [ms] (mean, across all concurrent requests)
Transfer rate:          890.28 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 48.946 s

Connection rate: 2.0 conn/s (489.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 470.6 avg 489.5 max 522.2 median 488.5 stddev 9.5
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 10.000

Request rate: 20.4 req/s (48.9 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 20.0 avg 20.4 max 20.8 stddev 0.2 (9 samples)
Reply time [ms]: response 46.8 transfer 2.1
Reply size [B]: header 450.0 content 24902.0 footer 2.0 (total 25354.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.50 system 17.58 (user 13.3% system 35.9% total 49.2%)
Net I/O: 507.3 KB/s (4.2*10^6 bps)

Apache

ab -n 100 -c 30 xxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   28.364 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25346000 bytes
HTML transferred:       24902000 bytes
Requests per second:    35.26 [#/sec] (mean)
Time per request:       850.918 [ms] (mean)
Time per request:       28.364 [ms] (mean, across all concurrent requests)
Transfer rate:          872.66 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 52.261 s

Connection rate: 1.9 conn/s (522.6 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 499.0 avg 522.6 max 591.0 median 518.5 stddev 19.4
Connection time [ms]: connect 0.6
Connection length [replies/conn]: 10.000

Request rate: 19.1 req/s (52.3 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 18.2 avg 19.2 max 19.6 stddev 0.5 (10 samples)
Reply time [ms]: response 46.9 transfer 5.3
Reply size [B]: header 453.0 content 24902.0 footer 2.0 (total 25357.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.80 system 18.88 (user 13.0% system 36.1% total 49.1%)
Net I/O: 475.2 KB/s (3.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Drupal con cache e boost

nginx

ab -n 10000 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   2.275 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      253780000 bytes
HTML transferred:       250020000 bytes
Requests per second:    4395.52 [#/sec] (mean)
Time per request:       6.825 [ms] (mean)
Time per request:       0.228 [ms] (mean, across all concurrent requests)
Transfer rate:          108934.95 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 5.971 s

Connection rate: 167.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 13.0 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 5024.0 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 5017.2 avg 5017.2 max 5017.2 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.79 system 2.56 (user 13.2% system 42.9% total 56.1%)
Net I/O: 125016.7 KB/s (1024.1*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Apache

ab -n 1000 -c 30 xxxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   0.753 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25291000 bytes
HTML transferred:       25002000 bytes
Requests per second:    1327.92 [#/sec] (mean)
Time per request:       22.592 [ms] (mean)
Time per request:       0.753 [ms] (mean, across all concurrent requests)
Transfer rate:          32797.26 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 1.148 s

Connection rate: 87.1 conn/s (11.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 6.2 avg 11.5 max 14.1 median 11.5 stddev 1.3
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 10.000

Request rate: 870.8 req/s (1.1 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 1.1 transfer 0.1
Reply size [B]: header 260.0 content 25002.0 footer 0.0 (total 25262.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.13 system 0.57 (user 11.1% system 49.5% total 60.6%)
Net I/O: 21544.9 KB/s (176.5*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

benchmark per utente autenticato (caricamento della pagina)

nginx

Page load times : 2.85 s

Apache

Page load times : 5.4 s

Ma la potenza di Nginx è il sistema cache

Drupal senza Boost e Nginx con il sistema cache abilitato

Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.437 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      252670000 bytes
HTML transferred:       249020000 bytes
Requests per second:    4103.34 [#/sec] (mean)
Time per request:       7.311 [ms] (mean)
Time per request:       0.244 [ms] (mean, across all concurrent requests)
Transfer rate:          101248.99 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 6.044 s

Connection rate: 165.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 11.7 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 4963.7 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 4970.1 avg 4970.1 max 4970.1 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.72 system 2.68 (user 12.0% system 44.3% total 56.3%)
Net I/O: 123516.8 KB/s (1011.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Dovresti usare la configurazione del perusio Nginx per Drupal


Come funzionava Apache, preforme, FCGI, ecc.? La tua configurazione di Apache è stata ottimizzata il più possibile quando hai eseguito questi test? Era in esecuzione esattamente lo stesso ambiente PHP?
mpdonadio

L'ambiente PHP (5.3) era esattamente lo stesso. Apache stava eseguendo mpm_prefork e la configurazione di apache (maxclient, MaxSpareServers, MaxRequestsPerChild, ecc.) Era esattamente la stessa di PHP5-FPM
flocondetoile

4
Questi sono buoni numeri, ma non sono sicuro che siano un vero confronto. Apache + FastCGI vs Apache + FCGI + PHPFPM vs Nginx + PHPFPM mostrerebbero meglio le differenze tra Apache e Nginx.
mpdonadio

Come sottolinea MPD, questo non è un vero confronto. È necessario eseguire php-fpm su entrambi per ottenere un'immagine reale.

1
Nginx è una buona scelta per gli account VPS con RAM limitata, credo. Dato che può funzionare comodamente con un footprint RAM inferiore rispetto ad Apache - specialmente se si mantengono disinstallati moduli non necessari - è rimasta più RAM per eseguire cache opcode (OpCache integrata di APC o PHP 5.5), fornire il server MySQL / Postgres demone un grosso buffer, e anche altre ottimizzazioni che giustamente Letharion sottolinea sono importanti.
Garrett Albright,

0

Ecco un test delle prestazioni per dieci server web / vari (es. Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). Tre dei test riguardano Drupal.

Sto pensando che Hiawatha potrebbe essere la scelta migliore. Si suppone che abbia piena compatibilità con Drupal , enfasi sulla sicurezza (DoS, XSS, CSRF, prevenzione delle iniezioni SQL) e velocità e impronta simili a Nginx.

In due dei tre test Drupal, sia Hiawatha che Nginx hanno superato Apache di circa il 150%, ma nel test statico Drupal, Apache ha superato leggermente Nginx, mentre Hiawatha ha superato il pacchetto di circa il 10%.

Non appenderei il cappello a nessuno di questi test, ma offre una visione a sfera delle prestazioni in diverse situazioni di utilizzo. Penso che le prestazioni da sole non dovrebbero essere l'unica considerazione. Stabilità e sicurezza possono essere i fattori più importanti.


0

ecco i risultati di un test di carico per drupal in esecuzione sullo stesso hardware ma con server Web diversi. (nginx e apache)

ecco la conclusione di questo test:

sotto un traffico intenso con le stesse risorse hardware, nginx ha prestazioni migliori di apache.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.