Alberto Mucignat

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...