Newsgroup: it.comp.os.linux.sys
Titolo: Consiglio dimensionamento server

Ho bisogno di implementare un webserver su apache, cgi in perl, con DB
Informix.
Le funzionalità sono abbastanza banali, nel senso che deve solamente
fornire riposta a query effettuate sul db tramite le cgi stesse, e
peraltro nemmeno query particolarmente complesse.
Il problema sta nel carico cui deve essere soggetto: deve essere in
grado di mantenere in piedi fino a un picco di 4000 richieste contemporanee.
Chi abbia già avuto a che fare con realizzazioni di questo
dimensionamento, mi può dare un ordine di grandezza sulla "corazzatura"
dell'hardware (ovviamente architettura x86 e linux :-) ?
Thx...
Byez...
-- 
Emanuele "SKULL" Balla
----------------------------------------------------------------------
"How should I know if it works?  That's what beta testers are for. I
only coded it." (Attributed to Linus Torvalds, somewhere in a posting)

 contemporanee.
beh, 4000 conessioni contemporanee sul web server non sono poche per un pc!
io ti consiglierei di mettere piu` di una macchina, almeno una per il web
server e una per il db; per il db vedi cosa consiglia informix (non lo
conosco), per il web server probabilmente non ti servira` moltissima cpu,
ma abbonda con la ram (per quantificarlo serve qualche info in piu`,
direi);
ovviamente mod_perl (se proprio non puoi rinunciare al perl) e kernel 2.4
(con il 2.2 non riesci a gestire tutte quelle connessioni) sono
indispensabili; 
valuta inoltre la possibilita` di distribuire il web in frontend su un po'
di macchine piccole (5 celeron con 512mb di ram, per esempio)... alla fine
potrebbe anche costarti meno in hw ed avresti una architettura piu`
ridondata
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 indispensabili; 
L'ipotesi architetturale presente prevede l'installazione di un cluster 
HA in kimberlite di 2 macchine biprocessione con 2 giga di ram ciascuna, 
+ l'unità storage scsi per il db in fiberchannel.
Può essere sufficiente, come ipotesi per il carico? Portare il front-end 
su altre macchine preferirei evitarlo, per una questione di numero di 
macchine da gestire. In ogni caso considera che la struttura 
dell'accesso prevede l'utilizzo di una coppia di reverse proxy (sia in 
http che ssl) in load-balancing, su cui avverrà l'accesso pubblico 
effettivo. Oltre a essere dettato da ragioni di sicurezza, questo 
dovrebbe anche scaricare le due macchine di cui sopra di una buona parte 
del lavoro http sui contenuti statici, presumo ...
byez


del lavoro http sui contenuti statici, presumo ...
Sì presumi bene, purchè. 
I due reverse proxy per i contenuti statici devono essere con tanta
ram, anzi di più. Ora io non so dirti quanta te ce ne vorrà, ma
l'obiettivo che tu devi raggiungere è che una richiesta statica arrivi
al/ai reverse proxy, passi per il processore, il processore copia i dati
dalla memoria, e li invia sulla rete, cioè lo schema deve essere:
network-ram-network. Quindi ti ci vorrà la ram necessaria per ospitare
le pagine statiche (magari non tutte, ma quella parte che viene acceduta
nella maggior parte dei casi), i rispettivi metadati, le aree dati del
kernel che crescono in funzione del numero di connessioni aperte, il
kernel e il web server. 
Altro purchè è appunto il web server, per fare questa cosa non pensare
necessariamente ad Apache, che è tanto bello ma un pessimo fornitore di
contenuti statici. Vedi khttpd (sulla cui stabilità e sicurezza tuttavia
non saprei cosa dirti) e magari Flash (che però si paga).
Naturalmente qui parliamo in termini molto approssimativi, bisognerebbe
vedere quale è il workload che devi affrontare, e quindi in particolare
quale è la percentuale di documenti statici rispetto ai dinamici, quanto
costa produrre i documenti dinamici, ecc..
Davanti ai reverse proxy avrai un web switch di livello 4 (cioè Linux
Virtual Server, o magari un dispositivo dedicato) e dietro ai reverse
proxy ci saranno i/il web server per i contenuti dinamici, con dietro il
database. Lo schema in genere è questo, poi la numerosità e la potenza
dei componenti di ciascun livello è una rogna modellistica che ti lascio
con gioia :-)
-- 
Per rispondermi, ricordati di togliere il 
nome del poeta e il trattino.

 del lavoro http sui contenuti statici, presumo ...
ma anche i reverse proxy sono macchine in piu` da gestire! e sono anche
una complicazione ulteriore all'architettura, volendo ben vedere
probabilmente la mia mail potrebbe risultare un po' distruttiva, non
prenderla pero` in questo senso: prendila come uno spunto di riflessione
per vedere se hai dimenticato qualche aspetto architetturale nel tuo
progetto (che sicuramente puo` funzionare alla grande)... non esiste un
solo modo per fare le cose, questo e` soltanto quello che preferisco io...
non e` legge, ma non e` nemmeno da buttare senza nemmeno valutarne la
fattibilita` :-) (e ovviamente e` tutto IMHO)


probabilmente la mia mail potrebbe risultare un po' distruttiva, 
A me sembra senza nč capo nč coda, per essere distruttiva dovrebbe
contenere motivazioni e discorsi seri, e io non he ho visti. I reverse
proxy sono macchine in piů da gestire? I cluster non servono per
scalare? Ma da quale medioevo informatico provieni?


 Ma da quale medioevo informatico provieni?
beh, un medioevo informatico nel quale ho visto sistemi di clustering che
creano piu` problemi di quanti ne risolvono, oppure dove architettura
fighissime sulla carta diventano un panico per chi deve gestirle per la
troppa complessita` dell'implementazione (l'unico elemento di una
architettura che non ti dara` mai problemi e` quello che si e` deciso di
non mettere, ovviamente non puoi non fare nulla perche` cosi` non si
rompera` nulla, ma, se puoi tenere semplice una architettura, SECONDO ME,
e` meglio)


 fattibilita` :-) (e ovviamente e` tutto IMHO)
Ti assicuro che _vorrei_ seguire la tua via. Volevo farlo anche prima 
che me la dicessi ;-)
renderebbe tutto più semplice... solo che non posso...
grazie comunque delle idee sicuramente interessati
