Newsgroup: it.comp.os.linux.sys
Titolo: fare reverse proxying di lighttpd con varnish

Lighttpd e' un web server che, dicono :), ha 
performance più elevate di apache, Varnish e' 
invece un reverse proxy/load balancer che oltre a 
essere efficiente dispone di un linguaggio di 
"programmazione" che lo rende molto flessibile.
 
Ci stiamo occupando di rifare un'infrastruttura che 
fa funzionare dei siti web a traffico abbastanza 
alto di pagine html statiche, ma che cambiano 
abbastanza frequentemente nel tempo.
 
Dovendo usare software a costo zero, Varnish mi e' 
sembrata la soluzione migliore per svolgere tre 
compiti che mi premono molto ovvero:
-load balancing fra web server di backend
-scegliere il pool backend opportuno in base 
all'fqdn (o alla url)
-centralizzazione dei log
 
Il mio collega ha portato avanti una soluzione, per 
la parte backend, che e' architettata con uno o più 
server lighttpd e con dei FastCGI server che 
interpretano il php. La cosa non da problemi nella 
conf di Varnish, al quale non interessa della parte 
fastcgi.
 
La discussione verte su: conviene usare Varnish 
davanti a questi web server oppure no? Lui sospetta 
che possa peggiorare più che migliorare. Io sarei 
disposto ad accettare anche un calo di performance 
piuttosto che dover impazzire con tanti log files 
(da conservare) quanti sono i backend, con un 
bilanciatore come Pulse che ha bisogno di un IP 
pubblico per ogni pool di backend, che mi sembra un 
bel po' piu' ostico da gestire.
 
Ogni commento e suggerimento sara' graditissimo :)
 
-- 
Tinto
 
 


Varnish se ben configurato è una bella bestia. Non so quanto migliori se 
il contenuto reale è già statico, ma a naso credo che cmq qualcosa 
migliorerebbe.
Ad ogni modo avete provato a dare un'occhiata a nginx?
Fa sia da webserver che da proxycache che da balancer
Se gli lasci vicino una moka credo faccia anche il caffè.
M
 
-- 
I fatti mi cosano

 caffè.
 
interessante, provo a mettere un moka vicino a 
varnish, vediamo se e' all'altezza ;)
 
-- 
Tinto
 
 

 remote logging.
 
ho dato un'occhiata a Pound e ho un po' capito come 
lavora (in pratica NON cacha).
Con "remote logging" intendi syslog?
Per dare un'idea della mole di dati, si parla di 
quasi 1 milione di pagine viste al giorno...
 
-- 
Tinto
 
 

 pagine viste al giorno...
 
Caso pessimistico: 8 ore al giorno i cui concentrare le richieste (sono 
di più di solito ma supponiamo che la gente dorma 16 ore al giorno).
 
In questo caso si tratta di 35 richieste al secondo che se sono pagine 
statiche sono un carico NULLO per qualunque webserver, anche datato.
 
Se poi, come nel tuo caso, i server web sono più di uno sinceramente non 
capisco dove stia la mole di lavoro che ti obbliga a cachare pesantemente.

Dopo dura riflessione, CtRiX ha scritto :

la "mole" la mettevo in campo per quanto riguarda 
la quantita' di log da scrivere (e conservare).
 
Sulla cache: sarei abbastanza d'accordo, ne farei 
anche a meno. Fra le cose che ho visto Varnish mi è 
piaciuto piu' che per la cache perche' mi permette 
di usare un solo IP pubblico invece di N e per la 
centralizzazione degli access log.
 
Dico sarei, perche' il tuo calcolo purtroppo non e' 
valido in quanto trattandosi di sito di notizie il 
carico non e' spalmato uniformemente su 8 ore e 
neanche 4. Se cade il governo o viene un terremoto 
in orario di lavoro, quando la gente e' in ufficio 
e non puo' accendere la tv ma solo guardare il web 
il carico ha dei picchi violentissimi.
 
