ott 152011
 

Questo è un mio articolo già pubblicato su wazi

Avete problemi nel servire più di due pagine al secondo sul vostro blog WordPress o Drupal?  I siti dei vostri concorrenti servono le pagine più velocemente di voi? La loro arma segreta potrebbe essere una combinazione di web server e PHP da Apache e mod_php. Ma non preoccupatevi - potete rivolgervi a una di queste soluzioni alternative anche voi, e migliorare le prestazioni del server web senza aggiornare le risorse hardware.

In primo luogo, una descrizione generale. Un server HTTP o web server  invia ai browser una pagina richiesta, di solito in codice HTML, o una pagina creata dinamicamente con un linguaggio come PHP, uno dei linguaggi di programmazione più comuni per le pagine web. Il linguaggio di scripting PHP assomiglia a JavaScript, Java e Perl, e tutti condividono un antenato comune, il linguaggio di programmazione C. Se avete bisogno di inserire del testo dinamico, come ad esempio il risultato di una query su database, all’interno del testo statico, troverete PHP estremamente utile.


Uno dei più antichi server web esistenti, e il più popolare, Apache, ha percorso una lunga strada da quando è stato rilasciato nel 1995. Tecnicamente, Apache è costituito da un demone su Unix o un servizio in Microsoft Windows, che, a seconda delle impostazioni nei file di configurazione, consente di accedere a uno o più siti (Virtual Host), gestisce le funzioni di sicurezza, e può ospitare le estensioni per servire pagine attive o dinamiche, come PHP o,per gli sviluppatori Java, permette di comunicare con Tomcat.

Un server HTTP Apache può essere configurato per operare in due modi. Multi-Processing Module Prefork (MPM prefork) implementa un web server non-threaded, pre-forking che è appropriato per i siti che hanno bisogno di evitare di creare thread per la compatibilità con le biblioteche non-thread-safe. Generalmente, qualsiasi modulo non banale  di Apache (come mod_php, un modulo che Apache può caricare per servire pagine dinamiche PHP) ha del codice non-thread-safe o vi sono librerie non-thread-safe richiamate da esso, quindi per non avere dubbi utilizziamo la modalità prefork MPM. In molte distribuzioni, tra cui Debian e Red Hat, quando si installa mod_php il sistema installa automaticamente la versione prefork MPM del pacchetto Apache. MPM prefork è anche il miglior MPM per isolare ogni richiesta, in questo modo un problema con una singola richiesta non influenzerà tutti gli altri. Una richiesta corrisponde generalmente ad un singolo processo su un server Linux.

Al contrario, Multi-Processing Module Worker (MPM worker)  implementa un server ibrido multi-processo multi-thread. Utilizzando i thread per servire le richieste, è in grado di servire un gran numero di richieste utilizzando meno risorse di sistema di un server basato sui processi. Tuttavia, mantiene gran parte della stabilità di un server basato sui processi, mantenendo più processi disponibili, ognuno con molti thread.

HTTP server alternativi

Apache è il motore per oltre il 70% dei siti web, ma nuove alternative stanno guadagnando quote di mercato. Apache è un server affidabile, ma ci vuole una notevole quantità di memoria per eseguirlo.In alcune situazioni altri web server sono in grado di fare meglio. Le più note alternativa open source come server HTTP sono lighttpdnginx e Cherokee.

webservers

Market Share per i Top Servers su tutti i domini daAugust 1995 a July 2011 (Source: Netcraft)

lighttpd è un web server sicuro, veloce, compatibile, flessibile e ottimizzato per gli ambienti ad alte prestazioni. Ha un ingombro di memoria molto basso rispetto ad altri web server, e di solito anche un basso carico della CPU. Ha un set di funzioni avanzate che includono il bilanciamento del carico FastCGI, CGI, Auth, compressione-output, URL Rewriting, SSL, e altro ancora.

nginx è un server proxy per HTTP e per i servizi di posta. E ‘ utilizzato da più di due anni su molti siti russi molto visitati, ed è diventato più popolare nel resto del mondo, al punto che oggi è utilizzato dal 6,5% di tutti i siti web.

Cherokee è un web server veloce, flessibile e facile da configurare che supporta FastCGI, SCGI, PHP, CGI, TLS e SSL , virtual host, autenticazione, codifica al volo, il bilanciamento del carico, file di log compatibili con Apache  e altro ancora. Fornisce anche una  interfaccia web di configurazione facile da usare che consente di configurare il server da cima a fondo senza modificare un file di testo.

Se si sta per costruire un nuovo sito da zero, quale server web si dovrebbe utilizzare? Ciascuno di questi server ha dei pro e dei contro, come vedremo più avanti. È necessario pesare i vostri requisiti e necessità con le caratteristiche e le capacità di ogni server, ed anche la vostra conoscenza di ciascuno. Molte persone conoscono molto bene Apache e lo utilizzano per ogni sito. Questa non è una cattiva idea, ma se state progettando un sito con caratteristiche particolari forse un altro server web potrebbe essere migliore.

Asincrono contro Sincrono

I Server Web possono essere suddivisi in due categorie, asincroni (lighttpd e nginx) e sincroni (Apache e Cherokee). Il principale vantaggio del metodo asincrono è la scalabilità. In un server sincrono o basato sui processi, ogni connessione simultanea richiede il proprio thread, che comporta un overhead significativo. Un server asincrono, invece, è event-driven e gestisce le richieste in un unico (o almeno, molti pochi) thread.

Mentre i server di basati sui processi spesso svolgono il proprio lavoro alla pari con i server asincroni in presenza di carichi leggeri, è sotto carichi più pesanti che di solito consumano troppa RAM, cosa che degrada in modo significativo le prestazioni. Inoltre, si degradano molto più velocemente su hardware meno potente o in ambienti con risorse limitate come i virtual private server (VPS).

Mod_php vs. FastCGI

Il metodo più comune per elaborare le pagine PHP sotto Apache avviene tramite mod_php, il modulo PHP. mod_php viene caricato all’avvio del server, ed elabora le pagine PHPall’interno di un unico processo genitore, ma ogni processo che è lanciato dal genitore (siamo in modalità sincrona) deve caricare lo stack completo, utilizzando più memoria. Per evitare questo, è possibile configurare il server web per elaborare PHP attraverso un processo esterno. Il FastCGI daemon processa le richieste e restituisce i risultati al server web, in contrasto con classici CGI, dove è lanciato un processo shell da processo figlio di Apache, cosa che è meno efficiente e lenta. PHP-FPM (Process Manager FastCGI) è una implementazionealternativa di PHP FastCGI con alcune funzioni utili per i siti di qualsiasi dimensione e specialmente per i siti particolarmente frequentati.

PHP-FPM è destinato principalmente ai siti web gravati da numerose richieste HTTP. E’ possibile lanciare più pool di processi FastCGI in ascolto su porte separate per soddisfare le esigenze di ambienti virtuali multi-dominio in hosting. Offre inoltre:

  • Processo di gestione avanzato con possibilità di fare uno stop/start controllato.
  • La possibilità di avviare lavoratori con differenti uid/gid/chroot/ambienti e impostazioni di php.ini diverse (sostituisce safe_mode)
  • Registrazione di stdout e stderr .
  • Riavvio di emergenza in caso di distruzione accidentale della opcode cache
  • Supporto per l’upload accelerato.
  • Supporto per lo “slowlog” che registra le pagine che richiedono troppo tempo per essere completate
È possibile utilizzare PHP-FPM come back-end a qualsiasi server web e non essere più legati ad Apache in modalità MPM-prefork. Un altro vantaggio ha a che fare con mod_php, che è eseguito in un processo che richiede una quantità di solito di grandi dimensioni di memoria, perché contiene non solo PHP, ma anche tutti gli altri moduli di Apache. Se PHP viene eseguito in un processo separato, tale processo può avere una vita più breve, e passare rapidamente i risultati all’Apache quando il PHP è eseguito.

Nginx più PHP-FPM

Gli amministratori di sistema che conoscono i pro ed i contro di  Apache  potrebbe desiderare di provare un approccio alternativo per un server web, sia per meglio soddisfare le esigenze dei visitatori del sito che per mantenere le loro competenze tecniche fresche. La combinazione di nginx con PHP-FPM sta diventando popolare in ambienti che hanno a disposizione basse quantità di memoria disponibile (VPS di solito) o grandi siti che devono elaborare molte richieste simultanee. E ‘ un ottimo sostituto per mod_php ed Apache.

Se volete provare anche voi  questa configurazione, ecco alcuni consigli. Una piccola nota– in Debian io suggerisco di usare il repository dotdeb.org  per avere una versione recente di questi pacchetti. Per CentOS potete aggiungere IUS repository ed installare i pacchetti con yum:

#EPEL
wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/epel-release-1-1.ius.el5.noarch.rpm
#IUS Community
wget http://dl.iuscommunity.org/pub/ius/stable/Redhat/5/x86_64/ius-release-1.0-6.ius.el5.noarch.rpm
#Install repos
rpm -Uvh epel-release-1-1.ius.el5.noarch.rpm ius-release-1.0-6.ius.el5.noarch.rpm

vi /etc/yum.repos.d/ius.repo
#Comment out this line:
mirrorlist=http://dmirr.iuscommunity.org/mirrorlist?repo=ius-el5&arch=$basearch
#Add this line:
baseurl=http://dl.iuscommunity.org/pub/ius/stable/Redhat/5.5/$basearch

#IUS PHP 5.3 packages are prefixed with "php53u" to avoid name clashes
yum install php53u-fpm 

#Use EPEL nginx. 
yum install nginx

Configurazione PHP-FPM

