¿Cómo debugar por qué va lento todo?
Xavi Montero
Si una aplicaci�n sf2 en entorno de desarrollo va lenta (ie: unos 2 � 3
segundos por request de http) �qu� herramientas tenemos para comprobar
qu� parte o m�dulo est� haciendo de cuello de botella?
Gracias!
Xavi.
Carlos Zuniga
> Hola,
>
> Si una aplicación sf2 en entorno de desarrollo va lenta (ie: unos 2 ó 3
> segundos por request de http) ¿qué herramientas tenemos para comprobar qué
> parte o módulo está haciendo de cuello de botella?
>
Hola,
Puedes usar el profiler de xdebug, que te permite ver el tiempo
utilizado por cada función llamada durante la ejecución
http://xdebug.org/docs/profiler
A parte el WebDebugToolbar de Symfony2 te da información sobre tiempo
usado en las queries de Doctrine.
Saludos
--
Linux Registered User # 386081
A menudo unas pocas horas de "Prueba y error" podrán ahorrarte minutos
de leer manuales.
Marcelo Prizmic
--
Has recibido este mensaje porque estás suscrito al grupo "symfony-es" de Google Groups.
Para publicar en este grupo, envía un email a symfo...@googlegroups.com
Para darte de baja, envía un email a symfony-es+...@googlegroups.com
El resto de opciones puedes encontrarlas en http://groups.google.com/group/symfony-es?hl=es
Marcelo
Nacho Pacheco
Xavi Montero
entiendo que es puro de PHP y por tanto es completamente independiente
de que se trate de sf2. Siemplemente "debugar�a cualquier cosa" y por
tanto sf2 tambi�n �correcto?
> Puedes usar el profiler de xdebug, que te permite ver el tiempo
> utilizado por cada funci�n llamada durante la ejecuci�n
> http://xdebug.org/docs/profiler A parte el WebDebugToolbar de Symfony2
> te da informaci�n sobre tiempo usado en las queries de Doctrine. Saludos
Xavi Montero
(valores de variables, etc) sino a los cuellos de botella en tiempo de
ejecuci�n. Si una llamada tarda 300ms pero intuitivamente deber�a tardar
30ms, saber por qu� est� tardando tanto.
Entiendo que la propuesta de Netbeans no va por ese lado �correcto?
> Con Netbeans pod�s hacer un seguimiento de la ejecuci�n l�nea por
> l�nea de c�digo y ver que va pasando con el valor de cada variable.
Xavi Montero
ayudar a identificar los puntos cr�ticos de ejecuci�n. Es decir,
entiendo que desactivas la cach� para que el debugger no se confunda
pero no comprendo si eso ayuda de alg�n modo a saber si la llamada a tal
o cual funci�n es lo que enlentece la ejecuci�n.
El 11/04/2012 22:04, Nacho Pacheco escribi�:
Marcelo Prizmic
He leído con atención el artículo pero no he comprendido cómo me puede ayudar a identificar los puntos críticos de ejecución. Es decir, entiendo que desactivas la caché para que el debugger no se confunda pero no comprendo si eso ayuda de algún modo a saber si la llamada a tal o cual función es lo que enlentece la ejecución.
El 11/04/2012 22:04, Nacho Pacheco escribió:
--
Has recibido este mensaje porque estás suscrito al grupo "symfony-es" de Google Groups.
Para publicar en este grupo, envía un email a symfo...@googlegroups.com
Para darte de baja, envía un email a symfony-es+unsubscribe@googlegroups.com
lo de Netbeans no va en primera instancia por el lado del tiempo sino en saber bien que hace el código. luego se puede evaluar si hay algo de más que al sacarlo te pueda hacer reducir los tiempos, o no.
marcelo
Xavi Montero
El "profiler de symfony2" que se encarga de capturar la info para
mostrar en el debug-toolbar... �es en realidad el mismo "profiler de
xdebug" gen�rico de php nativo?
El 11/04/2012 22:52, Xavi Montero escribi�:
Carlos Zuniga
> Una pregunta tonta sobre le xdebug...
>
> El "profiler de symfony2" que se encarga de capturar la info para mostrar en
> de php nativo?
>
No, el profiler de Symfony2 es el que aparece en la barra de debug en
el sitio web y lo que hace es mostrar información de los eventos,
emails enviados, queries de doctrine, etc.
El profiler de xdebug lo que hace es generar un log de cada función
llamada durante la ejecución del código (que puede ser cualquier
código php) y su duración. Luego puedes visualizar esta información
con el kcachegrind.
Deberías usarlo en modo producción ya que en modo debug seguro que lo
más lento va a ser la regeneración de caches que en producción no
sucede.
>
> El 11/04/2012 22:52, Xavi Montero escribió:
>
>> Ostras tiene muy buena pinta el xdebug. No lo conocía. Por lo que veo,
>> entiendo que es puro de PHP y por tanto es completamente independiente de
>> que se trate de sf2. Siemplemente "debugaría cualquier cosa" y por tanto sf2
>> también ¿correcto?
Correcto :)