altre destinazioni
vedi anche
- Voi come leggete il codice? «
- WP rant #1 - tassonomie «
- Parole sante «
- Quattro nove «
- Se volete smentirlo voi... «
ultimi post
- Come si incentiva il trasporto pubblico in Lombardia / 1 «
- Dieci e uno «
- Maratoneti «
- Jiayu G3, dove comprarlo (e ne vale la pena)? «
- Come risparmiare batteria su Android «
ultimi commenti
- ludo, Dieci e uno «
- theo, Dieci e uno «
- ludo, Libevent-based HTTP/1.1 client «
- george d, Libevent-based HTTP/1.1 client «
- ludo, Libevent-based HTTP/1.1 client «
tag principali
- blogging
- italia
- milano
- spigolature
- conferenze
- top100
- python
- web 2.0
- blogbabel
- rugby
- calcio
- ebook
- tv
- barcamp
- musica
- nanopublishing
- lightpress
- django
- php
categorie
- blogging «
- books «
- calcio «
- design «
- digital underground «
- ebay «
- eventi «
- gadget «
- games «
- general «
- guest blogger «
- help «
- in evidenza «
- internet business «
- lazyweb «
- letture «
- linux «
- luambo «
-
ludo «
- audio e musica «
- foto «
- quotidianità «
- rete «
- luoghi «
- milano «
- misc «
- miscellanea «
- mobile «
- mobile e pda «
- motori di ricerca «
- music «
- musica «
- news «
- personal «
- php «
- podcasting «
- podcasts «
- prima pagina «
- python «
- rugby «
- screencasts «
- simpleaggregator «
- sistemi operativi «
- smanettando «
- software «
- staticblog «
- sviluppo «
-
tech «
- ipaq «
- palm «
- programmazione «
- tecnologie varie «
- web «
- technology «
- tecnologia «
- tex «
- tv «
- varie «
- web 2.0 «
- web design «
archivi
- luglio 2013 «
- aprile 2013 «
- marzo 2013 «
- febbraio 2013 «
- novembre 2012 «
- ottobre 2012 «
- aprile 2012 «
- settembre 2011 «
- agosto 2011 «
- luglio 2011 «
- giugno 2011 «
- maggio 2011 «
- marzo 2011 «
- febbraio 2011 «
- gennaio 2011 «
- dicembre 2010 «
- novembre 2010 «
- ottobre 2010 «
- settembre 2010 «
- giugno 2010 «
- maggio 2010 «
- novembre 2009 «
- settembre 2009 «
- agosto 2009 «
- luglio 2009 «
- giugno 2009 «
- maggio 2009 «
- aprile 2009 «
- marzo 2009 «
- febbraio 2009 «
- gennaio 2009 «
- novembre 2008 «
- ottobre 2008 «
- settembre 2008 «
- agosto 2008 «
- luglio 2008 «
- giugno 2008 «
- maggio 2008 «
- aprile 2008 «
- marzo 2008 «
- febbraio 2008 «
- gennaio 2008 «
- dicembre 2007 «
- novembre 2007 «
- ottobre 2007 «
- settembre 2007 «
- agosto 2007 «
- luglio 2007 «
- giugno 2007 «
- maggio 2007 «
- aprile 2007 «
- marzo 2007 «
- febbraio 2007 «
- gennaio 2007 «
- dicembre 2006 «
- novembre 2006 «
- ottobre 2006 «
- settembre 2006 «
- agosto 2006 «
- luglio 2006 «
- giugno 2006 «
- maggio 2006 «
- aprile 2006 «
- marzo 2006 «
- febbraio 2006 «
- dicembre 2005 «
- novembre 2005 «
- ottobre 2005 «
- settembre 2005 «
- agosto 2005 «
- luglio 2005 «
- giugno 2005 «
- maggio 2005 «
- aprile 2005 «
- marzo 2005 «
- febbraio 2005 «
- gennaio 2005 «
- dicembre 2004 «
- novembre 2004 «
- ottobre 2004 «
- settembre 2004 «
- agosto 2004 «
- luglio 2004 «
- giugno 2004 «
- maggio 2004 «
- gennaio 2004 «
- dicembre 2003 «
- novembre 2003 «
- ottobre 2003 «
- settembre 2003 «
- agosto 2003 «
- giugno 2003 «
powered by
- WPFrontman + WP
friends
copyright
- © 2004-2011
Ludovico Magnocavallo
tutti i diritti riservati
Lo Zen e la scalabilità delle applicazioni web
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).
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
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.
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).
29 marzo 2006 #
ma che c'entra lo zen?