Il file di configurazione principale di PHP-FPM, di solito si trova in /etc/php5/fpm/php-fpm.conf ,consente di impostare le configurazioni generiche per tutte i pool. Un pool di nginx è un insieme di processi che servono uno o più host virtuali, ogni pool ha una serie di processi iniziali ed un numero massimo. I processi condividono lo stessa uid e gid e connessioni al database. Di solito si può lasciare intatto questo file di configurazione e basta creare un file in /etc/php5/fpm/pool.d/YOURPOOL_NAME.

Ecco un esempio di file di configurazione di setup per una macchina di piccole dimensioni - ovvero con meno di 1024 MB di RAM.
In questo esempio ho chiamato il mio pool www-linuxaria:

; Start a new pool named 'www'.
; the variable $pool can we used in any directive and will be replaced by the
; pool name ('www' here)
[www]

; The address on which to accept FastCGI requests.
listen = 127.0.0.1:9000

; Unix user/group of processes - put your webserver user/group here
user = www-data
group = www-data

; The number of child processes to be created when pm is set to 'static' and the
; maximum number of child processes to be created when pm is set to 'dynamic'.
; This value sets the limit on the number of simultaneous requests that will be
; served. Equivalent to the ApacheMaxClients directive with mpm_prefork.
pm.max_children = 20

; The desired minimum number of idle server processes.
pm.min_spare_servers = 2

; The desired maximum number of idle server processes.
pm.max_spare_servers = 10

; The number of requests each child process should execute before respawning.
; This can be useful to work around memory leaks in third-party libraries. 
pm.max_requests = 500

; The timeout for serving a single request after which the worker process will
; be killed. 
request_terminate_timeout = 30

Opzionalmente si possono attivare queste opzioni:

; The URI to view the FPM status page. If this value is not set, no URI will be
; recognized as a status page.
pm.status_path = /status

; The ping URI to call the monitoring page of FPM. If this value is not set, no
; URI will be recognized as a ping page. This could be used to test from outside
; that FPM is alive and responding.
ping.path = /ping


Configurazione di Nginx

Il file principale di configurazione di nginx di solito si trova in /etc/nginx/nginx.conf. Qui di seguito ci sono alcune direttive di configurazione suggerite per la stessa macchina di piccole dimensioni, ovverocon meno di 1024 MB di RAM:

#user and group of Nginx processes
user       www www;

#A worker process is a single-threaded process.
#If Nginx is doing CPU-intensive work such as SSL or gzipping and you have two or more CPUs/cores, you may set 
#worker_processes to be equal to the number of CPUs or cores. In this example we have four cores.
worker_processes  4;

#Generic error log for the web server
error_log  /var/logs/nginx/error.log;

#Location of your pid file
pid        /var/run/nginx.pid;

#Activate Events module
events {

#The worker_connections and worker_proceses from the main section allows you to calculate maxclients value:
#max_clients = worker_processes * worker_connections 
        worker_connections 768;
}

I file qua sopra fornisce le configurazioni generiche per tutti i vostri siti. Si dovrebbe anche avere un file per ogni sito attivo. Di solito io utilizzo per tale file il nome completo del sito, ad esempio,sul mio server Debian ho il file /etc/nginx/sites-enabled/linuxaria.com, con impostazioni simili a queste:

server {

#The listen directive tells nginx where to listen in ipv4 and ipv6 for incoming connections.
    listen 80;
    listen [::]:80 ipv6only=on;

#Server name is your web server URL.
    server_name www.linuxaria.com linuxaria.com;

#root specifies the document root for requests.
    root /srv/www/linuxaria.com/public_html;

    ...

#Inside this location you can see how all .php files are processed. 
#We give the address of the php-fpm server (localhost:9000).
    location ~ .php$ {
                include /etc/nginx/fastcgi_params;
                fastcgi_pass  127.0.0.1:9000;
                fastcgi_index index.php;
                fastcgi_param  SCRIPT_FILENAME  /srv/www/linuxaria.com/public_html$fastcgi_script_name;

Questi file dovrebbero aiutare a configurare il servizio di base con nginx e PHP-FPM. Se ci si sposta da Apache a nginx le cose più difficili da ”convertire” di solito sono le regole di riscrittura ed i .htaccess. Guardare la wiki ufficiale con la documentazione di nginx e utilizzare questo sito per convertire automaticamente i vostri Apache .htaccess in regole nginx.

Conclusioni

Naturalmente nginx con PHP-FPM è solo un approccio per servire velocemente le pagine PHP.  Sono molte le possibili combinazioni di server HTTP, server cache e back end a disposizione. Se non siete sicuri di quali potrebbero essere adattia voi, si può provare a chiedere gli esperti del nginx forum, nginx planet, o il canale nginx IRC, o ricercare casi di studio simili ai vostri. Alcune guide utili sono:

Popular Posts:

flattr this!

 Leave a Reply

(required)

(required)


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>