Sizing

Leggendo ciò che ho scritto de “Il fatto quotidiano” qualcuno mi ha chiesto quanto dovrebbe essere grande un server web e quanto costa. Rispondo qui di seguito, così che tutti possano usufruire di queste informazioni.

Tenete presente che il “sizing” (il “dimensionamento”) di un sistema informatico è una vera scienza ed una vera arte, oltretutto molto complessa. Per dare dei “numeri” attendibili bisogna avere dei dati di partenza altrettanto attendibili e fare dei test approfonditi. Qui posso solo dare delle informazioni di massima.

Dimensionare il server (ed il servizio)

Il carico che grava su un server è determinato da diversi fattori:

  1. Il numero degli utenti che tenta di collegarsi.
  2. Il numero di pagine (o di servizi) che ogni utente tenta di ottenere.
  3. La quantità di traffico prodotta da ogni connessione (per il download dei materiali richiesti)
  4. La quantità di memoria consumata da ogni richiesta (per mantenere traccia dello stato della connessione e dell’identità dell’utente).
  5. La quantità di traffico prodotta da ogni connessione tra il web server ed il database d’appoggio.

Purtroppo, fornire dei numeri attendibili per questi parametri, nella realtà pratica, è veramente difficile. Spesso si possono solo fare delle considerazioni di massima (almeno fino a che non è disponibile una versione beta del sistema su cui fare dei test). In linea di principio, la situazione è questa.

  1. Il mercato in lingua italiana è abbastanza piccolo. Rappresenta meno dell’1% del totale su Internet ed ammonta a circa 10.000.000 (dieci milioni) di utenti reali collegati ad Internet ogni giorno (si, lo so: Berlusconi ed i suoi parlano di 300.000.000.000 di utenti italiani, ognuno collegato stabilmente ad Internet con una FDDI a 34 Gb/sec… Qui però stiamo lavorando. Di queste cose da circo parliamo in altra sede). Questo vuol dire che anche i più grossi siti italiani, come Repubblica, il Corriere, Virgilio, etc., raramente possono vantare più di 300.000 – 600.000 utenti singoli che li visitano ogni giorno. I siti di e-commerce più trafficati, come IBS e BOL, di solito hanno tra i 20 ed i 60.000 utenti singoli al giorno. I blog di maggiore successo arrivano a qualche migliaio di utenti singoli ed un blog “normale” si piazza attorno a qualche centinaio. Per confronto: Google ha oltre mezzo miliardo di utenti singoli al giorno e persino Amazon (che esiste solo in lingua inglese) viaggia attorno ai 100 o 200 milioni di visitatori quotidiani.
  2. Dalle statistiche, si sa che ogni utente richiede abitualmente 5 pagine da ogni sito (più esattamente, da 3 a 7, a seconda del tipo di servizio).
  3. Sempre secondo le statistiche, ogni richiesta produce 30 o 40 Kb di traffico (in realtà, al giorno d’oggi sono spesso molti di più, attorno ai 200 – 300 Kb, a causa della roba in Flash, dei filmatini, delle foto, degli script Ajax e di altra roba).
  4. Ogni sessione richiede qualche Kb (da 3 a 7 Kb) per il mantenimento dello stato sul server. Questo parametro varia in modo drammatico da sistema a sistema. Su sistemi ben progettati si può arrivare a circa un Kb di RAM consumata per sessione. Sui sistemi mal progettati si può arrivare a 30 – 40 Kb di RAM consumata per sessione ed anche oltre.
  5. Ogni richiesta (HTTP request) produce mediamente 3 o 4 richieste al DB, per un traffico complessivo di qualche decina di Kb e con un consumo di RAM (sul server DB) di qualche decina di Kb (qualche centinaio in alcuni specifici casi).

Ovviamente, nei siti monolingua (solo italiano) il 90% del traffico si concentra nelle 8 o 10 ore che la gente di quella nazione dedica al lavoro, cioè tra le 8 di mattina e le 6 di sera. Nei siti plurilingua (inglese + italiano + altro) le curve di traffico si sovrappongono, seguendo le zone orarie delle varie nazioni, e quindi il traffico complessivo diventa più uniforme.

Tutto questo, sommato al fatto che il sistema operativo, il web server, il database e l’interprete (PHP, Visual Basic o Java) richiedono altre risorse vuol dire che, in pratica, la situazione può essere questa:

  1. Di solito, con un sito di e-commerce (IBS, BOL) o di informazione (Punto Informatico) di medie dimensioni, ci si trova a dover accontentare 30.000 o 40.000 utenti al giorno, cioè qualcosa come 50 utenti al secondo (o 50 utenti contemporanei, che poi è circa la stessa cosa).
  2. Vengono richieste normalmente tra le 120.000 e le 150.000 pagine al giorno. Questo vuol dire che durante le 10 ore lavorative si avranno circa 250 – 300 richieste al secondo sul web server e fino a 1000 richieste al secondo verso il database.
  3. Il traffico prodotto ogni giorno può essere dell’ordine di grandezza di diversi Gb (dipende molto dal tipo di servizio). Il traffico “istantaneo” può andare da qualche Mb al secondo a diverse decine.
  4. Di solito, ci vogliono almeno 8 Gb di RAM complessiva. Non è raro vedere sistemi come questi con 16, 32 o 64 Gb di RAM complessiva.
  5. Non è raro avere il DB su un server separato, con altre decine di Gb di RAM.

Come potete capire, anche un normale sito di e-commerce di medio successo, come IBS o BOL, ha bisogno di un server piuttosto robusto per funzionare correttamente. Più esattamente, è abbastanza normale che questi sistemi usino da due a cinque diversi computer (tutti piuttosto potenti) collegati tra loro. Anche un sito d’informazione specialistico, come Punto Informatico, può avere delle necessità di questo ordine di grandezza (più probabilmente qualcosa di meno). Un quotidiano nazionale, come Repubblica od il Corriere, ha esigenze che sono circa dieci volte superiori e non è raro che “giri” su cluster formati da 5, 6 o più computer di classe elevata.

Per confronto, potete veder cosa usa Google qui:

http://en.wikipedia.org/wiki/Google_platform

Dimensionare il processo (ed il team)

Dimensionare il server è difficile ma, tutto sommato, è relativamente facile rimediare agli errori più grossolani: basta spostare tutta la baracca su un server più grosso o su un cluster. Con le soluzioni di cloud computing che ci sono in giro adesso, questo è abbastanza facile.

È molto più difficile capire (ed accettare) il fatto che anche il team di sviluppo e di gestione del sistema NON può essere quello che spesso si pensa (o si sogna).

Lo sviluppo di un sito di media complessità, come IBS, BOL, Punto Informatico o Il Fatto Quotidiano, richiede l’intervento di diverse figure professionali:

  1. Un architetto software che progetti tutta la baracca e che, durante la fase di sviluppo, magari faccia anche da Project Manager.
  2. Un grafico (o più).
  3. Almeno due o tre sviluppatori (team di 5 – 8 sviluppatori sono tutt’altro che rari).
  4. Uno specialista di database (DBA)
  5. Un amministratore di sistema che segua il team di sviluppo (e prepari i vari server necessari per l’avventura).
  6. Un copy writer che si occupi dei testi.
  7. Almeno un paio di anime pie che si occupino dei collaudi.
  8. Magari, anche un Technical Writer che prepari la documentazione per chi, in seguito, dovrà gestire il sito.

I tempi di sviluppo (della “beta”) di un oggetto del genere sono tipicamente di qualche mese (diciamo da 3 a 12 mesi) ed i costi vanno da 30 – 40.000 € fino a 100 – 200.000 €, a seconda delle funzionalità necessarie e del livello di qualità della grafica e di altre componenti.

