# Misurare prima di ottimizzare **URL:** \ **Category:** IT\ **Created:** [April 19, 2007, 12:15pm UTC](https://www.ruby-forum.com/t/misurare-prima-di-ottimizzare/92425 "2007-04-19T12:15:51Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![chiaroscuro](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c5a1d2/32.png) [@chiaroscuro](https://www.ruby-forum.com/u/chiaroscuro)\ **Post date:** [April 19, 2007, 12:15pm UTC](https://www.ruby-forum.com/t/misurare-prima-di-ottimizzare/92425/1 "2007-04-19T12:15:51Z")
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: > **[Top 10 Ruby on Rails performance tips | Programming Zen](https://programmingzen.com/top-10-ruby-on-rails-performance-tips/)** > > Please note that this article is now obsolete. The performance of Ruby on Rails is influenced by many factors, particularly the configuration of your deployment server(s). However the application code can make a big difference and determine whether... ---
**Author:** ![chiaroscuro](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c5a1d2/32.png) [@chiaroscuro](https://www.ruby-forum.com/u/chiaroscuro)\ **Post date:** [April 19, 2007, 12:40pm UTC](https://www.ruby-forum.com/t/misurare-prima-di-ottimizzare/92425/2 "2007-04-19T12:40:57Z")
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 removed\_email\_address@domain.invalid ---
**Author:** ![chiaroscuro](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c5a1d2/32.png) [@chiaroscuro](https://www.ruby-forum.com/u/chiaroscuro)\ **Post date:** [April 19, 2007, 2:07pm UTC](https://www.ruby-forum.com/t/misurare-prima-di-ottimizzare/92425/3 "2007-04-19T14:07:30Z")
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 🙂 ) - vedi un po tutto quello che scrive Tom Kyte su Oracle e.g.: [http://tkyte.blogspot.com/2007/02/how-to-scale.html](http://tkyte.blogspot.com/2007/02/how-to-scale.html) > [Top 10 Ruby on Rails performance tips | Programming Zen](http://www.antoniocangiano.com/articles/2007/02/10/top-10-ruby-on-rails-performance-tips) > eh si ce l’ho gia’ nei miei bookmark! ciao, Luca – ## Web: [http://spazidigitali.com](http://spazidigitali.com) - [http://thetyper.com](http://thetyper.com) Email: mailto://removed\_email\_address@domain.invalid Skype: callto://l.mearelli Tel: +39 347 7764416 ---
**Author:** ![chiaroscuro](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c5a1d2/32.png) [@chiaroscuro](https://www.ruby-forum.com/u/chiaroscuro)\ **Post date:** [April 19, 2007, 7:51pm UTC](https://www.ruby-forum.com/t/misurare-prima-di-ottimizzare/92425/4 "2007-04-19T19:51:35Z")
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 ---
**Author:** ![chiaroscuro](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c5a1d2/32.png) [@chiaroscuro](https://www.ruby-forum.com/u/chiaroscuro)\ **Post date:** [April 19, 2007, 4:24pm UTC](https://www.ruby-forum.com/t/misurare-prima-di-ottimizzare/92425/5 "2007-04-19T16:24:03Z")
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 🙂 potete aggiungere arbitrariamente dei delay nei model e toglierli in fase di produzione per vedere le vostre applicazioni volaaaare!! 😃 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: removed\_email\_address@domain.invalid 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 removed\_email\_address@domain.invalid * * * Ml mailing list removed\_email\_address@domain.invalid [http://lists.ruby-it.org/mailman/listinfo/ml](http://lists.ruby-it.org/mailman/listinfo/ml)