Alberto Mucignat

Con colpevole ritardo, segnalo queste slide di Ilia Alshanetsky:

- PHP and Performance (pdf)
- PHP Security (pdf)

Consiglio a sviluppatori php e sistemisti di leggersele molto attentamente.

Ilia sarà a Skien per l'eZ conference 2006, dove terrà un talk su php e alte prestazioni.

Quest'anno oltre a lui ci sarà uno dei padri di PHP, Rasmus Lerdorf, che ora lavora a Yahoo.

Stamattina mi sono svegliato con un pensiero fisso: la scalabilità delle applicazioni web non esiste. O meglio: la scalabilità non è quello che pensiamo comunemente. Cerco di argomentare.

Anzitutto, prendiamo le distanze e diamo le definizioni:

Performance is measured by the output behavior of the application. In other words, performance is whether or not the app is fast. [...] Scalability is the ability of the application to maintain good performance under heavy load with the addition of resources. (dal già citato, Digg PHP's scalability and performances)

Queste prime definizioni sono importanti: spesso si confondono le due cose. Le performance sono qualcosa di tangibile anche con un solo utente, la scalabilità ha a che fare invece con un alto carico.

Inoltre, solitamente per scalabilità si intende la capacità di un'applicazione di gestire un maggior numero di utenti, semplicemente aggiungendo nuovo hardware. Questo è il primo falso mito, quasi mai vero: aggiungere un server richiede comunque delle configurazioni e dei tuning, specie se all'inizio si lavora con un unico server. Situazione peraltro comune a tutti i siti medio-piccoli.

Il secondo falso mito riguarda Java. Premetto che conosco poco le applicazioni Java perchè ho sempre usato sistemi opensource. Le poche volte che mi è capitato, semplicemente le applicazioni non erano predisposte per scalare. Per esempio utilizzavano i cosiddetti local persistent object o cose del genere. E infatti trovo un articolo su OnJava che spiega egregiamente come non c'è differenza sostanziale sulla scalabilità tra Java, PHP e gli altri linguaggi web:

Scalability is mainly about the architecture of the application layer, and there is no one true panacea architecture that will work for all application architectures. The key to success is not in any particular technology, but in simplifying your server model and understanding all of the components of the application layer, from the HTML and HTTP on the front end to the SQL in the back end. Both PHP and Java are flexible enough to create scalable applications for those who spend the time to optimize their application architecture.

Insomma, non è il linguaggio in sè che aumenta la scalabilità, ma la capacità di sviluppare applicazioni scalabili. In altre parole:

For any technology, the statement “X doesn’t scale” is a myth. The reality is that there are ways X can be made to scale and ways to screw up trying. Understanding the possibilities and avoiding the pitfalls requires experience that doesn’t (yet) come in a box. (da IT Myth: IT doesn't scale)

Da queste considerazioni e dalla mia esperienza personale, traggo le seguenti conclusioni:

1. La scalabilità non si ottiene aggiungendo hardware, ma lavorando sodo e professionalmente sul lato architetturale dell'applicazione. Tradotto per i manager e i non tecnici: ci vogliono tempo e bravi programmatori. Meglio: ci vuole qualcuno con i cosiddetti.

2. La scalabilità è una cosa che si mantiene lavorando continuamente sulla qualità e soprattutto sui dettagli. Come al solito, ci vogliono metodo e persone in gamba (sistemisti, sviluppatori, manager).

3. Anche se un'applicazione è venduta come scalabile, quando ci sono problemi non basta solo aggiungere hardware.

Corollario 1: la scalabilità non viene da sola e costa abbstanza. Sorry.

Corollario 2: è molto difficile, nella maggior parte dei casi, lavorare allo sviluppo considerando anche la scalabilità. A meno che nel progetto non vengano inclusi particolari task a proposito.

Spesso mi hanno chiesto: le vostre applicazioni sono scalabili? Non sono mai riuscito a rispondere per bene a questa domanda. D'ora in poi darò il link a questo post.

Ludo mi segnala dei corsi sulla scalabilità con Rails. Per i mai contenti, è disponibile una presentazione (pdf, 8Mb), anche se non molto esaustiva.

In contemporanea, esce un articolo sul performance di eZ publish. Da quel che so, i ragazzi norvegesi stanno spendendo parecchie energie per aumentarne la scalabilità e all'eZ conference 2006 di giugno ci saranno delle presentazioni a proposito.

Segnalo un autorevole parere che illustra il vantaggio di utilizzare PHP, in termini di scalabilità e performance.

Digg, noto motore di social bookmarking, con PHP garantisce un flusso di 200 milioni di pagine viste al mese con 3 web server. L'unica cosa che mi lascia interdetto è il fatto che vengono usati 8 db server (però piccolini), a causa di un non meglio specificato problema di scalabilità di MySQL: le applicazioni dinamiche che ho sviluppato negli anni avevano un rapporto medio di 3:1 tra i server PHP e MySQL.

Sulla scalabilità di PHP avevo già parlato a proposito del case study di Yahoo e del fatto che a Studenti.it abbiamo gestito picchi di traffico con un'infrastruttura abbastanza semplice, ma ben configurata.

(Via Fullo l'instancabile)

Ludo ci segnala una serie di articoli molto interessante, che racconta come è stata aumentata la scalabilità di un'applicazione web, grazie al refactoring di un'applicazione PHP di 50k righe con un'applicazione ROR da 5k righe. Ok, questa era per attirare l'attenzione.

In attesa del quarto articolo, vi segnalo quelli attualmente online:
- The adventures of scaling (stage 1)
- The adventures of scaling (stage 2)
- The adventures of scaling (stage 3)
- Question and answers

Sul numero di righe del codice dico subito che è una mera speculazione. ROR è un linguaggio a oggetti e quindi molto più "compatto" di un procedurale. Soprattutto, è normale che quando un'applicazione diventa vecchia, si porti dietro molte righe di codice inutili, di cui magari non è mai stato fatto il refactoring.

Comunque dice bene Ludo. E pare anche a me che ROR comporti una complessità notevole a livello architetturale.

In anni di lavoro a Studenti.it ho progettato diversi cluster, che servono in media 1 milione di pagine viste al giorno, con picchi di 2-3 milioni (oltre 200k utenti), durante i giorni degli esami di maturità. E l'architettura è abbastanza semplice, considerato quella messa in piedi per eins.de.

Per dire che PHP è molto più semplice da scalare, a mio avviso. O forse siamo stati bravi noi.

Rigirando la frittata, mi chiedo cosa significhi gestire la scalabilità in ROR, perchè quel che vedo è principalmente un lavoro su architettura e base dati, ottimizzando i vari passaggi che possono diventare bottlenecks.

Esperienza da leggere, comunque. Come quando si parla del cluster MySQL 5, della ricerca FULLTEXT e dell'ottimizzazione delle slow query. Negli ultimi giorni ho risolto così alcuni bottlenecks di eZ publish, a proposito di JOINs e INDEXes...