Newsgroup: it.comp.os.linux.sys
Titolo: vantaggi dei web server "veloci" (lighttpd, nginx)+php fast cgi contro il "vecchio" apache

ciao a tutti,
 
dei miei colleghi stanno sudando sette camicie per far funzionare bene 
un sito web molto trafficato (per dare un ordine di grandezza molto 
spannometrico, siamo sui 100 Mbit/s di media) con una soluzione dove 
Nginx serve i contenuti statici e fa eseguire il php a dei fast cgi su 
altri server.
 
Il problema che si riscontra e' che questi fastcgi (e solo loro, non 
gli Nginx o, prima, i lighty) creano un traffico fortissimo verso il 
file server (montato in NFS) che lo mette spesso in crisi, nonostante 
sia una macchina specializzata a gestire l'NFS (e' un netapp).
 
Googlando un po' ho visto che questa soluzione rispetto alla "vecchia" 
con l'Apache con il modulo php sembra avere come vantaggio principale 
quello di un utilizzo efficiente della memoria. Il fatto e' che di 
memoria ne abbiamo in abbondanza mentre il file server e' affogato. 
Quindi mi domando se non sarebbe meglio "sacrificare" la ram per non 
strozzare i dischi.
 
Commenti critiche e suggerimenti ben accetti :)
grazie
 
-- 
Tinto
 
 

 Commenti critiche e suggerimenti ben accetti :)
 
Tenendo MOLTO ben presente che non è possibile dare suggerimenti
affidabili senza conoscere bene l'architettura e le applicazioni che ci
girano, uno dei sistemi per evitare questo tipo di problema è quello
della replica dei file su tutti i frontend attraverso un sistema di
staging. Se non ricordo male ci sono anche sistemi basati su CVS o SVN
per fare tutto in automatico.
 
Chiaramente questo funziona se non hai dati che devono essere scritti
dai vari frontend e resi immediatamente disponibili agli altri.
 
Alternativamente se hai molte scritture e necessiti di sincronia puoi
pensare di implementare un glusterfs; per certi carichi è molto più
performante di nfs, ma appunto dipende dai carichi.
 
Terza soluzione un mix. Raddoppi o quadruplichi il file server
replicando con glusterfs o con drbd su più nodi ed esportando verso i
frontend sempre via NFS ma ovviamente servendo i file da più sistemi.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

Commenti critiche e suggerimenti ben accetti :)
 
Considererei di provare Zend Optimizer, o meglio ancora Zend Server.
 
Leonardo
 
-- 
What would'st thou do, my squire so gay, that rides beside my reine
Were ye Glenallan's Earl this tide, and I were Roland Cheyne?
To turn the rein were sin and shame, to fight were wondrous peril:
What would ye do now, Roland Cheyne, were ye Glenallan's Earl?

 ....
 
ciao, innanzitutto grazie per la risposta, in effetti e' difficile dare 
risposte certe senza conoscere il tutto. Ma e' anche difficile 
descrivere un "tutto" che e' talmente vasto che non c'e' nessuno che lo 
conosca interamente :)
 
Comunque le tue proposte sono simili a quelle che hanno fatto i 
colleghi e che mi lasciano un po' perplesso per vari motivi.
 
Per il glusterfs: non faccia fatica a credere che 3 macchine linux che 
implementano un gfs siano piu' performanti di una con l'nfs. Pero' che 
siano piu' veloci di un sistema operativo+hardware dedicato e 
ottimizzato al 100% per l'nfs e' gia' meno sicuro.
 
Per tenere i php sui dischi locali delle macchine ci sono 
controindicazioni di massima (penso che nessuno sappia effettivamente 
se, e quanti, fra i vari script php scritti da vari personaggi negli 
anni abbiano bisogno che le modifiche scritte siano immediatamente 
replicate per gli altri) e di architettura, perche' i server sono 
macchine virtuali i cui dischi risiedono su un datastore che e' montato 
in nfs e servito da una testa gemella di quella che e' in affanno ;)
 
Comunque giusto per accademia: uno dei siti piu' trafficati del mondo, 
facebook usa php. So che il loro piu' recente datacenter e' 
completamente diskless, con i dischi sostituiti dalle schede Fusion-io.
 
-- 
Tinto
 
 

 ottimizzato al 100% per l'nfs e' gia' meno sicuro.
 
Puoi dirlo che usi NetApp :)
 
Non è che per caso sei a tappo con gli IOPS? Hai verificato quanti IOPS
fanno i tuoi server e se le meccaniche che hai sono sufficienti per
fornirli? Proprio recentemente ho fatto rifare per intero uno storage ad
un cliente perché aveva sufficiente spazio ma su poche meccaniche e male
organizzato. Aumentando le meccaniche ed organizzando lo storage in modo
corretto ha avuto un guadagno prestazionale enorme, arrivando a
migliorare la latenza del 400%.


 macchina specializzata a gestire l'NFS (e' un netapp).
 
Perchè non provi a mettere una soluzione di caching, tipo Varnish o 
memcahed (lo so che sono 2 cose completamente diverse, ma hanno lo stesso 
scopo)?
Così facendo ti terrai i contenuti statici in memoria ed eviterai di fare 
ulteriori IOPS sullo storage.
Ovviamente bisogna anche capire quale è il problema, ma se hai un po' di 
RAM a disposizione può essere una buona idea.
Gli host Xen accedevano sempre via NFS? 

 Non è che per caso sei a tappo con gli IOPS? 
 
non ho fatto i calcoli, ma mi sembra altamente improbabile perche' 
perche' tutto cio' (i contenuti statici, che sono la larga maggioranza) 
che non ha a che fare con php legge e scrive senza lentezze né 
problemi.
 
-- 
Tinto
 
 

 [...]
 
 
Ciao  Manlio

 Gli host Xen accedevano sempre via NFS? 
 
si' e con le stesse opzioni di mount (su cui si e' provato a 
intervenire)
 
-- 
Tinto
 
 

 server.
 
intanto sono riusciti a vedere che c'erano delle 
letture di grossi file berkley-db che, spostati in 
locale, hanno piu' che dimezzato il carico.
 
Mettere mano al codice non e' (piu') nelle mie 
competenze e... capacita' ;)
 
-- 
Tinto
 
 

 indagato forse non riesce a tenere in cache i php.
 
Arrivo tardi, ma:
 
1) varnish non cacherï¿œ mai "i php": casomai ne cacha l'output [ O:-) ],
se e solo se questo presenta header che lo consentono. Il che ï¿œ spesso
meno banale di quanto possa sembrare...
 
2) lato php, avere un meccanismo di op-code caching che tenga il
bytecode in ram (e/o ramdisk) ti puï¿œ significativamente aiutare a
ridurre l'I/O verso lo storage, dato che verso il file php "vero" avrai
tendenzialmente solo operazioni di stat necessarie a vedere se lo script
ï¿œ cambiato rispetto all'ultima esecuzione. Se poi ciï¿œ non ï¿œ sufficiente,
se il meccanismo di opcode ï¿œ sufficientemente smart e se il codice ï¿œ
modificato sufficientemente di rado, puoi anche arrangiare di non
eseguire lo stat per nulla (vedi parametro apc.stat per APC), di fatto
andando ad usare il server NFS solo quando strettamente indispensabile...
 
 
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
 

 
 
Infatti il sospetto era proprio questo.
Uso del file system remoto per un database, con continue
letture/scritture che rendevano impossibile al sistema operativo il 
caching dei vari files (invece per i contenuti statici serviti da Nginx 
non hai questo problema).
 
Se il carico è ancora alto, continuate a cercare casi come questo.
Ad esempio controllate dove vengono salvati i dati delle sessioni HTTP 
(immagino proprio su berkley-db).
In questo caso al posto di berkley-db usate un database distribuito (e 
non un database normale su filesystem distribuito!) come redis o 
memcached.
 
 
Ciao  Manlio