En primer lugar, esta no es una respuesta, sino un enfoque de diagnóstico.
Esto de ninguna manera es exhaustivo, o incluso algo cercano, es solo un punto de partida.
Tiempo hasta el primer byte
El tiempo hasta el primer byte (TTFB) tiene varios componentes:
- Búsqueda de DNS: encuentre la dirección IP del dominio (posible mejora: servidores DNS más numerosos / distribuidos / sensibles)
- Tiempo de conexión: abra un socket en el servidor, negocie la conexión (el valor típico debe estar alrededor del tiempo de 'ping' - generalmente es necesario un viaje de ida y vuelta - keepalive debería ayudar para solicitudes posteriores)
- En espera: se requiere el procesamiento inicial antes de que se pueda enviar el primer byte (aquí es donde debería estar su mejora; será más significativo para el contenido dinámico).
Cuando mira una salida de ApacheBench, también ve:
- Procesamiento: es la suma de espera + transferencia completa de contenido (si el tiempo de transferencia es significativamente más largo de lo que se esperaría para descargar la cantidad de datos recibidos, se está procesando más (después del primer byte recibido) (por ejemplo, la página está vaciar el contenido ya que está disponible)
Comparaciones para eliminar componentes
Con pocas excepciones, su problema radicará en el procesamiento de back-end, que generalmente se reduce a código demasiado complejo / ineficiente, o MySQL mal configurado.
Una buena manera de abordar este problema es a través de una serie de comparaciones que eliminarán varios aspectos de su configuración. Una buena comparación debe ser lo más constante posible para ayudar a reducir el problema. Actualmente, ha proporcionado las siguientes comparaciones:
- Sitio idéntico (clonado) que se ejecuta en el servidor antiguo y en el nuevo servidor:
- Diferencia: servidor
- Resultado: el antiguo servidor es rápido; nuevo servidor es lento
- Notas: Lo que necesita aquí es cuantificar las diferencias entre estos servidores, tanto en términos de la pila utilizada (Nginx, etc.) como del hardware (¿el servidor antiguo es más rápido porque es una máquina más potente?)
- Conclusión: el código puede ejecutarse rápidamente en la configuración correcta
- Sitio de prueba versus sitio completo en el nuevo servidor
- Diferencia: contenido, temas, complementos, etc.
- Resultado: el sitio de prueba es rápido, el sitio completo es lento
- Notas: en teoría, esta prueba debería ayudarlo a eliminar muchos aspectos de su configuración (DNS, red, incluso su configuración nginx / php / mysql), sin embargo, no es del todo 'justo'.
- Conclusión: el contenido adicional está teniendo un impacto significativo en el rendimiento
La prueba ideal sería duplicar su sitio completo, pero luego eliminar todo el contenido, excepto un artículo y los comentarios asociados. El objetivo de esta prueba sería determinar de manera 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. Básicamente, compararía el rendimiento de sitios idénticos, en el mismo (nuevo) servidor, cargando la misma página (misma longitud, etc.), con la única diferencia de ser el contenido total del sitio (por ejemplo, existe una buena posibilidad de que algún complemento no funcione). escalar bien con mayor contenido).
Sin cambiar nada, hay algunas otras comparaciones que puede hacer:
- Pruebe desde una ubicación remota frente a una local: esto ayudará a identificar si la causa es la red, la latencia, el DNS, etc.
- Ya ha hecho (algo) esto y ha concluido principalmente que no tiene un problema de red.
- Pruebe a través de Varnish (es decir, el puerto 80) frente a nginx directamente (puerto 8080); intente no cambiar su configuración entre pruebas, solo use el puerto correcto. Esto le mostrará el impacto del barniz. Dado que Varnish es una capa de almacenamiento en caché, debe atender todas las solicitudes después de la primera muy rápidamente, esencialmente, debe omitir el backend y el procesamiento que se necesita para generar una página dinámica, y servir la copia en caché muy rápidamente.
- Lo ha hecho (aunque no localmente) y ha demostrado que Varnish tiene un impacto positivo significativo en su rendimiento.
Afinando tu Backend
En este punto, ya debería haber encontrado el problema o concluido que se encuentra en su backend. Eso te deja Nginx, PHP o MySQL.
(Debo mencionar aquí, que es siempre útil para saber si su cuello de botella es la CPU, RAM, o E / S - entre sar, top, iostat, vmstat, free., Etc usted debe ser capaz de llegar a una conclusión sobre este tema)
Nginx
Nginx solo acepta solicitudes y sirve contenido estático o cambia las solicitudes a PHP-FPM; por lo general, no hay mucho que optimizar con Nginx.
- Establecer trabajadores = # núcleos de CPU
- Habilitar keepalive (un valor de 10-15 es bueno)
- Deshabilitar el registro innecesario
- Aumente el tamaño del búfer si es necesario
- Evite las declaraciones if (use nombres estáticos en lugar de expresiones regulares cuando sea posible, elimine las extensiones innecesarias)
Idealmente, su blog de prueba y su blog clonado tienen configuraciones idénticas, en cuyo caso, efectivamente ha eliminado Nginx como el problema.
Solicitud
En el caso en que intente identificar un problema en su código (por ejemplo, un complemento lento, etc.), los registros lentos son el lugar para comenzar.
- Habilite el registro lento de MySQL y el registro lento de PHP-FPM ejecute su punto de referencia y vea lo que viene como lento.
MySQL
- Aumente sus cachés y ejecute 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 límite de memoria
- open_basedir y safe_mode tienen importantes implicaciones de rendimiento, pero también pueden proporcionar una capa adicional de defensa. Pruebe con y sin ellos para determinar si su impacto en el rendimiento es tolerable.
PHP-FPM
- Ajuste los valores pm. *: Aumente para hacer frente a una carga alta
Vale la pena señalar que los resultados de htop muestran que php-fpm consume la mayor parte de la CPU, y su problema parece estar directamente relacionado con esto.
Almacenamiento en caché
Una vez que haya optimizado cada posible cuello de botella, comience a almacenar en caché.
- Ya tiene un caché opCode (APC), asegúrese de que funciona (viene con un archivo de prueba), verifique las tasas de aciertos de su caché y, si es posible, tenga el caché APC en la memoria en lugar de en el disco.
- Configure su código en caché (por ejemplo, usando un complemento para Wordpress como W3TC)
- Con nginx puede configurar el almacenamiento en caché FastCGI, pero como tiene Varnish, es mejor evitarlo.
- Configure una capa de almacenamiento en caché, como Barniz (que ya ha hecho) y asegúrese de que funciona (por ejemplo, use varnishstat, lea Lograr un alto índice de aciertos )
- Agregue más almacenamiento en caché para los componentes de su sitio, por ejemplo, MemCached si corresponde
A veces, dadas las limitaciones de su aplicación y hardware, es posible que no pueda mejorar tanto el rendimiento del backend, sin embargo, ese es el punto del almacenamiento en caché, para minimizar el uso del backend.
Otras lecturas
if -fdirectiva que está utilizando en ellocationcontenedor en la configuración de nginx. Basado en lo que estoy leyendo aquí wiki.nginx.org/Pitfalls , tengo la sensación de que-festá haciendo una búsqueda ineficiente del archivo que podría causar un problema de Tiempo al primer byte, especialmente si tiene directorios con una gran cantidad de archivos.