Me hice cargo de un sitio de e-comm de wordpress (aunque esta pregunta es más sobre la creación de perfiles en general) que tiene un problema de rendimiento que aparentemente solo afecta un área específica en la sección de administración del CMS. Al intentar editar un tipo particular de producto, que tiene una gran cantidad de atributos adjuntos, la página hace que el navegador se bloquee el 99% de las veces. Esperaba que esto se debiera a las consultas de MySQL que causaban el cuello de botella; sin embargo, cuando perfilé la base de datos, obtuve los siguientes resultados:
Consultas totales: 174 – Tiempo total de consultas MySQL: 0.11370
Esto sugiere que el cuello de botella está ocurriendo en otro lugar, pero no estoy seguro de dónde podría estar. Si ejecuto YSlow en la página, no hay nada drástico que explique el problema, aunque hay alrededor de 20 scripts y hojas de estilo cargados, por lo que se podría hacer alguna optimización allí. Voy a habilitar una biblioteca de caché de código de operación que mejorará el rendimiento de PHP, pero ¿hay algo más que pueda hacer para tratar de identificar el problema aquí? Gracias.
Use un generador de perfiles como Xdebug… si el problema no está en la base de datos, mi PHP tiene el problema… descubra qué parte del código está tardando más… Xdebug le dirá el tiempo empleado por llamada de función, así como el uso de la memoria .
La última vez que hice un perfil de wordpress, me tomó una docena microtime(1)Cálculos basados en para detectar el lugar que tomó la mitad de 2,5 segundos de tiempo de carga. Estaba cargando y analizando el archivo de localización .mo.
También se obtuvo una ganancia considerable al instalar el caché de APC, ya que resultó que wordpress es un monstruo pesado que consume mucho tiempo para analizar sus códigos.
me gustaría
- Usar bicho de fuegoo el panel Net de Chrome para ver si es la página o JavaScript/CSS/imges lo que está causando la ralentización (front-end)
- Usar rizo para ver cuanto tarda la pagina:
time curl -b PHPSESSID=123 http://example.com/wp-admin/ - habilitar/instalar xdebug y activa la creación de perfiles. Usar KCachegrind para ver qué funciones están causando los mayores retrasos.
Nir Alfasi
chinche de fuego (complemento de Firefox) es la mejor herramienta que conozco para localizar tales problemas. También puede instalar otro complemento llamado “velocidad de la página“. le mostrará exactamente qué parte tarda más en cargarse. Otra opción es depurar su código con la impresión de “tiempo” y ver cuál tiene la mayor diferencia de tiempo:
http://php.net/manual/en/function.microtime.php
Si el navegador falla, es probable que haya demasiado HTML de una forma específica que bloquee el navegador. ¿O “bloquear el navegador” no estaba realmente bloqueando el navegador?
– hakré
29 de enero de 2012 a las 19:38
Bueno, en Chrome, la página se congela durante unos minutos, a veces se recupera, a veces no.
– bsod99
29 de enero de 2012 a las 19:41
¿La página ya estaba completamente cargada? ¿Deshabilitaste javascripts?
– hakré
29 de enero de 2012 a las 19:42
He probado con y sin JS habilitado. Sin JS, la página parece cargarse de manera más consistente, aunque aún lleva mucho tiempo
– bsod99
29 de enero de 2012 a las 19:51
Métrica también el tamaño de salida de la página. Sospecho que es bastante grande. Deshabilite javascript por el momento para reducir los efectos secundarios.
– hakré
29 de enero de 2012 a las 20:05