Se poi insieme alle pagine statiche ci ficcano 
anche qualche php si fa presto a fare la frittata.
 
-- 
Tinto
 
 

 lavoro che ti obbliga a cachare pesantemente.
la "mole" la mettevo in campo per quanto riguarda 
la quantita' di log da scrivere (e conservare).
Sulla cache: sarei abbastanza d'accordo, ne farei 
anche a meno. Varnish mi ï¿œ piaciuto non tanto per 
la cache ma perche' mi permette di usare un solo IP 


)
 
Dopo dura riflessione, CtRiX ha scritto :
 

la "mole" la mettevo in campo per quanto riguarda 
la quantita' di log da scrivere (e conservare).
 
Sulla cache: sarei abbastanza d'accordo, ne farei 
anche a meno. Varnish mi è piaciuto non tanto per 
la cache ma perche' mi permette di usare un solo IP 
pubblico invece di N e per la centralizzazione 
degli access log.
 
Dico sarei, perche' il tuo calcolo purtroppo non e' 
valido in quanto trattandosi di sito di notizie il 
carico non e' spalmato uniformemente su 8 ore e 
neanche 4. Se cade il governo o viene un terremoto 
in orario di lavoro, quando la gente e' in ufficio 
e non puo' accendere la tv ma solo guardare il web, 


 presto a fare la frittata.
 
Ne sono consapevole, gestendo anche io sistemi di alcuni quotidiani di 
carattere nazionale.
 
Proprio per questo sto cercando di farti capire che:
 
1) se si tratta di pagine statiche è inutile complicarti la vita con 
$qualsiasiaccrocchio tu voglia. 
 
2) se il problema sono i PHP scritti a pene di segugio allora prima si 
fixano i problemi di scalabilità del PHP e poi si procede con altro.
 
Questo in base alla mia esperienza, ovviamente. 
Aggiungere cache ed altro di fronte ad un cluster web aiuta tantissimo 
*se* ciò che ci sta dietro è fatto decentemente (non necessariamente 
bene).
 
Altrimenti vai ad inserire altri livelli di complessità che (soprattutto 
nel tuo anarchico caso) aumentano la complessità (e la vulnerabilità) del 
sistema piuttosto che la sua resilienza ai carichi.
 
Non è che ti sto rompendo le palle con questi argomenti (vedasi gli altri 
thread) perchè oggi mi gira così ma perchè da quello che racconti i tuoi 
problemi sono altrove.
 
P.S. (per la cronaca, PHP se scritto bene a livello di script e 
configurato bene a livello sistemistico scala di brutto. Ma è difficile 
farlo funzionare bene senza sperimentare e senza esperienza).
 

 altrove.
 
si' ho capito benissimo, come so che i problemi 
sono altri, si possono sintetizzare in "vogliamo 
far vedere come siamo bravi e veloci a fare cose 
senza spendere niente, poi se a lungo andare 
sorgono problemi cercheremo qualcuno a cui dare la 
colpa".
 
La soluzione -purtroppo- non e' in mio potere, 
cerco solo di fare il meno peggio per potermi 
pagare l'affitto ;)
 
-- 
Tinto
 
 

 -centralizzazione dei log
 
Per curiosita`, come la fai? Prendi per buoni solo quelli del proxy oppure i 
giri in qualche modo al syslog di turno?
 
Enrico

Enrico 'Henryx' Bianchi ha spiegato il 05/10/2011 :

varnish ha anche un demone (varnishcnsa) che scrive 
i log in formato standard. Sinceramente mi basta il 
minimo per poter dire di soddisfare gli obblighi 
legislativi di conservazione.
Non ci facciamo ne' analisi ne' nulla... se potessi 
li manderei direttamente a /dev/null
 
-- 
Tinto
 
 

 i log in formato standard.
 
Si, questo lo so. La mia domanda pero` era un'altra (anche se penso di aver 
inteso che prendi per buoni solo quelli del proxy) :)
 
Enrico