varios tablas statement relacionadas registros prepared multiples insertar ejemplos datos php performance benchmarking microtime

tablas - pdo php ejemplos



Cómo comparar la eficiencia del script PHP (9)

Deberá mirar Xdebug y más específicamente, Xdebug .

Básicamente, habilita el generador de perfiles y cada vez que carga una página web crea un archivo cachegrind que se puede leer con WinCacheGrind o KCacheGrind .

Xdebug puede ser un poco difícil de configurar, así que aquí está la sección relevante de mi php.ini para referencia:

[XDebug] zend_extension = h:/xampp/php/ext/php_xdebug-2.1.1-5.3-vc6.dll xdebug.remote_enable=true xdebug.profiler_enable_trigger=1 xdebug.profiler_output_dir=h:/xampp/cachegrind xdebug.profiler_output_name=callgrind.%t_%R.out

Y aquí hay una captura de pantalla de un archivo WinCacheGrind en WinCacheGrind :

Eso debería proporcionar amplios detalles sobre cuán eficiente es su script PHP. Desea orientar las cosas que toman la mayor cantidad de tiempo. Por ejemplo, puede optimizar una función para que ocupe la mitad del tiempo, pero sus esfuerzos se verían mejor si se optimiza una función que se llama docenas, sino cientos de veces, durante la carga de una página.

Si tiene curiosidad, esta es solo una versión anterior de un CMS que escribí para mi propio uso.

Quiero saber cuál es la mejor manera de comparar mis scripts PHP. No importa si un trabajo cron, o página web o servicio web.

Sé que puedo usar microtime pero, ¿realmente me está dando el tiempo real de un script PHP?

Quiero probar y comparar diferentes funciones en PHP que hacen lo mismo. Por ejemplo, preg_match vs strpos o domdocument vs preg_match o preg_replace vs str_replace`

Ejemplo de una página web:

<?php // login.php $start_time = microtime(TRUE); session_start(); // do all my logic etc... $end_time = microtime(TRUE); echo $end_time - $start_time;

Esto dará como resultado: 0.0146126717 (varía todo el tiempo, pero ese es el último que obtuve). Esto significa que tomó 0.015 más o menos para ejecutar el script PHP.

¿Hay una mejor manera?


Eric,

Te estás haciendo la pregunta incorrecta. Si su script se está ejecutando en ~ 15 mSec, entonces su hora es en gran medida irrelevante. Si ejecuta en un servicio compartido, la activación de imágenes PHP tomará ~ 100 mSec, leyendo en los archivos de script ~ 30-50 mSec si está completamente en caché en el servidor, posiblemente 1 o más segundos si se carga desde una granja de servidores NAS de back-end. Las demoras en la red al cargar los muebles de la página pueden agregar muchos segundos.

El problema principal aquí es la percepción que tiene el usuario del tiempo de carga: cuánto tiempo debe esperar entre hacer clic en el enlace y obtener una página completa. Eche un vistazo a Google Page Speed, que puede usar como extensión Ff o Chrome, y la documentación de Pagespeed, que analiza en profundidad cómo obtener un buen rendimiento de la página. Siga estas pautas y trate de obtener los puntajes de su página mejor que 90/100. (La página de inicio de Google puntúa 99/100 al igual que mi blog). Esta es la mejor manera de obtener un buen rendimiento percibido por el usuario.


Me gustaría ver en xhprof . No importa si se ejecuta en el cli o a través de otro sapi (como fpm o fcgi o incluso el módulo de Apache).

La mejor parte de xhprof es que incluso está en condiciones de ejecutarse en producción. Algo que no funciona tan bien con xdebug (la última vez que lo revisé). xdebug tiene un impacto en el rendimiento y xhprof (no diría que no hay ninguno) se maneja mucho mejor.

Con frecuencia usamos xhprof para recolectar muestras con tráfico real y luego analizar el código desde allí.

En realidad, no es un punto de referencia en términos que le da tiempo y todo eso, aunque también lo hace. Simplemente hace que sea muy fácil analizar el tráfico de producción y luego profundizar en el nivel de función php en el callgraph recopilado.

Una vez que se compila y carga la extensión, comienza a perfilar el código con:

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

Para detener:

$xhprof_data = xhprof_disable();

A continuación, guarde los datos en un archivo o base de datos, lo que sea que flote su boath y no interrumpa el tiempo de ejecución habitual. Pasamos esto de forma asíncrona a S3 para centralizar los datos (para poder ver todas las ejecuciones desde todos nuestros servidores).

El código en github contiene una carpeta xhprof_html que puedes volcar en el servidor y, con una configuración mínima, puedes visualizar los datos recopilados y comenzar a profundizar.

HTH!


Para comparar qué tan rápido se ejecuta su secuencia de comandos completa en el servidor, hay muchas herramientas que puede usar. Primero asegúrese de que su script (preg_match vs strpos por ejemplo) tenga los mismos resultados para calificar su prueba.

Puedes usar:


Ponlo en un ciclo para hacer cada cosa 1,000,000 de veces para obtener un número más realista. Y solo inicie el temporizador justo antes del código que realmente quiere comparar, luego registre el tiempo de finalización justo después (es decir, no inicie el temporizador antes de la session_start() .

También asegúrese de que el código sea idéntico para cada función que desee comparar, con la excepción de la función que está cronometrando.

La forma en que se ejecuta el script (cronjob, php desde la línea de comandos, Apache, etc.) no debería marcar una diferencia, ya que solo se mide la diferencia relativa entre la velocidad de las diferentes funciones. Entonces esta relación debería permanecer igual.

Si la computadora en la que está ejecutando la evaluación comparativa tiene muchas otras cosas en marcha, esto podría afectar los resultados de la evaluación comparativa si se produce un aumento en el consumo de CPU o memoria de otra aplicación mientras se ejecuta su punto de referencia. Pero mientras tenga muchos recursos en la computadora, no creo que esto sea un problema.


Prueba https://github.com/fotuzlab/appgati

Permite definir pasos en el código y reporta el tiempo, el uso de la memoria, la carga del servidor, etc. entre dos pasos.

Algo como:

$appgati->Step(''1''); // Do some code ... $appgati->Step(''2''); $report = $appgati->Report(''1'', ''2''); print_r($report);

Matriz de salida de muestra:

Array ( [Clock time in seconds] => 1.9502429962158 [Time taken in User Mode in seconds] => 0.632039 [Time taken in System Mode in seconds] => 0.024001 [Total time taken in Kernel in seconds] => 0.65604 [Memory limit in MB] => 128 [Memory usage in MB] => 18.237907409668 [Peak memory usage in MB] => 19.579357147217 [Average server load in last minute] => 0.47 [Maximum resident shared size in KB] => 44900 [Integral shared memory size] => 0 [Integral unshared data size] => 0 [Integral unshared stack size] => [Number of page reclaims] => 12102 [Number of page faults] => 6 [Number of block input operations] => 192 [Number of block output operations] => [Number of messages sent] => 0 [Number of messages received] => 0 [Number of signals received] => 0 [Number of voluntary context switches] => 606 [Number of involuntary context switches] => 99 )


Si realmente quiere comparar el código del mundo real, use herramientas como Xdebug y XHProf .

Xdebug es ideal para cuando trabajas en desarrollo / etapas, y XHProf es una gran herramienta para la producción y es seguro ejecutarlo allí (siempre y cuando leas las instrucciones). Los resultados de una única carga de página no van a ser tan relevantes como ver cómo se desempeña el código, mientras que al servidor se le da un martilleo para hacer un millón de cosas más y escasean los recursos. Esto plantea otra pregunta: ¿estás bloqueando la CPU? ¿RAM? E / S?

También debe mirar más allá del código que está ejecutando en sus scripts para saber cómo se están sirviendo sus scripts / páginas. ¿Qué servidor web estás usando? A modo de ejemplo, puedo hacer que nginx + PHP-FPM realice seriamente mod_php + Apache, que a su vez es superado por servir contenido estático mediante el uso de un buen CDN.

¿Lo siguiente a considerar es para qué estás tratando de optimizar?

  • ¿Es la prioridad número uno la velocidad con que la página representa en el navegador de los usuarios?
  • ¿Se devuelve cada solicitud al servidor lo más rápido posible con el menor consumo de CPU?

A los primeros se les puede ayudar haciendo gzip de todos los recursos enviados al navegador, pero hacerlo podría (en algunas circunstancias) alejarlos del logro de este último.

Afortunadamente, todo lo anterior puede ayudar a demostrar que las pruebas de "laboratorio" cuidadosamente aisladas no reflejarán las variables y los problemas que encontrará en la producción, y que debe identificar cuál es su objetivo de alto nivel y qué puede hacer para llegar allí, antes de ir por la ruta de optimización micro / prematura al infierno .


También es bueno mantener sus ojos en su código PHP y verificarlo con este link , para asegurarse de que su codificación no perturbe el rendimiento de la aplicación.


Un buen comienzo es usar xdebugs profiler Xdebug

Tal vez no sea lo más fácil de configurar y usar, pero una vez que lo haces funcionar, los enormes volúmenes de datos y la facilidad de visualización son irremplazables.