Misuratore performance di un sito PHP

[Cosimo Bortone]

Buon giorno ragazzi,

non so se l'argomento è stato già trattato...se si, chiedo venia e cercherò di reperire i link dalla ml, comunque vorrei sapere se esiste uno strumento, magari opensource in modo da fornirmi un report delle performance di un sito scritto in php.

Mi rendo conto che detta così è molto generica...mi sapete consigliare una metodologia da adottare per poter fare una 'fotografia' prestazionale? 

Tutto questo a prescindere dal server che penso sia comunque Apache. Non conosco ancora i particolari..purtroppo.

Grazie in anticipo per i consigli che vorrete darmi! Magari servirà a riepilogare lo stato dell'arte per voi guru!

Ciao,

Co

[liuggio]

aha- e qui che ti volevo

anche fotografia prestazionale non so cosa sia forse posso suggerirti produzione(Xhprof) e in sviluppo(xdebug).

Ci sono molte best practice in questo caso potresti descriverci restringere il caso?

lento soprattutto durante query?

solo su alcuni controller?

ad alcune ore?

i log danno qualche sintomo particolare?

gli errori riportano qualcosa?
....
..
.

2013/4/4 Cosimo Bortone <mbor...@gmail.com>

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--
 __________________liuggio_________________________________
 
  __/|_      We reject kings, presidents and voting.
/o )   \/    We believe in rough consensus
)__ v _/\          and running code  (I.E.T.F. credo)
______________________________________________________________

[Cosimo Bortone]

.....lo so ragà che è troppo generica la cosa e me ne scuso.... ma non so nulla nel dettaglio....

Volevo sapere soltanto se esisteva qualche best practice, necessariamente generica... che potesse aiutarmi allo scopo!.....

Mimmo Bortone

2013/4/4 liuggio <liu...@gmail.com>

[liuggio]

xhprof / xdebug

2013/4/4 Cosimo Bortone <mbor...@gmail.com>

[Marco D'Alia]

Secondo me ti conviene profilare le query che fai al db, al 90% il collo di bottiglia è li, non credo tu faccia calcoli complessi in php.

Se usi un framework vedi se esiste già uno strumento / plugin per vedere pagina per pagina:

1) quante query fai 

2) quanti ms impiega ogni query

Se non usi un framework è comunque semplice wrappare le chiamate al db e fargli scrivere su un file txt questi dati.

Un'idea tela puoi fare anche guardando lo slow query log di mysql, o innotop, ma per mia esperienza ti conviene vedere pagina per pagina quante query fai, spesso si ha una bella sorpresa...

Marco.

2013/4/4 liuggio <liu...@gmail.com>

[Cosimo Bortone]

Perfetto!

grazie dei preziosi suggerimenti. Immagino però che il db sia Oracle.

Purtroppo non posso dirvi altri particolari perchè non li conosco... Mi hanno anticipato soltanto che ci sono problemi prestazionali su un applicativo PHP.... detta così non dice nulla...lo so....Da cui la mia richiesta 'anticipata' a voi del gruppo!.

Mimmo Bortone

2013/4/4 Marco D'Alia <mad...@gmail.com>

[Gufo Rosso]

prim ottimizza il codice, brevemente - righe di codice + performance

un codice impattonato non identato, senza commenti, semplicemente a capo senza spazi inutili

+30% in prestazioni senza fare altro

