15 votos

El extraño caso del Señor del Tiempo Hasta el Primer Byte

Tengo un servidor web en un Linode 1024 VPS basados en

  • Ubuntu 11.10
  • Nginx 1.0.5
  • PHP 5.3.6 (con PHP-FPM, APC)
  • Barniz 3.0.2

Y un par de blogs no basado en WordPress 3.3.1. Uno de ellos es un simple blog, con la configuración por defecto, el tema y sólo el "Hola Mundo" post, para probar el servidor. El otro es un blog clonado a partir de otro servidor con casi 10k puestos y más de 10k comentarios. Este blog tiene por 5k visitas únicas por día.

El servidor da buenos números en un ab de prueba para el blog de prueba, Pero la misma prueba con el clonado blog es imposible de hacer: ab cargas de prueba el servidor demasiado, y tengo que detener el proceso, que de todos modos hace ab para mostrar esta realmente mal resultado.

El htop muestra también un "normal" de la carga cuando está en operación normal, pero normal grande de la carga durante el ab de la prueba.

Hay otra cosa extraña sucediendo (la más importante para mí): el Tiempo Hasta el Primer Byte es muy alta, pero después de que esperar el sitio web se carga muy rápido. Esto puede ser fácilmente probado con servicios tales como tools.pingdom.com, que le da este resultado. Por favor, preste atención a que la región amarilla que significa "tiempo de Espera".

¿Por qué está sucediendo esto? Posibles ideas:

  • Mala PHP-FPM config
  • Linode DNS, tiempo de respuesta es horrible. Absurdo-el blog de prueba resuelve DNS bien, TTFB es fantástico
  • Mal de configuración de Nginx

En caso de que alguien necesita más info,

25voto

cyberx86 Puntos 14100

En primer lugar, esta no es una respuesta, por lo tanto como una aproximación diagnóstica.

Esto no significa de ninguna manera integral o incluso nada parecido, es sólo un punto de partida.

El tiempo hasta el Primer Byte

El tiempo hasta el primer byte (TTFB) tiene un número de componentes:

  • La Búsqueda del DNS: busque la dirección IP del dominio (posible mejora: más numerosos/distribuidos/sensible de los servidores de DNS)
  • Tiempo de conexión: Abrir un socket con el servidor, a negociar la conexión (valor típico debe ser de alrededor de 'ping' tiempo - un viaje de ida y generalmente es necesario - keepalive debe de ayuda para las solicitudes posteriores)
  • En espera: el procesamiento inicial requerido antes de que el primer byte puede ser enviada (su es donde su mejora debe ser - va a ser más significativa para el contenido dinámico.

Cuando usted mira un ApacheBench de salida, también se puede ver:

  • Procesamiento: es la suma de espera + transferencia completa de contenido (si el tiempo de traslado es significativamente mayor que lo que sería de esperar para descargar la cantidad de datos recibidos, el procesamiento posterior (después de que el primer byte recibido) se está produciendo (por ejemplo, la página está vaciando de contenido a medida que está disponible)

Comparaciones de Eliminar los componentes

Con pocas excepciones, el problema va a mentir en el procesamiento de servidor, que generalmente se reduce excesivamente complejas/ineficiente código, o mal configurado MySQL.

Una buena manera de acercarse a este problema es a través de una serie de comparaciones que se va a eliminar varios de los aspectos de su configuración. Una buena comparación debe mantener a tanto constante como sea posible para ayudar a reducir el problema. En la actualidad, se han proporcionado las siguientes comparaciones:

  1. Idénticos (clonado) sitio se ejecuta en el servidor antiguo y el nuevo servidor:
    • Diferencia: Servidor
    • Resultado: el viejo servidor es rápido; nuevo servidor es lento
    • Notas: Lo que usted necesita aquí es cuantificar las diferencias entre estos servidores - tanto en términos de la pila utilizada (Nginx, etc) y el hardware (es el antiguo servidor más rápido porque es una máquina más potente?)
    • Conclusión: el código puede ser capaz de correr rápido en el derecho de instalación
  2. Sitio de prueba vs completo sitio en el nuevo servidor
    • Diferencia: el contenido, los temas, plugins, etc
    • Resultado: sitio de la prueba es rápida y completa del sitio es lento
    • Notas: en teoría, esta prueba debería ayudar a eliminar una gran cantidad de aspectos de su configuración de DNS, la red, incluso a su nginx/php/mysql instalación - sin embargo, no es "justo".
    • Conclusión: el contenido adicional está teniendo un impacto significativo en el rendimiento

La prueba ideal tendría que duplicar su sitio completo, pero, a continuación, elimine todo el contenido excepto para un artículo y los comentarios asociados. El punto de esta prueba sería determinar de forma concluyente si la gran cantidad de contenido es el problema o si otros aspectos de su configuración (plugins de wordpress, tema, etc) son la causa. Esencialmente estás comparar el rendimiento de los sitios idénticos, en el mismo (nuevo) servidor de carga de la misma página (de la misma longitud, etc) - con la única diferencia de que el total del contenido del sitio (por ejemplo, hay una buena probabilidad de que algún plugin no escala bien con el aumento de contenido).

Sin cambiar nada, hay algunas otras comparaciones que se pueden hacer:

  • Prueba desde una ubicación remota vs local - esto ayudará a identificar si la red, latencia, dns, etc es la causa
    • Ya has (un poco) de hecho esto y sobre todo la conclusión de que usted no tiene un problema de red.
  • Prueba a través de Barniz (es decir, el puerto 80) vs nginx directamente (el puerto 8080) - trate de no cambiar su configuración de entre las pruebas - sólo utiliza el puerto correcto. Esto le mostrará el impacto de Barniz. Desde el Barniz es una capa de caché, debe servir a todas las solicitudes después de la primera muy rápidamente - en esencia, se debe omitir el backend y el procesamiento que se necesita para generar una página dinámica, y servir a la copia en caché de forma muy rápida.
    • Usted ha hecho esto (aunque, no local) y se demostró que el Barniz tiene un impacto positivo significativo en su rendimiento.

El ajuste de su Backend

En este punto usted debería haber encontrado el problema o la conclusión de que se encuentra en su backend. Que te deja con Nginx, PHP o MySQL.

(Debo mencionar aquí, que siempre es útil saber si el cuello de botella es la CPU, la RAM, o I/O - entre sar, top, iostat, vmstat, free, etc usted debe ser capaz de llegar a algún tipo de conclusión al respecto).

Nginx

Nginx es sólo tomar pedidos y servir contenido estático o el cambio de las solicitudes de PHP-FPM - generalmente no hay mucho para optimizar con Nginx.

  • Conjunto de trabajadores = # núcleos de CPU
  • Habilitar keepalive (un valor de 10-15 es bueno)
  • Deshabilitar innecesarios del registro de
  • Aumentar el tamaño del buffer si es necesario
  • Evitar en caso de declaraciones (uso estático nombres, en lugar de expresiones regulares donde sea posible, eliminar los innecesarios extensiones)

Idealmente, su blog de prueba y clonado blog tienen las mismas configuraciones, en cuyo caso, se han eliminado efectivamente Nginx como el problema.

Aplicación

En el caso de que usted está tratando de identificar un problema en el código (por ejemplo, una lenta plugin, etc) la lentitud de los registros son el lugar para comenzar.

  • Habilitar MySQL lento y el registro de PHP-FPM lento registro de ejecutar su punto de referencia y ver lo que viene lento.

MySQL

  • Aumentar su caché y ejecutar mysqltuner.pl para obtener un buen punto de partida.

PHP

  • deshabilitar extensiones innecesarias,
  • deshabilitar register_globals, magic_quotes_*, expose_php, register_argc_argv, always_populate_raw_post_data
  • aumentar el memory_limit
  • open_basedir y safe_mode tener importantes consecuencias en el rendimiento, pero también puede proporcionar una capa adicional de defensa. Prueba con y sin ellos, para determinar si su impacto en el rendimiento es tolerable.

PHP-FPM

  • Ajustar el pm.* valores - aumento de lidiar con alta carga

Vale la pena señalar que su htop resultados muestran php-fpm como consumir la mayor parte de la CPU y el problema no parece estar directamente relacionado con este.

El almacenamiento en caché

Una vez que se han optimizado de cada una de las probabilidades de cuello de botella, iniciar el almacenamiento en caché.

  • Usted tiene un código de operación (opCode cache (APC) ya - asegurarse de que se está trabajando (que viene con un archivo de prueba) - comprobar las tasas de aciertos de caché, y si es posible caché de APC a la memoria en lugar de en el disco.
  • La configuración de su código de caché (por ejemplo, el uso de un plugin para Wordpress como W3TC)
  • Con nginx puede configurar FastCGI caché - pero ya que usted tiene Barniz, esta es la mejor manera de evitarlo.
  • La instalación de una capa de caché, como el Barniz (que ya lo ha hecho) - y asegúrese de que está trabajando (e.g el uso varnishstat, leer el Logro de un alto Hitrate)
  • Agregar más almacenamiento en caché para los componentes de su sitio - por ejemplo, MemCached, si es aplicable

A veces, debido a las limitaciones de su aplicación y el hardware, usted no puede ser capaz de mejorar el backend de rendimiento mucho, sin embargo, que es el punto de almacenamiento en caché para reducir el uso del backend.

Leer más

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: