Misurare prima di ottimizzare

Community IT
1

lo sapevo, l’ho sempre saputo… non ottimizzare prima di misurare.
eppure ero convinto che il problema di una mia applicazione fosse nel
database. ho deciso (per una volta) di fare le cose per bene e ho
scoperto che, nonostante l’altissimo numero di query, nel db ci
passava circa l’1% del tempo e il collo di bottiglia era nel rendering
e in alcune chiamate implicite fatte al db in fase di rendering.

semplicemente mettere la pagination e togliere un po di logging ha
ridotto da 10 a 1 i tempi di una pagina.

voi avete esperienze simili su come fare profiling vi abbia aiutato?

PS: ottimo articolo di antonio qui:

2

Il giorno 19/apr/07, alle ore 12:14, chiaro scuro ha scritto:

voi avete esperienze simili su come fare profiling vi abbia aiutato?

Come ben sai io mi occupo dei siti internet di una delle maggiori
case editrici italiane e con questi problemi combatto tutti i giorni.
Per esperienza, non rilasciamo mai il codice se non è ben farcito con
i log sulle prestazioni. Questo perché, anche se i vari ambienti
(prova, staging … ) sono gemelli, la prova del nove è sempre
l’utente finale e cioè la produzione. Una settimana con i questi log
attivi e se non ci sono problemi via anche quelli per andare ancora
più veloci.

Caso di questi giorni: sto ristudiando la presentation del motore di
ricerca di un sito per la vendita di libri on line. Una bomba
l’accesso al db, peccato che, per fare in fretta e avere la massima
elasticità possibile nella visualizzazione, abbiano deciso di usare
xml e xslt. Il risultato è una transazione di 3 secondi, di cui: 2,2
in presentation e 0,8 sul db.

Comunque è una vitaccia! Il tempo si perde sempre dove non ce lo si
aspetta.

Ciao
Jacopo

SeeSaw | Another point of view
www.seesaw.it
[email protected]

3

chiaro scuro wrote:

voi avete esperienze simili su come fare profiling vi abbia aiutato?

si assolutamente, anche se piu sul database che altro. Infatti troppo
spesso l’ottimizzare l’accesso al db e’ considerato un “cittadino di
seconda classe” quando si sviluppa (ed il dba un avversario piuttosto
che un alleato :slight_smile: )

Top 10 Ruby on Rails performance tips | Programming Zen
eh si ce l’ho gia’ nei miei bookmark!

ciao,
Luca

–

Web: http://spazidigitali.com - http://thetyper.com
Email: mailto://[email protected]
Skype: callto://l.mearelli
Tel: +39 347 7764416

4

Il giorno gio, 19/04/2007 alle 12.14 +0200, chiaro scuro ha scritto:

semplicemente mettere la pagination e togliere un po di logging ha
ridotto da 10 a 1 i tempi di una pagina.

voi avete esperienze simili su come fare profiling vi abbia aiutato?

Ecco una mia esperienza:

stavamo modificando un motore wiki abbastanza particolare: la maggior
parte della logica, anziché essere strutturata in metodi delle varie
classi, era contenuta in un due/trecento file di testo che venivano
compilati all’avvio e trasformati in blocchi da inserire in un
dizionario.
La suite di test relativa alle nostre modifiche avviava il motore nel
#setUp e lo fermava nel #tearDown, così con soli 90 test la cosa
diventava troppo lenta (più di 300 secondi!)
Io ero convinto che il problema fosse legato all’accesso al disco, e che
quindi difficilmente avrei potuto risolvere il problema in maniera
semplice. Ma dopo una profilazione ho scoperto che il 95% del tempo di
avvio veniva speso per compilare i file.

Ho risolto il problema passando ad una strategia di tipo setup/reset:
nel setup il motore wiki veniva avviato solo se non c’era già una
instanza in esecuzione; nel tearDown si effettuava un reset del motore,
eliminando le modifiche fatte dai test senza però fermare il motore, ed
evitando la compilazione.

Risultato: l’intera suite girava in 20 secondi.

Giovanni

5

il delay endemico è tipico delle applicazioni enterprise

se non avete problemi di delay, non siete enterprise, per fortuna
c’è acts_as_enterprisey, il plugin che se non ci fosse l’avrei fatto io
:slight_smile:

potete aggiungere arbitrariamente dei delay nei model e toglierli in
fase di produzione per vedere le vostre applicazioni volaaaare!! :smiley:

ad ogni modo, per tornare sul serio, per fare il profiling in genere uso
il profiler di sql server per le prestazioni su db, e firebug (uno dei
migliori plugin per mozilla) per il profiling del javascript

jek

Da: [email protected] per conto di Jacopo M.
Inviato: gio 19/04/2007 12.39
A: ruby-it
Oggetto: Re: [ruby-it] misurare prima di ottimizzare

Il giorno 19/apr/07, alle ore 12:14, chiaro scuro ha scritto:

voi avete esperienze simili su come fare profiling vi abbia aiutato?

Come ben sai io mi occupo dei siti internet di una delle maggiori
case editrici italiane e con questi problemi combatto tutti i giorni.
Per esperienza, non rilasciamo mai il codice se non è ben farcito con
i log sulle prestazioni. Questo perché, anche se i vari ambienti
(prova, staging … ) sono gemelli, la prova del nove è sempre
l’utente finale e cioè la produzione. Una settimana con i questi log
attivi e se non ci sono problemi via anche quelli per andare ancora
più veloci.

Caso di questi giorni: sto ristudiando la presentation del motore di
ricerca di un sito per la vendita di libri on line. Una bomba
l’accesso al db, peccato che, per fare in fretta e avere la massima
elasticità possibile nella visualizzazione, abbiano deciso di usare
xml e xslt. Il risultato è una transazione di 3 secondi, di cui: 2,2
in presentation e 0,8 sul db.

Comunque è una vitaccia! Il tempo si perde sempre dove non ce lo si
aspetta.

Ciao
Jacopo

SeeSaw | Another point of view
www.seesaw.it
[email protected]

Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml