php - microsegundos - ¿Qué se considera un largo tiempo de ejecución?

php microtime to seconds (13)

¿Necesita ser más rápido y por qué?

Si la respuesta es "Sí, porque está en la lista de requisitos" o "Porque requiere valiosos recursos del servidor" , intente optimizar sus consultas SQL. Tal vez necesite agregar índice (s) ...

De lo contrario, creo que deberías pasar a la siguiente tarea. Primero, funciona y segundo, estás hablando de .3 a .5 seg. que debería ser lo suficientemente rápido para los humanos y las máquinas.

Estoy tratando de averiguar la eficiencia del código del lado de mi servidor.

Utilizando microtime(true) para medir la velocidad, puedo calcular el tiempo que tardó en ejecutarse mi script.

Estoy obteniendo velocidades promedio de .3 a .5 segundos. Estos scripts realizan una serie de consultas de base de datos para devolver valores diferentes al usuario.

¿Qué se considera un tiempo de ejecución eficiente para los scripts PHP que se ejecutarán en línea para un sitio web?

Sé que depende exactamente de lo que se está haciendo, pero solo considere esto como un script estándar que se lee de una base de datos y devuelve valores al usuario. Miro a Google y los veo buscar en internet en .15 segundos y siento que mi script es una mierda.

Apunta a <200ms.

La gente comienza a perder cada vez más la paciencia por los tings que toman> 200 ms.

Con PHP, la mayoría de los sitios web se generan tan rápido que el mayor retraso es el procesamiento de la página, incluidas todas las solicitudes secundarias, como las imágenes que se muestran.
Pero también la velocidad y la calidad de la conexión a Internet del visitante, su computadora y su software son factores importantes.

Para ser generoso, digamos que PHP toma el 20% del tiempo total de carga y representación de una página web.
Y nuevamente, sé que este porcentaje es muy aproximado, pero es más como un ejemplo ilustrativo.

El tiempo promedio de carga de una página es de alrededor de 3 segundos. (que es demasiado) Los sitios web de buena calidad deben tardar aproximadamente 1 segundo en cargarse completamente, por lo que se permitirá a PHP 200ms (20% de 1 segundo) para generar la salida. Por lo tanto, php puede tardar hasta 600 ms en un sitio web "promedio".

Nota: El tiempo de ejecución de PHP puede mejorarse cambiando su proveedor o mejorando su código fuente.

Depende, como se dijo, pero además considere esto: con un tiempo de ejecución de un segundo, podrá atender (en condiciones ideales) solo una solicitud por segundo en una máquina servidor con una CPU y donde no suceda nada más en eso máquina. Si tiene más solicitudes de entrada que una por segundo, obtendrá una larga cola y su servidor se ejecutará de inmediato, lo que hará que las solicitudes entrantes se demoren más en procesarse. Si recibe menos solicitudes, aún debe prestar atención a la utilización de la CPU. Si el servidor ya está muy cargado, es posible que tenga un problema que deba ser atendido.

Existen métodos matemáticos (teoría de colas) que se pueden usar para analizar los requisitos de capacidad; consulte, por ejemplo, PDQ ( http://www.perfdynamics.com/Tools/PDQ.html ) para obtener más información.

Por lo tanto, comparar con Google puede no ser justo, ya que deben tener cantidades masivas de solicitudes entrantes y, con un tiempo de ejecución 3 veces mayor, necesitarían varias veces más servidores de los que ya tienen ...

El tiempo de procesamiento de la página de destino de YouTube es <100 ms ( Video aquí a las 7:00).

Su cuello de botella es probablemente una consulta de base de datos - intente usar

EXPLAIN select * from x...

para ver si puede agregar índices que aceleren sus consultas.

editar el enlace de arriba ha muerto. High Scalability hizo una función en YouTube que usó ese video como su fuente principal, por lo que puede ser de interés: http://highscalability.com/youtube-architecture

Esto es, por supuesto, muy subjetivo, depende del sitio, etc. etc.

Sin embargo, diría que cuando una página comienza a tardar más de unos 100 milisegundos, es un retraso notable para el usuario, y eso podría ser "demasiado largo". Eso es si esta es una página que puede esperarse razonablemente que se cargue instantáneamente. Si la página es una página de búsqueda, haciendo una búsqueda de texto completo en una base de datos grande, la situación es, por supuesto, diferente.

He realizado un sitio WP con una búsqueda bastante pesada y un procedimiento de recopilación de estadísticas agregadas en una de sus páginas.

El módulo PHP respectivo obtiene aproximadamente 500 registros de la base de datos y luego decodifica cada uno de los que solicitan la base de datos para obtener más detalles sobre, por ejemplo, 10 campos personalizados diferentes para agregar todos los datos complementarios necesarios para el front-end.

Luego devuelve solo una página de datos (por ejemplo, 20 elementos) y la información de estadísticas (otros 10 elementos).

Mirando mis herramientas de desarrollo de Chrome tiempo

mi máquina de desarrollo local necesita ~ 0.9 - 1.1 segundos para TTFB para cada solicitud XHR que inicie el procedimiento de backend descrito anteriormente.
el servidor web real en un alojamiento compartido bastante bueno para la misma página requiere 0,3-0,6 segundos para TTFB .

Obviamente, esto no es una figura de rendimiento de base de datos limpia, Apache y PHP <-> MySQL se interponen en el tiempo, pero como cifra aproximada está bien puede usarse. Aquí no se presentan sobrecargas de conexión de SSL, etc. Justo el tiempo que tomó el servidor para preparar los datos y responder, no se vuelve a cargar la página, ya que se trata de una solicitud XHR.

Si el sitio en cuestión en una hora pico tiene 100 visitantes / hora visitando esa misma página cargada de base de datos en una hora pico, es solo ~ 2 usuarios / minuto , por lo que con su solicitud de 0.5 seg / visitante puede atender a 60 visitantes / minuto y llamarlo el cuello de botella. Obviamente, la capacidad de rendimiento adicional es enorme en este caso imaginario.

Hum ... No estoy seguro de que un valor absoluto sea bastante justo aquí. Realmente depende del hardware ... Cuando me desarrollo localmente, mi máquina desarrolladora funciona entre 5 y 10 veces más lenta que el servidor activo. Entonces, si tomamos un valor absoluto, el rango "aceptable" variaría dependiendo del hardware.

Bueno, generalmente trato de mantener las cosas por debajo de 100 ms. Si el tiempo de carga del servidor es mayor, rastrearé la ejecución e intentaré averiguar qué es lo que está mal. Tengo que decir que la mayoría de las veces, la base de datos (de ahí las consultas) son el cuello de botella. Un verdadero trabajo en eso es realmente importante.

Me doy cuenta de que, como editor en Wikipedia, no vemos quejas hasta que el inicio de carga de la página exceda de 5 a 10 segundos. Por supuesto, el mecanismo para reportar tal lentitud es oscuro para la mayoría de los usuarios.

Para mí, como usuario de sitios web de viajes, me siento adecuadamente aplacado por una pantalla intermedia que dice "Recibí su solicitud. Ahora se está procesando. Puede tardar hasta X segundos".

Me parece un poco alto.

Para referencia, mi marco que he creado está obteniendo tiempos de ejecución tan bajos como .0028 y tan altos como .0340 segundos. En promedio, cada página suele tener entre 11 y 18 consultas SQL.

Sin embargo, tenga en cuenta que este es un marco altamente optimizado, que aprovecha el almacenamiento en caché, la codificación muy cuidadosa de las consultas y la carga automática. Intenta implementar esas tácticas, y deberías ver una gran mejora.

Todo es relativo, en realidad. No espere obtener tiempos a la par con otros sitios usando PHP. Recuerde, PHP necesita cargar todo desde cero en cada carga de página.

Realmente desea ver qué tan bien funciona su sitio bajo carga, como usar Apache ab para probarlo. Si su sitio puede manejar el nivel de tráfico más alto que puede esperar, entonces no necesita optimizarlo más. Un usuario no podrá saber si su página se carga en .75 segundos o .25 segundos.

Recuerde, llamar al microtiempo en sí mismo agregará tiempo a la carga de su página, ya que tiene que hacer una llamada al sistema operativo (cambio de contexto). Puede ser más valioso optimizar la página, hacerla más pequeña para que pueda ir más rápido a la red y se muestre más rápido una vez en el cliente.

Yo diría que 10 veces menos estaría bien. El número de consultas no importa sin embargo. Puede haber 20 de ellos, todos funcionando por 0.005 seg. La calidad sí importa, no la cantidad. Perfile su código para determinar las partes más lentas, agregando más sentencias de microtiempo, encuentre la parte más lenta y optimícela.

Si tiene su propia función para consultar mysql, colocar cosas de microtiempo sería muy útil

No compararía tu script con Google, a menos que mantengas un ranking de página similar ... etc.
Si la búsqueda simplemente recupera valores de una base de datos, se puede mejorar la velocidad de algunos al crear un perfil de la aplicación y eliminar los cuellos de botella (por mencionar algunos - script en la página, imágenes grandes, tablas grandes, índices de bases de datos)