Redis Cache de página completa vs Cache FastCGI Ningx para WordPress

La memorización de caché es la columna vertebral de la velocidad y el rendimiento del sitio. Es esencial para el éxito de su sitio de WordPress. Incluso si su sitio está alojado en un servidor voluminoso, llegará a los rastreadores si no tiene caché. Servir sitios web para decenas de miles de usuarios al día solo es posible debido a técnicas inteligentes de almacenamiento de caché. En este artículo, pondré dos soluciones de almacenamiento distintas en el caché de las páginas de WordPress entre sí. Mientras que Nginx Fastcgi Cache es un veterano de almacenamiento de caché, el caché de página completa es relativamente oscura.
¿Quién saldrá en la frente y quién colapsará primero bajo carga? Como descubrirá pronto, ambos tienen sus ventajas y desventajas, pero solo hay un ganador. Cerca. ¡Aumentemos! La memoria en Cache WordPress 101 WordPress requiere muchas piezas móviles para funcionar. Cada vez que un usuario solicita una página desde un sitio de WordPress, el servidor analiza primero la solicitud. Si el servidor no puede servir fácilmente a la página solicitada, procesará los scripts PHP relevantes y ensamblará la página dinámicamente. A veces, esto también implica consultar la base de datos para recopilar datos adicionales.
Como regla general, cuanto más debe ir la demanda, más lenta es la respuesta del servidor. Si hay muchos competidores, el servidor se puede bloquear tratando de procesar todas las solicitudes paralelas. La memorización de caché ayuda a acelerar la respuesta del servidor almacenando y entregando solicitudes previamente procesadas. Un servidor puede implementar muchas capas de caché para almacenar distintos tipos de datos.

La capa de caché de la página está más cerca de los usuarios (Fuente: SPINUPWP) para aplicaciones PHP y bases de datos, como WordPress, hay cuatro tipos principales de almacenamiento de caché en el servidor: almacenamiento en caché de objetos, caché, código de operación de caché y CDN de caché. Puede leer más sobre todo esto en el artículo en profundidad del cohete WP sobre el almacenamiento de caché. Este artículo se centra en comparar las soluciones de almacenamiento de páginas, pero le sugiero que se familiarice con los elementos básicos del almacenamiento de caché a. Objetos. Configuración del sitio de prueba y el servidor. Usaré una caída estándar de $ 10 desde DigitalOcean para realizar las pruebas. Con una mezcla de memoria decente y recursos de cálculo, es un servidor perfecto para probar el sitio de WordPress. La configuración de gotas incluye 2 GB de RAM, 1 CPU, almacenamiento SSD de 50 GB y transferencia de 2 TB. Instalé el sitio web de WordPress en una pila Lemp basada en Debian (Linux, Nginx, Mariadb y PHP 7.3). Para enfatizar el sitio de prueba, lo personalicé para incluir una mezcla decente de elementos estáticos y dinámicos utilizando WooCommerce y Elementor.
El sitio web de WordPress utilizado para comparar la memoria de caché de las páginas que probé el sitio básico con la herramienta de prueba de velocidad del sitio GTMetrix. Como puede ver en su informe de prueba, aún no está optimizado para el rendimiento.

Informe GTMTRIX para el lugar de prueba Prueba El estrés del sitio básico sin caché activado utilizaré una herramienta de prueba de rendimiento gratuita.io para probar el sitio. Su nivel gratuito le permite probar dos URL de cualquier sitio web con hasta 10000 competidores durante un minuto. Es más que suficiente para nuestro caso de uso. Nota: si se pregunta sobre el nombre de dominio, es un dominio personal no utilizado. Es esencial tener el sitio alojado en un dominio real para instalar un certificado SSL de una autoridad de firma, como Let’s Cifrypt. Con un certificado SSL instalado, el sitio debe llevar a cabo una retención HTTPS para cada solicitud única del cliente. Esto imita mejor el uso en el mundo real durante la prueba de estrés.

Los resultados de la prueba Loader.io para el sitio básico, puede verificar los parámetros de prueba en el cuadro naranja a la izquierda. Observe el parámetro de prueba de 0 a 200 clientes durante 1 min. Esto significa que Loader.io probará el sitio web aumentando lentamente el número de clientes activos de 0 a 100 durante un período de 1 minuto.
En el gráfico presentado, la línea verde representa el número de competidores, y la línea azul representa el tiempo de respuesta promedio del servidor. Puede ver que el tiempo de respuesta aumenta a medida que aumenta el número de clientes. Loader.io canceló la prueba después de 36 segundos, porque más del 50% de las solicitudes no tuvieron éxito (un tiempo de espera o una respuesta de error HTTP 400/500). Además, el tiempo de respuesta promedio de 17.33 segundos tampoco es bueno para la experiencia del usuario. Verificar la pestaña Detalles le dará una mejor comprensión del momento en que se inician los tiempos de espera del servidor. Puede ver que comienza en la marca de 25 segundos. Hay muchos 500 errores internos del servidor. Realicé la prueba nuevamente, esta vez limitando el número de clientes en competencia a 100. El sitio base se ha esforzado por trabajar incluso bajo esta tarea mínima.

Repita la prueba con un máximo de 100 clientes activos que la prueba se ha ejecutado durante un minuto esta vez, pero el tiempo de respuesta promedio del servidor sigue siendo inaceptable. Cada usuario activo enfatiza más el servidor, lo que lo hace responder lentamente a todos los demás usuarios. Los tiempos de espera del servidor aún persisten.
El tiempo de espera del servidor persiste ya que el número de clientes activos aumenta de la tabla anterior notará que los tiempos de espera del servidor comienzan a aparecer en la marca de 38 segundos en la prueba.

Hay 68 clientes activos a los 38 segundos, ahora tiene una idea correcta de cómo funciona el sitio básico cuando hay 100 y 200 clientes activos. Es hora de realizar las mismas pruebas con Redis Page Cache o Ningx FastCGI Cache activado en el servidor. ¿Qué es la caché de página completa? Redis (servidor de diccionario desde la distancia) es un depósito de datos en la memoria extremadamente rápido para su uso como base de datos, caché, proxy y más. Debido a que Redis almacena sus datos en la memoria, a diferencia de las bases de datos tradicionales que almacenan datos en discos físicos o SSD, Redis puede buscar datos muy rápidamente. Debido a que el almacenamiento en la memoria es más costoso de escamificar en un servidor web. Es ideal para almacenar archivos más pequeños en caché, como los resultados de la base de datos y las sesiones persistentes. Por lo tanto, Redis generalmente se usa para activar el almacenamiento de objetos y no almacenar la página en caché.

Pantalla de configuración para el complemento Redis Object Cache (Fuente: WordPress.org) Prosepsu Smart People ha adaptado las características únicas del servidor Redis e implementado un almacenamiento de caché de las páginas Redis para WordPress. Use las directivas Redis MaxMemory #MB y MaxMemory-Polycy-LRU Redis para garantizar que el servidor use su memoria volátil limitada de manera efectiva, eliminando páginas de caché más antiguas para dejar espacio para otras nuevas.

El caché de la página Redis Redis en el repositorio WordPress.org Redis Page Cache almacena y sirve el caché de la página completa en el almacén de memoria, como funciona el caché de objeto Redis. Desde un punto de vista técnico, esto debería convertirlo en un caché muy rápido. Cómo activar la documentación de caché de la página Redis para activar el complemento de caché de la página Redis es un poco inconsistente. Después de algunos intentos y errores, hice que funcionara para mi configuración. Estos son los pasos que seguí: 1. Antes de instalar el complemento, asegúrese de tener el servidor Redis instalado y ejecutado en su servidor web. Si usa Debian/Ubuntu, aquí está el orden para instalarlo a través de la terminal: sudo apt-get install Redis-server Recomiendo cálidamente seguir el tutorial de océano digital en la instalación y la seguridad en su distribución de Linux. Si tiene alguna otra variante de Linux, también tienen tutoriales separados que se dirigen a casi todas las distribuciones principales de Linux. 2. Después de instalar y configurar Redis en su servidor web, debe instalar la extensión de Phredis en su servidor ofrece un PHP para comunicarse con la tienda Redis Key-Valuable. Sudo apt-get install php-redis reinicie el servidor PHP después de instalar la extensión de phpredis. Puede hacerlo con el siguiente pedido: Servicio sudo Php7.3-FPM Nota de reinicio:

Mi servidor web ejecuta la versión PHP 7.3. Debe utilizar un pedido apropiado para la versión PHP de su servidor web. 3. Debe asegurarse de que el servidor Redis tenga suficiente memoria asignada para almacenar la caché de la página. Redis Page Cache recomienda que asigne al menos 16 MB solo para la caché de la página. Puede hacer esto agregando la siguiente línea a su redis.conf: MaxMemory 256Mb He asignado 256 MB del servidor Redis. Debido a que el complemento comprime el caché con GZIP para reducir el uso de la memoria, debería ser más que suficiente para almacenar todas las páginas caché. Luego agregue la siguiente política de memoria para asegurarse de que Redis evacúe el caché anterior para dejar espacio para otros nuevos. MaxMemory-Polycy Allkeys-LRU reinicie el servidor Redis después de guardar los cambios en el archivo de configuración. Aquí está el comando para reiniciar: sudo systemCTL reiniciar redis.servicio 4. Ahora tiene que instalar y activar el caché de la página Redis. Puede instalarlo manualmente desde su almacén de GitHub de código abierto o directamente a través de wordpress.org. Nota:
Si instala el complemento directamente a través de WordPress.org, el slog del complemento (o el nombre de su director) es PJ-Page-Cache-Red. Pero si lo descarga directamente a través de su almacén de GitHub, el Slog es Redis-Page-Cache. Recuerde dónde instaló, porque necesita usar la babosa correcta en el siguiente paso. 5 Para hacer esto, primero debe cambiar el director del terminal en la carpeta WP-Content utilizando el comando CD. CD /VAR/www/your-domain.com/wp- Content Ahora puede crear una conexión simbólica en el director de Concontent WP utilizando el comando LN -S. Sudo Ln -S Plugins/PJ-Page-Red/Advanced-Cache.php Advanced-Cache.php 6. Finalmente, debe activar el caché en su sitio de WordPress editando su archivo wp. -Config.php. Agregue el siguiente fragmento de código en la parte superior de la línea que dice /* Eso es todo, ¡deja de editar! Feliz blogs. */ define (‘wp_cache’, true); Nota: La ubicación en la que agrega el fragmento de código anterior es muy importante. Termine para configurar la caché de la página Redis para su sitio de WordPress. Antes de probar la carga del sitio web, verifiquemos si la memoria de la página funciona de acuerdo con la intención. Puede probar esto visitando el sitio en modo de incógnito o utilizando el comando curl: curl -v https://example.com -v/null Si la memoria de la página funciona de acuerdo con la intención, entonces debería ver un encabezado de respuesta x- PJ-Cache-Status con el valor de acceso. <

X-PJ-Cache-Status: presione si el valor mostrado es “Miss” por primera vez, intente ejecutar el pedido nuevamente o actualizar la página. Debe hacer esto porque la memoria de caché se guarda solo después de que la página se ha cargado al menos una vez. “X-PJ-Cache-Status: HIT” indica que funciona el caché de la página Redis

Al ver la condición del caché directamente dentro del terminal de felicitaciones, ahora ha verificado que Redis Page Cache funciona en su sitio web. También puede configurar el complemento de caché de la página Redis para definir cómo debería funcionar. Para este ejemplo, me mantendré en la configuración predeterminada. Prueba de estrés con el caché de la página Redis activado para probar el sitio inactivo para ver cómo se resiste con el caché de la página Redis activado. Comenzaré Loader.io y realizaré la prueba de carga con el número máximo de competidores establecidos en 100.
Los resultados de la prueba de cargador.io para 0-100 clientes con caché de página redis activado. Repetí la prueba cinco veces para asegurar que los resultados sean consistentes. Con un tiempo de respuesta promedio de 478 ms y sin errores, podemos concluir que el sitio funciona espléndido con el caché activado. A medida que aumenta el número de competidores (la línea verde), el tiempo de respuesta permanece relativamente constante (la línea azul). Este es uno de los mejores indicadores que un servidor puede administrar muchos usuarios activos sin afectar la velocidad de carga de la página. Realicemos nuevamente la prueba, pero esta vez con un máximo de 200 clientes competidores.
Los resultados de la prueba Loader.io para clientes 0-200 con caché de página Redis activado el sitio todavía funciona bien, sin errores y un tiempo de respuesta promedio de 757 ms. En la tabla anterior, notará un aumento en el tiempo de respuesta a la marca de 22 segundos. Después de este punto, el tiempo de respuesta del servidor aumenta a medida que aumenta el número de clientes activos. Según un estudio de RackAid, debe mantener el tiempo de respuesta del servidor menos de 500 ms para mantener una buena experiencia de usuario. Al final de la prueba con 200 usuarios activos, el tiempo de respuesta del servidor aumentó a más de 1200 ms. Esto está lejos de ser ideal. Nota: La memorización de caché es solo una de las muchas formas de reducir el tiempo de respuesta del servidor. Para obtener más información sobre este tema, consulte el artículo de WP Rocket sobre la reducción de TTFB. El tiempo de respuesta del servidor es rápido y se arreglan hasta 78 clientes activos que atienden a 78 competidores sin pérdida de rendimiento es excelente. Suponiendo que cada usuario pase en promedio 2 minutos en cualquier página, se traduce en servir más de 1.5 millones de solicitudes de página cada mes, sin problemas de servidor. Vayamos más allá de los límites del servidor. Lo probaré nuevamente con el número máximo de clientes activos establecidos en 250.
Los resultados de la prueba Loader.io para 0-250 clientes con caché de página Redis activados los resultados aparecen de acuerdo con la prueba anterior, pero esta vez el 5.1% de las respuestas del servidor fueron errores HTTP 400/500. Con respecto a la pestaña Detalles, nos proporcionará más información sobre cuándo aparecieron las respuestas de error por primera vez.


La pestaña Detalles para la prueba 0-250 de Redis Page Cache activó los errores HTTP 500X apareció por primera vez en el punto de 51 segundos. El número total de clientes activos fue 218 en este momento de la prueba. De las pruebas anteriores podemos concluir que Redis Page Cache mejora el rendimiento del sitio. Ahora pasemos para probar el sitio con el caché Ningi Fastcgi activado. ¿Qué es Ningx Fastcgi Cache? Nginx es un servidor web popular de alto rendimiento que puede alojar sitios de WordPress. Además de ser un servidor web, también se usa como proxy inverso, proxy de correo electrónico, saldo de carga y caché HTTP. Según W3Techs, el 32.1% de los sitios web se instalan en un servidor web NGINX (25 de mayo de 2020). La mayoría de los hosts de WordPress se centraron en el rendimiento Use Nginx para alimentar sus sitios web hoy.

Acelere los sitios con Ningin FastCGI Cache (Fuente: NGINX) La memorización en caché en Nginx se alimenta principalmente por el módulo de caché FastCGI. Según una prueba de evaluación comparativa de SPINUPWP, Ningin Fastcgi Cache fue la solución de almacenamiento de caché más rápida y eficiente. Cómo activar Ningin Fastcgi Cache Puede activar Ningin Fastcgi Cache solo en un servidor web que tiene instalado NingX. Como ya he instalado NGINX como servidor web, lo restableceré a la configuración básica para eliminar cualquier rastro de Redis. Puede averiguar cómo usar Ningin Fastcgi Cache en su sitio web de WordPress visitando el elemento de cohete WP en su caché Nginx. También puede consultar nuestro artículo sobre el almacenamiento de contenido dinámico en caché en WordPress para un tutorial exhaustivo sobre cómo activar la caché NINGX FastCGI. Antes de probar el sitio, verifique si FastCGI Cache funciona en el sitio verificando la sede de respuesta. IO. Prueba de estrés con Ningin Fastcgi Cache activado primero, probaré el sitio estableciendo el número máximo de clientes activos en 100.

Los resultados de Loader.io prueba para 0-100 clientes con caché Nginx activados como se esperaba, el sitio funciona excepcionalmente después de activar el caché de la página. El tiempo de respuesta promedio del servidor permanece por debajo de 400 ms, incluso si el número de clientes activos alcanza los 100 (el número máximo establecido por mí). Ahora aumentemos el número máximo de clientes activos a 200 y repitamos la prueba de estrés.

Los resultados de la prueba de cargador.io para 0-200 clientes con caché Nginx activado incluso después de aumentar el número máximo de clientes activos, el tiempo de respuesta promedio del servidor permanece por debajo de 400 ms. Ya tenemos un claro ganador. Pero, ¿qué tan lejos podemos empujar el servidor? Loader.io le permite establecer el número máximo de clientes activos en 10000. Por lo tanto, probé con esta configuración máxima para ver si el servidor se mantendrá al día. Los resultados de la prueba de cargador.io para clientes 0-10000 con caché Nginx se activaron sorprendentemente, el servidor mantuvo el paso. Sin embargo, los resultados de la prueba mostraron una tasa de error del 19.7% (tiempos de espera en este caso) y un tiempo de respuesta promedio del servidor de 4464 ms. Continué reduciendo el número máximo de clientes a la mitad para descubrir el límite de estrés del caché FastCGI del sitio activado. Finalmente, alcanzamos dos números.

Los resultados de la prueba carger.io para los clientes 0-800 con la caché Ningin Fastcgi activada con el número máximo de clientes activos establecidos en 800, el tiempo de respuesta promedio del servidor es de 596 ms. Sin embargo, los tiempos de espera del servidor comienzan hacia el final de la prueba después de llegar a 760 clientes activos. El límite de estrés para el caché Ningin Fastcgi es 3.5 veces mayor que el observado con Redis Page Cache.

Los tiempos de espera del servidor comienzan en 56 segundos. Realizaré otra prueba de estrés para encontrar el número de clientes activos que el servidor puede administrar sin comprometer el tiempo de respuesta promedio (<500 ms). Para esta prueba, establezca el número máximo de competidores en 500.

Los resultados de la prueba Loader.io para clientes 0-500 con Ningin Fastcgi Cache activaron el tiempo de respuesta del servidor alcanza más de 500 ms a 44 segundos y continúa avanzando. El número de clientes activos en este momento es 375. Por lo tanto, podemos deducir que el servidor puede administrar 375 competidores sin afectar el tiempo de respuesta. Es 4.8 veces mayor que el número de clientes activos aceptados por Redis Page Cache. Suponiendo que cada usuario pase en promedio 2 minutos en cualquier página, se traduce en servir 8.1 millones de páginas cada mes, sin problemas de servidor. No está mal para un sitio alojado en un servidor de $ 10/mes. Hacer las pruebas de estrés Redis Page La caché es una implementación de almacenamiento de caché inteligente para sitios de WordPress. En comparación con el hecho de que la memoria de la página no está activada, ayuda a mejorar el rendimiento del sitio. Sin embargo, Ningin Fastcgi Cache ha superado el caché de la página Redis en todas las pruebas de estrés. A continuación se muestra un diagrama comparativo de ambas pruebas de estrés. Los resultados son concluyentes y hablan por sí mismos.