Girovagando su Cmswatch.com per cercare notizie ho trovato un articolo, un po' datato ma ancora interessante, dedicato alla quantità di risorse richieste dai CMS ai server ospitanti; l'autore, anche se in modo molto scherzoso (ma forse sarebbe meglio dire ironico), definisce il funzionamento dei CMS utilizzando il termine GRUPA (Gratuitous Runtime Page Assembly) con riferimento alla loro necessità di creare pagine "On-the-Fly".
In pratica i CMS vengono paragonati a delle mostruose (ma simpatiche) piccole creature dispettose che richiedono continuamente risorse al server per le pagine che devono essere prodotte "al volo".
Pensiamo solo alle pagine dinamiche dei CMS in PHP, un semplice input dal client dell'utente richiede la chiamata all'interprete, spesso l'interrogazione di un database, la generazione sul momento dell'output etc., moltiplichiamo il tutto per qualche migliaio di richieste e otteniamo un possibile problema.
Molti obietteranno (giustamente) che i sistemi di gestione della cache e le prestazioni disponibili per i server di ultima generazione risolvono gran parte delle preoccupazioni dovute al carico di traffico; ma la recente telefonata di un cliente mi ha riproposto la problematica.
Il sito in questione ha circa 15/16 mila unici giornalieri e oltre 80 mila views; il traffico si concentra in particolare nel primo pomeriggio quando non di rado si verificano dei rallentamenti.
Il CMS utilizzato è Mambo con cache abilitata, e il server è un dedicato con Intel Core2 due Conroe E6400 2,13GHz con 2 GB di RAM e Os Debian.
Non è stato necessaria un'analisi molto approfondita per comprendere che alla base dei rallentamenti c'erano le numerose query al DBMS, purtroppo il tipo di servizio dato dal sito necessità di input continui e di numerose archiviazioni (registrazioni e richieste) ed elaborazioni.
Al momento, data la mancanza di una configurazione superiore da parte dell'hoster, abbiamo deciso di separare l'applicazione dal database in modo da dedicare un server ad ognuno di essi.
Nell'articolo l'autore propone scherzosamente un ritorno all'utilizzo delle pagine statiche elencandone i vantaggi, ma parte dal principio che la maggior parte dei server sia configurato per restituire al meglio solo questo tipo di output. Il contributo è del 2003 e per fortuna oggi i server sono più performanti di allora.