if($x==5 e' diverso da 5==$x

altra cosa

switch....(....

case
include..

break

case

include....

break

}

 dalle 50 righe in su e' piu veloce poi ci sono altre chicce

[Riccardo Fraioli]

è prassi usare output_buffering ,settato a no value ?

[liuggio]

gufo non sono d accordo allora anche l'if ternario e gli ' invece che " .

si ottimizza dopo aver capito cosa va lento e poi i Coding standard sono piu importanti

approposito hai capito cosa va lento??

[alessandro cinelli]

cache anyone?

2013/4/5 liuggio <liu...@gmail.com>:

@cirpo

[Cesare D'Amico]

Quelle che suggerisci sono micro-ottimizzazioni che hanno come effetto collaterale di rendere il codice illeggibile; puoi ottenere gli stessi miglioramenti di performance usando una opcode cache (apc, zend server) risparmiando nel contempo eoni nella manutenzione ordinaria del software.

Il giorno 05 aprile 2013 01:57, Gufo Rosso <guf...@gmail.com> ha scritto:

[Jacopo Romei]

Anche io decisamente in disaccordo con Gufo.

In ordine di rilevanza:
- Ricavare un decimillesimo di secondo sulla compilazione del codice PHP e magari non usare opcode caching (che rende inutile ottimizzare il codice da compilare, conservandone copie precompilate)?
- Scrivere codice procedurale in file enormi che vanno ricompilati ad ogni minimo cambiamento, vanificando l'opcode caching, e magari non organizzare il codice in classi piccole e super circorscritte?

- Scrivere righe di codice compattissime in strutture di controllo e strutture dati che per loro natura hanno prestazioni asintotiche pessime, magari esponenziali nel caso migliore?

- Scrivere codice super performante al millisecondo e poi avere query da decimi di secondo, senza considerare il concetto di 'ordine di grandezza'?

- Scrivere codice e query eseguibili in un baleno senza considerare che con la cache giusta le cose non le eseguiamo affatto?

- Scrivere codice velocisssssssimo e illegibile senza considerare che l'azienda vince se i ricavi sono molto superiori alle spese e quindi anche che il costo di qualche CPU/Giga-di-RAM in più sarà sempre più economico del tempo speso a sviluppare codice offuscato e illegibile?

Due capisaldi, anzi tre:

1. Gli sviluppatori e il loro tempo costano molto di più del tempo macchina.

2. Il modo più veloce di fare una cosa è NON farla.

3. La mortazza.

2013/4/5 alessandro cinelli <alessandr...@gmail.com>

--
Jacopo Romei
http://www.sviluppoagile.it/
http://twitter.com/jacoporomei
http://www.anonimarmonisti.com/

[Cesare D'Amico]

Approvo tutto.

Tranne la mortazza ovviamente: lunga vita al seitan :-)

[Matteo Manchi]

Anch'io sono in disaccordo con il codice "Mapazzone" [Cit.]: si diventa
scemi, si riduce di pochi millisecondi quando poi il collo di bottiglia
magari � sulle query.

Porto la mia piccola esperienza: un paio d'anni fa andai a lavorare in
un'azienda dove trovai una situazione del genere: 22 secondi di
generazione di una pagina XML da usare come WebService su 4000 righe di
codice (per la gioia dell'OOP). Inutile compattare 4000 righe di codice,
quando dentro ad un while che iterava circa 13k volte (calcoli meteo) ad
ogni giro doveva fare la stessa query (o poco differente) di select.


Vi lascio un link carino: http://www.phpbench.com/

Il 05/04/2013 09:29, liuggio ha scritto:
>
>
> gufo non sono d accordo allora anche l'if ternario e gli ' invece che " .
>
> si ottimizza dopo aver capito cosa va lento e poi i Coding standard
> sono piu importanti
>
> approposito hai capito cosa va lento??
>
> On Apr 5, 2013 9:16 AM, "Riccardo Fraioli" <rifr...@gmail.com

> <mailto:rifr...@gmail.com>> wrote:
>
> � prassi usare output_buffering ,settato a no value ?

>
>
> Il giorno 05 aprile 2013 01:57, Gufo Rosso <guf...@gmail.com

> <mailto:guf...@gmail.com>> ha scritto:

>
> prim ottimizza il codice, brevemente - righe di codice +
> performance
> un codice impattonato non identato, senza commenti,
> semplicemente a capo senza spazi inutili
> +30% in prestazioni senza fare altro
> if($x==5 e' diverso da 5==$x
> altra cosa
> switch....(....
> case
> include..
> break
> case
> include....
> break
> }
> dalle 50 righe in su e' piu veloce poi ci sono altre chicce
>
>
>
>
> Il giorno 04 aprile 2013 12:59, Cosimo Bortone

> <mbor...@gmail.com <mailto:mbor...@gmail.com>> ha scritto:
>
> Buon giorno ragazzi,
>
> non so se l'argomento � stato gi� trattato...se si, chiedo
> venia e cercher� di reperire i link dalla ml, comunque

> vorrei sapere se esiste uno strumento, magari opensource
> in modo da fornirmi un report delle performance di un sito
> scritto in php.
>

> Mi rendo conto che detta cos� � molto generica...mi sapete

> consigliare una metodologia da adottare per poter fare una
> 'fotografia' prestazionale?
> Tutto questo a prescindere dal server che penso sia
> comunque Apache. Non conosco ancora i particolari..purtroppo.
>
> Grazie in anticipo per i consigli che vorrete darmi!

> Magari servir� a riepilogare lo stato dell'arte per voi guru!
>
> Ciao,
> Co
>
>
> --
> Hai ricevuto questo messaggio perch� sei iscritto al

> gruppo "PUG Roma" di Google Gruppi.
> Visita questo gruppo all'indirizzo
> http://groups.google.com/group/pug-roma?hl=it-IT.
>
>
>
>
> --

> Hai ricevuto questo messaggio perch� sei iscritto al gruppo

> "PUG Roma" di Google Gruppi.
> Visita questo gruppo all'indirizzo
> http://groups.google.com/group/pug-roma?hl=it-IT.
>
>
>
>
> --

> Hai ricevuto questo messaggio perch� sei iscritto al gruppo "PUG

> Roma" di Google Gruppi.
> Visita questo gruppo all'indirizzo
> http://groups.google.com/group/pug-roma?hl=it-IT.
>
>
>
> --

> Hai ricevuto questo messaggio perch� sei iscritto al gruppo "PUG Roma"

[Matteo Cavucci]

entro un po' a gamba tesa che non ne so molto di php minificato, ma certamente so che html+css+js andrebbero minificati sempre quanto vanno in produzione. Il chè è piuttosto semplice: non lavori mai col codice compattato, ma lo si minifica se e solo se va in prod. Il debug si fa altrove. Detto questo, la minificazione migliora, ma magari fosse il +35% come ho letto.

A me fanno sempre le prediche su come Amazon abbia scoperto che ogni 100 millisecondi aggiunti al tempo di caricamento fanno diminuire le vendite del 1%. Google dice che aggiungere mezzo secondo alla pagina dei risultati di una ricerca può fare diminuire il traffico e le entrate dalla pubblicità del 20%.

Che il grosso stia in altre parti mi pare chiaro, ma forse è bene considerare ogni cosa, anche se minima, come utile al bilancio delle prestazioni verso l'utente.

2013/4/5 Matteo Manchi <matteo...@gmail.com>

Anch'io sono in disaccordo con il codice "Mapazzone" [Cit.]: si diventa
scemi, si riduce di pochi millisecondi quando poi il collo di bottiglia

magari è sulle query.

Porto la mia piccola esperienza: un paio d'anni fa andai a lavorare in
un'azienda dove trovai una situazione del genere: 22 secondi di
generazione di una pagina XML da usare come WebService su 4000 righe di
codice (per la gioia dell'OOP). Inutile compattare 4000 righe di codice,
quando dentro ad un while che iterava circa 13k volte (calcoli meteo) ad
ogni giro doveva fare la stessa query (o poco differente) di select.


Vi lascio un link carino: http://www.phpbench.com/



Il 05/04/2013 09:29, liuggio ha scritto:

>
>
> gufo non sono d accordo allora anche l'if ternario e gli ' invece che " .
>
> si ottimizza dopo aver capito cosa va lento e poi i Coding standard
> sono piu importanti
>
> approposito hai capito cosa va lento??
>
> On Apr 5, 2013 9:16 AM, "Riccardo Fraioli" <rifr...@gmail.com

> <mailto:rifr...@gmail.com>> wrote:
>
>     è prassi usare output_buffering ,settato a no value ?

>
>
>     Il giorno 05 aprile 2013 01:57, Gufo Rosso <guf...@gmail.com

>     <mailto:guf...@gmail.com>> ha scritto:

>
>         prim ottimizza il codice, brevemente - righe di codice +
>         performance
>         un codice impattonato non identato, senza commenti,
>         semplicemente a capo senza spazi inutili
>         +30% in prestazioni senza fare altro
>         if($x==5 e' diverso da 5==$x
>         altra cosa
>         switch....(....
>         case
>         include..
>         break
>         case
>         include....
>         break
>         }
>          dalle 50 righe in su e' piu veloce poi ci sono altre chicce
>
>
>
>
>         Il giorno 04 aprile 2013 12:59, Cosimo Bortone

>         <mbor...@gmail.com <mailto:mbor...@gmail.com>> ha scritto:

>
>             Buon giorno ragazzi,
>
>             non so se l'argomento è stato già trattato...se si, chiedo
>             venia e cercherò di reperire i link dalla ml, comunque

>             vorrei sapere se esiste uno strumento, magari opensource
>             in modo da fornirmi un report delle performance di un sito
>             scritto in php.
>

>             Mi rendo conto che detta così è molto generica...mi sapete

>             consigliare una metodologia da adottare per poter fare una
>             'fotografia' prestazionale?
>             Tutto questo a prescindere dal server che penso sia
>             comunque Apache. Non conosco ancora i particolari..purtroppo.
>
>             Grazie in anticipo per i consigli che vorrete darmi!

>             Magari servirà a riepilogare lo stato dell'arte per voi guru!
>
>             Ciao,
>             Co
>
>
>             --
>             Hai ricevuto questo messaggio perché sei iscritto al

>             gruppo "PUG Roma" di Google Gruppi.
>             Visita questo gruppo all'indirizzo
>             http://groups.google.com/group/pug-roma?hl=it-IT.
>
>
>
>
>         --

>         Hai ricevuto questo messaggio perché sei iscritto al gruppo

>         "PUG Roma" di Google Gruppi.
>         Visita questo gruppo all'indirizzo
>         http://groups.google.com/group/pug-roma?hl=it-IT.
>
>
>
>
>     --

>     Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG

>     Roma" di Google Gruppi.
>     Visita questo gruppo all'indirizzo
>     http://groups.google.com/group/pug-roma?hl=it-IT.
>
>
>
> --

> Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma"

> di Google Gruppi.
> Visita questo gruppo all'indirizzo
> http://groups.google.com/group/pug-roma?hl=it-IT.
>
>

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.

[Matteo Manchi]

Ma HTML, CSS e JS vengono minificati per diminuire i dati da inviare in
rete (e da ricevere) essendo quella a volte il collo di bottiglia. Posso
anche metterci 50ms per generare un file html da 3MB, ma sempre x
secondi ci vogliono per farlo caricare. In quel caso � ben differente il
tempo di download dal tempo di esecuzione (rendering html/css/js).

Il 05/04/2013 11:03, Matteo Cavucci ha scritto:
> entro un po' a gamba tesa che non ne so molto di php minificato, ma
> certamente so che html+css+js andrebbero minificati sempre quanto

> vanno in produzione. Il ch� � piuttosto semplice: non lavori mai col

> codice compattato, ma lo si minifica se e solo se va in prod. Il debug
> si fa altrove. Detto questo, la minificazione migliora, ma magari
> fosse il +35% come ho letto.
>
> A me fanno sempre le prediche su come Amazon abbia scoperto che ogni

> 100 /millisecondi/ aggiunti al tempo di caricamento fanno diminuire le

> vendite del 1%. Google dice che aggiungere mezzo secondo alla pagina

> dei risultati di una ricerca pu� fare diminuire il traffico e le
> entrate dalla pubblicit� del 20%.
>
> Che il grosso stia in altre parti mi pare chiaro, ma forse � bene

> considerare ogni cosa, anche se minima, come utile al bilancio delle
> prestazioni verso l'utente.
>
>
>
>
>
>
>
>
>
>
>
>
> 2013/4/5 Matteo Manchi <matteo...@gmail.com

> <mailto:matteo...@gmail.com>>

>
> Anch'io sono in disaccordo con il codice "Mapazzone" [Cit.]: si
> diventa
> scemi, si riduce di pochi millisecondi quando poi il collo di
> bottiglia

> magari � sulle query.

>
> Porto la mia piccola esperienza: un paio d'anni fa andai a lavorare in
> un'azienda dove trovai una situazione del genere: 22 secondi di
> generazione di una pagina XML da usare come WebService su 4000
> righe di
> codice (per la gioia dell'OOP). Inutile compattare 4000 righe di
> codice,
> quando dentro ad un while che iterava circa 13k volte (calcoli
> meteo) ad
> ogni giro doveva fare la stessa query (o poco differente) di select.
>
>
> Vi lascio un link carino: http://www.phpbench.com/
>
>
>
> Il 05/04/2013 09:29, liuggio ha scritto:
> >
> >
> > gufo non sono d accordo allora anche l'if ternario e gli '
> invece che " .
> >
> > si ottimizza dopo aver capito cosa va lento e poi i Coding standard
> > sono piu importanti
> >
> > approposito hai capito cosa va lento??
> >
> > On Apr 5, 2013 9:16 AM, "Riccardo Fraioli" <rifr...@gmail.com
> <mailto:rifr...@gmail.com>

> > <mailto:rifr...@gmail.com <mailto:rifr...@gmail.com>>> wrote:
> >
> > � prassi usare output_buffering ,settato a no value ?

> >
> >
> > Il giorno 05 aprile 2013 01:57, Gufo Rosso
> <guf...@gmail.com <mailto:guf...@gmail.com>

> > <mailto:guf...@gmail.com <mailto:guf...@gmail.com>>> ha

> scritto:
> >
> > prim ottimizza il codice, brevemente - righe di codice +
> > performance
> > un codice impattonato non identato, senza commenti,
> > semplicemente a capo senza spazi inutili
> > +30% in prestazioni senza fare altro
> > if($x==5 e' diverso da 5==$x
> > altra cosa
> > switch....(....
> > case
> > include..
> > break
> > case
> > include....
> > break
> > }
> > dalle 50 righe in su e' piu veloce poi ci sono altre chicce
> >
> >
> >
> >
> > Il giorno 04 aprile 2013 12:59, Cosimo Bortone
> > <mbor...@gmail.com <mailto:mbor...@gmail.com>

> <mailto:mbor...@gmail.com <mailto:mbor...@gmail.com>>> ha scritto:
> >
> > Buon giorno ragazzi,
> >
> > non so se l'argomento � stato gi� trattato...se si,
> chiedo
> > venia e cercher� di reperire i link dalla ml, comunque

> > vorrei sapere se esiste uno strumento, magari opensource
> > in modo da fornirmi un report delle performance di
> un sito
> > scritto in php.
> >

> > Mi rendo conto che detta cos� � molto generica...mi

> sapete
> > consigliare una metodologia da adottare per poter
> fare una
> > 'fotografia' prestazionale?
> > Tutto questo a prescindere dal server che penso sia
> > comunque Apache. Non conosco ancora i
> particolari..purtroppo.
> >
> > Grazie in anticipo per i consigli che vorrete darmi!

> > Magari servir� a riepilogare lo stato dell'arte per

> voi guru!
> >
> > Ciao,
> > Co
> >
> >
> > --

> > Hai ricevuto questo messaggio perch� sei iscritto al

> > gruppo "PUG Roma" di Google Gruppi.
> > Visita questo gruppo all'indirizzo
> > http://groups.google.com/group/pug-roma?hl=it-IT.
> >
> >
> >
> >
> > --

> > Hai ricevuto questo messaggio perch� sei iscritto al gruppo

> > "PUG Roma" di Google Gruppi.
> > Visita questo gruppo all'indirizzo
> > http://groups.google.com/group/pug-roma?hl=it-IT.
> >
> >
> >
> >
> > --

> > Hai ricevuto questo messaggio perch� sei iscritto al gruppo "PUG

> > Roma" di Google Gruppi.
> > Visita questo gruppo all'indirizzo
> > http://groups.google.com/group/pug-roma?hl=it-IT.
> >
> >
> >
> > --

> > Hai ricevuto questo messaggio perch� sei iscritto al gruppo "PUG

> Roma"
> > di Google Gruppi.
> > Visita questo gruppo all'indirizzo
> > http://groups.google.com/group/pug-roma?hl=it-IT.
> >
> >
>
> --

> Hai ricevuto questo messaggio perch� sei iscritto al gruppo "PUG

> Roma" di Google Gruppi.
> Visita questo gruppo all'indirizzo
> http://groups.google.com/group/pug-roma?hl=it-IT.
>
>
>
> --

> Hai ricevuto questo messaggio perch� sei iscritto al gruppo "PUG Roma"

[Jacopo Romei]

La minificazione degli asset è perfettamente dovuta, visto che

1. il 90% del tempo che l'utente web percepisce è speso client-side.

2. nessun sviluppatore front-end lavora con il codice minificato.

Ergo, con la minificazione *automatica* di markup/css/js stiamo:

1. aggredendo il vero collo di bottiglia: quel 90%

2. impattando in quantità nulla il lavoro degli sviluppatori

2013/4/5 Matteo Cavucci <matteo....@gmail.com>

--

[Cosimo Bortone]

Lunedi vi saprò dire di più...visto che finalmente dovrei andare a 'vedere' di che si tratta! ;-)

Molto probabilmente dovrò mettere le mani direttamente su Apache...sempre se i sistemisti me lo lasceranno fare!...

Penso, infatti, che fondamentalmente sia un problema di cache.

Figo xhprof, non lo conoscevo!

P.S: Anche io dissento sulla mortazza.... ;-)

Mimmo Bortone

2013/4/5 Jacopo Romei <jro...@gmail.com>

[Roy]

Come detto la domanda è troppo vaga.

La mia proposta è parti col profilare le richieste che fa il browser, magari sono richieste a siti esterni.

Preferisco usare  xdebug, fai fare un giro con il profiler attivo e poi apri il file prodotto con kcachegrind e ottieni una cosa del genere
http://xdebug.org/docs/profiler
+
http://kcachegrind.sourceforge.net/html/Screenshots.html

Anche se da quel che vedo è praticamente la stessa cosa di XHProf.

Alla fine nel 90% dei casi metti in ordine per tempo proprio della funzione e trovi i colpevoli, di recente mi è successo su un plugin di magento che per verificare la licenza faceva una chiamata ad un sito esterno -.-

[liuggio]

AAAAAH non diciamo che xdebug è la stessa cosa hanno finalità differenti per env differenti

2013/4/5 Roy <tsm...@gmail.com>

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--

[Alessandro Nadalin]

In effetti xdebug in produzione te lo scordi, dato che uccide le performance...ma per profilare in locale va na bomba

[Cosimo Bortone]

si, infatti...

xdebug è impraticabile seppure fichissimo... 

Ho avuto un pò di info i più ma ancora non ci ho messo le zampine sopra.. 

Si tratta di un applicativo che usa moodle  https://moodle.org/

qualcuno ci ha lavorato sopra?

2013/4/5 Alessandro Nadalin <alessandr...@gmail.com>

[Francesco Mosca]

a proposito di prestazioni ed xdebug: ho una suite di test, perlopiù funzionali, che con xdebug attivo impiega il 30-35% di tempo in più a girare. Vi vengono in mente buoni motivi per lasciarlo comunque acceso? (piuttosto che eventualmente attivarlo solo quando ho bisogno di debug approfondito, sempre nel contesto dei test)

f·

2013/4/5 Alessandro Nadalin <alessandr...@gmail.com>

[Roy Bellingan]

a proposito di prestazioni ed xdebug:

Può essere disattivato...
Oppure tenuto attivo ma solo se si aggiunge un &xdebug=1 oppure &profile=1...

Altrimenti si, se è sempre attivo consuma parecchie risorse

--
Roy Bellingan
tsm...@gmail.com
CG & ArchiVIZ http://archidea.us
Programmazione & SysAdmin http://tsmt.eu

[Eugenio Pombi]

@francesco, cosa intendi con "bisogno di debug approfondito"? io mentre sviluppo ogni 5 minuti mi capita di controllare qualcosa col debugger, e se non sbaglio no xdebug, no debugger, no party :)

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.
Visita questo gruppo all'indirizzo http://groups.google.com/group/pug-roma?hl=it-IT.
 
 

--

Eugenio Pombi
Developer

tel:      +39.329.5455797
mail:    eux...@gmail.com
twitter: @euxpom
skype: euxeux

it.linkedin.com/pub/eugenio-pombi/3b/28b/99a

[Francesco Mosca]

@eugenio no, mi sono spiegato male. L'idea è che normalmente durante lo sviluppo ovviamente xdebug è attivo, ma per phpunit no, a meno che non abbia test che falliscano per cause strane per le quali mi può far comodo avere, chessò, lo stacktrace anche da phpunit

(spero sia un po' più chiaro. la premessa è che anche io non saprei vivere senza xdebug :))

2013/4/5 Eugenio Pombi <eux...@gmail.com>

[Roy Bellingan]

Domanda ma l'analisi la devi fare sul server live "a cuore aperto" ?

[Eugenio Pombi]

@francesco, per me lo sviluppo E' phpUnit :)

intendi dire che disattiveresti xdebug solo prima di far girare le eventuali suittone da 10 minuti?

[Roy Bellingan]

On 05/04/2013 17:54, Eugenio Pombi wrote:

Troppa roba ! cancellate le mail citate in precenza che diventa illegibile plz!

[Francesco Mosca]

@Roy: hai ragione, gmail ci vizia (e ci abitua al top-quoting), ma per esempio nel tuo caso non si capisce a chi stai rispondendo

@eugenio: ok, capito cosa intendi. si, diciamo disattiverei xdebug per tutti quei test che mi coprono funzionalità su cui non sto lavorando direttamente, ma che comunque faccio girare sempre (per regression etc.)

f· 

2013/4/5 Roy Bellingan <tsm...@gmail.com>

On 05/04/2013 17:54, Eugenio Pombi wrote:

Troppa roba ! cancellate le mail citate in precenza che diventa illegibile plz!

[Eugenio Pombi]

@francesco: sarebbe figo farlo così selettivamente, se trovi il sistema tienimi informato ;)

Il giorno 05 aprile 2013 18:03, Francesco Mosca <fmo...@gmail.com> ha scritto:

@Roy: hai ragione, gmail ci vizia (e ci abitua al top-quoting), ma per esempio nel tuo caso non si capisce a chi stai rispondendo

@eugenio: ok, capito cosa intendi. si, diciamo disattiverei xdebug per tutti quei test che mi coprono funzionalità su cui non sto lavorando direttamente, ma che comunque faccio girare sempre (per regression etc.)

f·

[Cesare Lasorella]

Concordo con quanto detto da Matteo, non sempre il minifing delle pagine HTML sortisce buoni risultati.
I motori di rendering dei vari browser non ragionano allo stesso modo. (esperienza personale)
Concordo invece sul minimizzare i file js e magari css.

Ciao
Cesare

Inviato da iPhone

Il giorno 05/apr/2013, alle ore 11:08, Matteo Manchi <matteo...@gmail.com> ha scritto:

> Ma HTML, CSS e JS vengono minificati per diminuire i dati da inviare in
> rete (e da ricevere) essendo quella a volte il collo di bottiglia. Posso
> anche metterci 50ms per generare un file html da 3MB, ma sempre x

> secondi ci vogliono per farlo caricare. In quel caso è ben differente il

> tempo di download dal tempo di esecuzione (rendering html/css/js).
>
>
>
> Il 05/04/2013 11:03, Matteo Cavucci ha scritto:
>> entro un po' a gamba tesa che non ne so molto di php minificato, ma
>> certamente so che html+css+js andrebbero minificati sempre quanto

>> vanno in produzione. Il chè è piuttosto semplice: non lavori mai col

>> codice compattato, ma lo si minifica se e solo se va in prod. Il debug
>> si fa altrove. Detto questo, la minificazione migliora, ma magari
>> fosse il +35% come ho letto.
>>
>> A me fanno sempre le prediche su come Amazon abbia scoperto che ogni
>> 100 /millisecondi/ aggiunti al tempo di caricamento fanno diminuire le
>> vendite del 1%. Google dice che aggiungere mezzo secondo alla pagina

>> dei risultati di una ricerca può fare diminuire il traffico e le
>> entrate dalla pubblicità del 20%.
>>
>> Che il grosso stia in altre parti mi pare chiaro, ma forse è bene

>> considerare ogni cosa, anche se minima, come utile al bilancio delle
>> prestazioni verso l'utente.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2013/4/5 Matteo Manchi <matteo...@gmail.com
>> <mailto:matteo...@gmail.com>>
>>
>> Anch'io sono in disaccordo con il codice "Mapazzone" [Cit.]: si
>> diventa
>> scemi, si riduce di pochi millisecondi quando poi il collo di
>> bottiglia

>> magari è sulle query.

>>
>> Porto la mia piccola esperienza: un paio d'anni fa andai a lavorare in
>> un'azienda dove trovai una situazione del genere: 22 secondi di
>> generazione di una pagina XML da usare come WebService su 4000
>> righe di
>> codice (per la gioia dell'OOP). Inutile compattare 4000 righe di
>> codice,
>> quando dentro ad un while che iterava circa 13k volte (calcoli
>> meteo) ad
>> ogni giro doveva fare la stessa query (o poco differente) di select.
>>
>>
>> Vi lascio un link carino: http://www.phpbench.com/
>>
>>
>>
>> Il 05/04/2013 09:29, liuggio ha scritto:
>>>
>>>
>>> gufo non sono d accordo allora anche l'if ternario e gli '
>> invece che " .
>>>
>>> si ottimizza dopo aver capito cosa va lento e poi i Coding standard
>>> sono piu importanti
>>>
>>> approposito hai capito cosa va lento??
>>>
>>> On Apr 5, 2013 9:16 AM, "Riccardo Fraioli" <rifr...@gmail.com
>> <mailto:rifr...@gmail.com>
>>> <mailto:rifr...@gmail.com <mailto:rifr...@gmail.com>>> wrote:
>>>

>>> è prassi usare output_buffering ,settato a no value ?

>>>
>>>
>>> Il giorno 05 aprile 2013 01:57, Gufo Rosso
>> <guf...@gmail.com <mailto:guf...@gmail.com>
>>> <mailto:guf...@gmail.com <mailto:guf...@gmail.com>>> ha
>> scritto:
>>>
>>> prim ottimizza il codice, brevemente - righe di codice +
>>> performance
>>> un codice impattonato non identato, senza commenti,
>>> semplicemente a capo senza spazi inutili
>>> +30% in prestazioni senza fare altro
>>> if($x==5 e' diverso da 5==$x
>>> altra cosa
>>> switch....(....
>>> case
>>> include..
>>> break
>>> case
>>> include....
>>> break
>>> }
>>> dalle 50 righe in su e' piu veloce poi ci sono altre chicce
>>>
>>>
>>>
>>>
>>> Il giorno 04 aprile 2013 12:59, Cosimo Bortone
>>> <mbor...@gmail.com <mailto:mbor...@gmail.com>
>> <mailto:mbor...@gmail.com <mailto:mbor...@gmail.com>>> ha scritto:
>>>
>>> Buon giorno ragazzi,
>>>

>>> non so se l'argomento è stato già trattato...se si,
>> chiedo
>>> venia e cercherò di reperire i link dalla ml, comunque

>>> vorrei sapere se esiste uno strumento, magari opensource
>>> in modo da fornirmi un report delle performance di
>> un sito
>>> scritto in php.
>>>

>>> Mi rendo conto che detta così è molto generica...mi

>> sapete
>>> consigliare una metodologia da adottare per poter
>> fare una
>>> 'fotografia' prestazionale?
>>> Tutto questo a prescindere dal server che penso sia
>>> comunque Apache. Non conosco ancora i
>> particolari..purtroppo.
>>>
>>> Grazie in anticipo per i consigli che vorrete darmi!

>>> Magari servirà a riepilogare lo stato dell'arte per

>> voi guru!
>>>
>>> Ciao,
>>> Co
>>>
>>>
>>> --

>>> Hai ricevuto questo messaggio perché sei iscritto al

>>> gruppo "PUG Roma" di Google Gruppi.
>>> Visita questo gruppo all'indirizzo
>>> http://groups.google.com/group/pug-roma?hl=it-IT.
>>>
>>>
>>>
>>>
>>> --

>>> Hai ricevuto questo messaggio perché sei iscritto al gruppo

>>> "PUG Roma" di Google Gruppi.
>>> Visita questo gruppo all'indirizzo
>>> http://groups.google.com/group/pug-roma?hl=it-IT.
>>>
>>>
>>>
>>>
>>> --

>>> Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG

>>> Roma" di Google Gruppi.
>>> Visita questo gruppo all'indirizzo
>>> http://groups.google.com/group/pug-roma?hl=it-IT.
>>>
>>>
>>>
>>> --

>>> Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG

>> Roma"
>>> di Google Gruppi.
>>> Visita questo gruppo all'indirizzo
>>> http://groups.google.com/group/pug-roma?hl=it-IT.
>>
>> --

>> Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG

>> Roma" di Google Gruppi.
>> Visita questo gruppo all'indirizzo
>> http://groups.google.com/group/pug-roma?hl=it-IT.
>>
>>
>>
>> --

>> Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma"

>> di Google Gruppi.
>> Visita questo gruppo all'indirizzo
>> http://groups.google.com/group/pug-roma?hl=it-IT.
>
> --

> Hai ricevuto questo messaggio perché sei iscritto al gruppo "PUG Roma" di Google Gruppi.

[Roy Bellingan]

On 05/04/2013 18:27, Eugenio Pombi wrote:

@francesco: sarebbe figo farlo così selettivamente, se trovi il sistema tienimi informato ;)

Purtroppo che io sappia a meno di commentare la riga "che lo carica" alias la zend load plugin ecc all'inizio del file e riavviare apache - php-fpm non ci sono alternative per disabilitare lo stack trace degli errori.

[Cosimo Bortone]

si...su moodle 3.4.

Come profilatore delle varie pagine cosa mi consigliate, non avendo accesso al server, ma solo all'applicazione. 

Mi servirebbe un sistema che mi consentisse di esprimere in quanti ms vengono caricati i singoli elementi delle pagine, in modo da poter misurare un 'prima intervento' ed un 'dopo'.

2013/4/5 Roy Bellingan <tsm...@gmail.com>

Domanda ma l'analisi la devi fare sul server live "a cuore aperto" ?

[liuggio]

ciao hai letto i messaggi precedenti?

2013/4/8 Cosimo Bortone <mbor...@gmail.com>

[Cosimo Bortone]

@liuggio: ..ho letto adesso...

2013/4/8 liuggio <liu...@gmail.com>

[Matteo Manchi]

È stato postato oggi su un gruppo di facebook (Web Developer Italiani):
Forp e la sua ui
http://anthonyterrien.com/forp/
http://anthonyterrien.com/forp-ui

Qualcuno l'ha mai usato? Io visto oggi e non ho avuto il tempo di testarlo.

[Roy Bellingan]

On 08/04/2013 14:59, Matteo Manchi wrote:

È stato postato oggi su un gruppo di facebook (Web Developer Italiani):
Forp e la sua ui
http://anthonyterrien.com/forp/
http://anthonyterrien.com/forp-ui

Simpatica e veloce, ma in pratica non aggiunge molto alle soluzioni attuali..
La gui è un sacco carina...

[Cosimo Bortone]

comunque sto usando YSlow ed è una bomba! Era esattamente quello che cercavo!

2013/4/8 Roy Bellingan <tsm...@gmail.com>

--

[Marco D'Alia]

ma allora era un problema di html, immagini e javascript, non di php

2013/4/8 Cosimo Bortone <mbor...@gmail.com>

[Roy Bellingan]

ma allora era un problema di html, immagini e javascript, non di php

^_^

[Cosimo Bortone]

Prima di affrontare il 'come' ottimizzare, e naturalmente e anche 'cosa', se le query (su mysql) oppure i plugin php creati (chi sa da chi...) (oppure anche lato server attivando la cache per esempio), per moodle, a me serviva una fotografia dei tempi di caricamento delle varie pagine (tutto: js, css, img, png) in modo da avere una 'fotografia' da presentare al cliente dello stato del sito così allo stato attuale.

Dopo aver ottimizzato le parti che possono essere ottimizzate (query, codice, o quant'altro...nei limiti di quello che posso fare..) rieseguirò la stessa analisi che immagino mi fornirà risultati migliori...

Alla fine potrò dire di aver ottimizzato il sito del, diciamo per dire, il 25%...

Era questo il discorso.. Scusare se non sono stato chiarissimo... 

2013/4/8 Marco D'Alia <mad...@gmail.com>