Dopo la consegna del sistema, e quindi durante il funzionamento quotidiano, il sistema avrà bisogno di altre figure professionali:

  1. Un amministratore di sistema.
  2. Una redazione che si occupi dei contenuti (da una a 100 persone o più: dipende tutto dal tipo di sito…)
  3. Un grafico che si occupi dei piccoli inserti grafici quotidiani.
  4. Un programmatore che si occupi di implementare le nuove funzionalità richieste dal proprietario.

In altri termini, un sistema del genere ha bisogno almeno di alcune migliaia di euro al mese per restare in vita.

Tutto questo, ovviamente, senza considerare che il sistema andrà comunque ammodernato in maniera più o meno pesante durante la sua vita operativa.

La cosa grave è che un errore commesso nel dimensionare il team di sviluppo e/o il team di gestione è piuttosto difficile da correggere. Dato che il sistema, per sua stessa natura, è quasi del tutto “ad hoc”, qualunque nuovo membro del team deve spendere una quantità di tempo considerevole per capire com’è fatto il sistema prima di poter essere d’aiuto.

La questione della manutenibilità

I siti medio-grandi, diciamo quelli che vanno dalla scala di Punto Informatico, IBS e BOL, fino a quelli di Repubblica e del Corriere, hanno anche un’altra caratteristica perversa: solitamente il team di sviluppo resta attivo per anni dopo la consegna del sistema, anche se con meno personale, e continua ad aggiornare il sistema mentre questo funziona. Spesso i membri del team cambiano durante la vita operativa del sito. Questo vuol dire che un nuovo membro deve potersi orientare con facilità all’interno del sistema. Questo, a sua volta, significa che il sistema deve essere dannatamente “manutenibile”. Un nuovo membro deve poter capire facilmente la struttura del sistema e deve potersi orientare nel codice senza essere costretto a fare continuamente del reverse engineering. I vari Project Manager che si avvicendano durante la vita del progetto, devono poter capire come è fatto il sistema e devono poter controllare il lavoro dei programmatori.

Per questa ragione, personalmente non credo che si possa (o si debba) creare siti di queste dimensioni con tecnologie che non sono state concepite sin dall’inizio per avere il massimo di modularità, di controllabilità e di manutenibilità. Cose come Perl, PHP (e quindi WordPress e Drupal), Visual Basic (ASP.NET) e Python non sono state concepite con questo scopo in mente e, anche se non mancano né gli strumenti né le tecniche per rimediare alle loro carenze, sarebbe meglio che non venissero usati in questi contesti.

Intendiamoci: non è solo una questione di linguaggio (grammatica, sintassi, semantica, etc.) o di librerie (strumenti). È Soprattutto una questione di “ambiente di lavoro”, inteso come strumenti (Eclipse, Netbeans, Maven, Hudson, HackyStat, Hibernate, JPA, JDO, JCR, JMX, etc.) e come metodologie “acquisite” (Continuos Integration, TDD e cose simili).

Per quanto mi riguarda, credo che l’unica tecnologia che permette di tenere sotto controllo dei progetti di questo genere sia Java (J6EE e EJB3.0, per capirci). Non a caso, è la tecnologia abitualmente usata dalle banche. Qui, però, entriamo nel campo dei gusti personali. Non mancano infatti esempi di siti di enormi dimensioni creati con tecnologie “non nobili”. Ad esempio, Facebook è scritto in PHP.

Qualche caso tipico

Giusto come indicazione di massima, potete tenere presente questi consigli:

  1. Se vi dovete fare un blog personale, usate un servizio gratuito, come WordPress.com o, al massimo, installate Wordpress su un piccolo server a noleggio, di quelli da 8 – 10 US$/mese.
  2. Se dovete fare un piccolo sito di comunità, ad esempio per il vostro gruppo di ciclisti, od un piccolo sito di e-commerce, ad esempio per vendere la marmellata della nonna, usate un sito in hosting (“web hosting”, cioè un server Apache condiviso tra più siti), magari con Drupal o WordPress. Vi costerà da 10 a 20 € al mese.
  3. Se dovete fare un sito redazionale di medio/piccola complessità (come Punto informatico) od un sito di e-commerce professionale (più piccolo di IBS…), usate almeno un VPS (Virtual Private Server) od un servizio di Cloud Computing (Amazon EC2, Google App Engine, MS Azure, etc.). Vi costerà dai 20 € ai 200 € al mese, a seconda delle esigenze.
  4. Per qualunque cosa oltre queste dimensioni, usate almeno un grosso VPS, oppure un server fisico (“dedicated server”) o, se necessario, un cluster composto da 2 – 5 macchine. Vi costerà dai 200 € ai 2000 € o più al mese, a seconda delle esigenze.

Conclusioni

Da quanto ho appena detto dovrebbero essere chiare alcune cose:

  1. L’idea che basti un “guru” ed un serverino da 10 US$/mese per buttarsi nell’avventura dell’Internet Business è esattamente ciò che sembra: una pia illusione.
  2. In generale, per fare siti web decorosi ci vogliono dei professionisti (un team di professionisti).
  3. In generale, i costi sono paragonabili (almeno) a quelli necessari per aprire un negozio “fisico” od un ristorante.
  4. Per avventurarsi in questo territorio occorre una preparazione tecnica di livello molto elevato, anche solo per capire cosa vi dice il vostro consulente. Un laureato in economia e commercio “tradizionale” dovrebbe tenersi accuratamente alla larga da questa roba e dedicarsi all’agri-business.

Spero di esservi stato d’aiuto. Se avete qualcosa da dire, usate il sistema dei commenti qui sotto.

Alessandro Bottoni

Annunci
Comments
2 Responses to “Sizing”
  1. kingofgng ha detto:

    Tutto molto interessante, solo un paio di appunti personali:
    – Se il sito/blog personale finisce su Digg/Reddit/Slashdot (e magari su più di uno), il server rischia di saltare quindi la cosa va tenuta in debita considerazione
    – La mia esperienza personale mi dice che il web hosting condiviso fa schifo nella migliore delle ipotesi: i periodi di downtime sono il classico “pain in the ass” da cui a volte non ci si esce perché c’è qualche stronziolo di utente che butta giù il server condiviso per tutti.
    – Anche in considerazione di quanto detto sopra, io consiglierei di evitare come la peste AN Hosting/Midphase: in uno dei TAAANTI downtime che il mio blog (ita/eng) ha dovuto subire in 2 anni mi è stato detto molto chiaramente che il loro servizio non era adatto per reggere l’urto dell’effetto slashdot. Ultimamente le cose sono migliorate e sono passati a server con CPU a 8 core, ma l’affidabilità resta aleatoria.
    – Del Grid Hosting di MediaTemple (http://mediatemple.net/webhosting/gs/) ho letto un gran bene e l’idea mi intriga, infatti credo che sposterò la baracca da quelle parti non appena mi ritaglierò un pò di tempo per la laboriosa operazione di switch (che nel mio caso include anche l’aggiornamento di WordPress all’ultima versione disponibile+plug-in)….

    • alessandrobottoni ha detto:

      Eh, si… il web hosting tradizionale (un server Apache suddiviso tra più siti) solitamente fa proprio schifo, anche per le applicazioni più banali. Purtroppo, fanno abbastanza schifo anche i VPS di fascia più bassa e molte soluzioni “cloud” o “grid”. Ad esempio, MediaTemple viene recensita piuttosto male da molti suoi utenti.
      Francamente, se appena appena la vostra applicazione ha delle esigenze di resistenza ai picchi di traffico e di continuità del servizio, sarebbe meglio che prendeste in considerazione o un grosso VPS od un server dedicato. Lo so, costano molto, però, purtroppo, queste sono le sole soluzioni che funzionano in applicazioni realmente “professionali”.
      A saperle scegliere ed usare con competenza, anche certe soluzioni di cloud computing, come Amazon EC2 e Google App Engine, possono essere di grande soddisfazione.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: