altre destinazioni

vedi anche

ultimi post

ultimi commenti

tag principali

categorie

archivi

powered by

  • WPFrontman + WP

friends

copyright

  • © 2004-2011
    Ludovico Magnocavallo
    tutti i diritti riservati

Lo Zen e la scalabilità delle applicazioni web

29 marzo 2006

4 commenti

tag

categorie

Un titolo degno di Enrica per consigliarvi The Adventures Of Scaling, una serie di post sull’ottimizzazione di eins.de, sito tedesco con un buon traffico (>1m di pageviews giornaliere) recentemente riscritto in Ruby on Rails.

Un po’ di scienza, un po’ di black magic e tanto buonsenso, questi gli ingredienti indispensabili per ottimizzare architetture che sono semplici sono in apparenza. Come era prevedibile Rails è lento, la complessità architetturale (proxy, load balancers, ecc.) e la stratificazione del codice ammazzano le performance, e le ottimizzazioni più consistenti sono a livello di base dati (uno dei motivi per cui non mi sono mai piaciuti gli ORM).

4 commenti

  • Alberto Mucignat
    29 marzo 2006 #

    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

  • gabriele renzi
    29 marzo 2006 #

    Scusa, non ho letto attentamente e non ho capito, quindi chiedo:
    - ma le complicazioni architetturali non c’erano anche prima con php?
    - aggiungere proxy, load balancer etc.. li porta ad un incremento di pagine servite di una volta e mezza, perché dovrebbero ammazzare le performance?

    Ovviamente io sono straconvinto che nella comunità dei railer ci sia generalmente poca attenzione alle performance del codice stesso, Tanto per dire, è abbastanza banale una volta che il codice è stabilizzato cancellare ActiveRecord e sostituirlo con un layer custom.
    Esempio stupido: in un sacco di applicazioni rails trovi una cosa come

    obj_attributes= Obj.find(:all).map {|o| o.attribute}

    che
    - aumenta il carico computazionale sul database
    - aumenta il traffico sulla connessione
    - introduce un overhead lato ruby

    sarebbe banale da trasformare in una semplice "select title from pages", ma in genere la gente se ne frega.

  • ludo
    29 marzo 2006 #

    Gabriele, per quanto posso capire io:

    * l’architettura dell’applicazione PHP era (come quasi tutte le applicazioni PHP) molto semplice, Apache+mod_php e MySQL; PHP è superveloce, e in genere le applicazioni sono shared nothing e non hanno un layer ORM;

    * i proxy e i load balancer, per non parlare dei server fcgi che si piantano, introducono complessità difficile da gestire, e soprattutto in un’architettura cresciuta in maniera organica/caotica danno più problemi che benefici

    Per il resto sono perfettamente d’accordo con te. Anche in ambiente Python c’è la tendenza a ignorare le questioni legate al DB o le questioni di performance: sia TurboGears che Django usano ad esempio SQLObject, pesantissimo e decisamente bacato (basta provare ad utilizzare tabelle o campi Unicode con MySQL 4.1 per rendersene conto).

  • Boh
    29 marzo 2006 #

    ma che c'entra lo zen?