Cómo maximizar el rendimiento de PHP 7 con NGINX, parte 1: servicio web y almacenamiento en caché

NGINX | 26 de febrero de 2016

Floyd SmithDirector de marketing de contenidos

Introducción: cómo se utiliza NGINX con PHP

PHP es la opción más popular para crear una aplicación web del lado del servidor, con aproximadamente un 80 % de cuota de mercado. (ASP.net ocupa un lejano segundo puesto, y Java un tercer puesto aún más distante.)

El universo de PHP incluye multitud de frameworks de PHP; entre los más populares se encuentran Laravel, Phalcon y Symfony 2. PHP también sirve de base para populares sistemas de gestión de contenidos (CMS), como WordPress y Drupal. (La versión más reciente de Drupal, Drupal 8, incluye una importante integración con Symfony 2.

Ahora, el equipo de PHP lanza una nueva versión, PHP 7 —más de una década después de la introducción de PHP 5—. Durante este tiempo, tanto el uso de la web como las exigencias de los sitios web han aumentado exponencialmente. PHP ha contribuido a ese rápido crecimiento, pero ese mismo crecimiento que ha hecho posible también ha puesto de manifiesto sus limitaciones.

PHP suele considerarse potente y flexible, pero propenso a problemas de rendimiento. Los sitios basados en PHP pueden «tocar techo» fácilmente tras apenas unas pocas duplicaciones del tráfico. Justo cuando un sitio empieza a alcanzar sus objetivos empresariales u operativos, comienza a fallar cada vez que aumenta el volumen de tráfico.

Para miles y miles de aplicaciones basadas en PHP, algunos cambios relativamente sencillos han bastado para mejorar el rendimiento. Entre ellos se incluyen el almacenamiento en caché con herramientas como memcached, la optimización de bases de datos, y el uso de un proxy inverso y el balanceo de carga con NGINX Open Source y NGINX Plus. NGINX ha mejorado considerablemente la capacidad de respuesta de las aplicaciones, permitiendo multiplicar por diez el número de usuarios y el volumen de tráfico.

Esta entrada de blog es la primera de una serie de dos partes sobre cómo maximizar el rendimiento de sus sitios web que utilizan PHP 7. Aquí nos centramos en actualizar a PHP 7, implementar NGINX Open Source o NGINX Plus como software de servidor web, reescribir las URL (algo necesario para que las solicitudes se procesen correctamente), almacenar en caché los archivos estáticos y almacenar en caché los archivos dinámicos (también denominado almacenamiento en caché de aplicaciones o microcaché).

En la próxima entrada del blog, nos centraremos en las medidas que puede adoptar con servidores adicionales: añadir un servidor proxy inverso, migrar a varios servidores de aplicaciones, equilibrar la carga entre varios servidores, mantener la persistencia de las sesiones durante el equilibrio de carga y finalizar protocolos de seguridad como SSL/TLS y el protocolo HTTP/2 relacionado.

Por qué PHP llega a su límite

¿Por qué las aplicaciones PHP llegan a un límite? Por la misma razón que cualquier software de servidor de aplicaciones. Cuando llega una solicitud de un usuario, PHP —y el software de servidor web sobre el que se ejecuta— tienen que realizar varias tareas:

Interpretar la solicitud. Primero, el software del servidor web y, después, PHP deben iniciar procesos para recibir, interpretar y atender la solicitud. Apache HTTP Server, por ejemplo, asigna recursos para gestionar cada solicitud de datos, ya sea sencilla (recuperar un archivo JPEG) o compleja (procesar solicitudes CSS anidadas). Todo esto requiere tiempo, recursos del sistema y una asignación de memoria que puede ser considerable si el sistema operativo, PHP o ambos tienen que cargar varias bibliotecas antes siquiera de empezar a procesar la solicitud.
Gestionar los protocolos auxiliares. Si utiliza SSL/TLS o HTTP/2, o ambos, el software de su servidor web tiene que descodificar las solicitudes, un proceso que puede llevar bastante tiempo.
Procesar la solicitud. PHP tiene que reunir los recursos necesarios para gestionar la solicitud. Esto puede requerir varias llamadas a la base de datos, llamadas a servicios externos a través de Internet y un procesamiento interno complejo.
Responder a la solicitud. PHP debe devolver los resultados al software del servidor web para que los transmita al solicitante como una respuesta HTTP. Recuerde que tanto el software del servidor web como PHP ejecutan un hilo activo y dedicado para cada solicitud, desde la recepción inicial hasta la confirmación final.

Es una carga considerable para un servidor físico, una máquina virtual o una instancia de servidor en la nube en cada solicitud. El rendimiento suele degradarse cuando se agota la memoria física de la máquina del servidor, ya sea física o virtual. En ese momento, el servidor empieza a paginar al disco las sesiones actuales a medida que llegan nuevas solicitudes. La espera necesaria para atender las solicitudes de archivos también genera estados de espera que, a su vez, contribuyen a la paginación. Superado cierto punto (muy limitado), las operaciones de paginación y las solicitudes de datos saturan las operaciones de procesamiento, y el rendimiento entra en una espiral descendente que provoca largas esperas o incluso la finalización abrupta de las sesiones de unos usuarios frustrados.

Cómo abordar los problemas de rendimiento

Superar las barreras de rendimiento de PHP es perfectamente posible, y para ello se requieren varios pasos complementarios que pueden combinarse entre sí. A grandes rasgos, son los siguientes:

Resolver el problema a base de hardware. Más memoria, más memoria, discos más rápidos, servidores de bases de datos independientes, una red de distribución de contenidos, una mayor capacidad de transferencia y otras soluciones mecánicas constituyen una solución rápida, aunque poco refinada, a los problemas de rendimiento. Estas soluciones pueden ayudar a mantener la disponibilidad o a escalar el rendimiento de forma lineal.
Mejorar PHP y el código de la aplicación. Las nuevas versiones de PHP, los nuevos frameworks y las mejoras en el código de la aplicación pueden ser de gran ayuda. También es posible duplicar o incluso cuadruplicar el rendimiento sin incurrir en gastos adicionales de hardware nuevo.
Software de servidor mejorado. La mayoría de los servidores web y PHP asignan recursos específicos a cada solicitud abierta en curso. El software de servidor NGINX gestiona las solicitudes a medida que llegan, sin inmovilizar recursos, lo que minimiza el consumo de recursos del servidor.
Implementación multiservidor. Puede implementar un servidor proxy inverso para gestionar las solicitudes de Internet y distribuirlas (equilibrar la carga) entre uno o varios servidores de aplicaciones. El servidor proxy inverso también puede encargarse del almacenamiento en caché de archivos, la terminación de protocolos como SSL/TLS y HTTP/2, y la gestión de varios servidores de aplicaciones. Incluso con un solo servidor de aplicaciones, esto le libera de una gran parte de su carga de trabajo. El equilibrio de carga garantiza que ningún servidor se sature con más carga de la que le corresponde a medida que se añaden más servidores.

No es necesario implementar estos pasos en un orden concreto; por ejemplo, aunque mantenga Apache como servidor web y no actualice el servidor de aplicaciones a PHP 7, el mero hecho de implementar NGINX como proxy inverso «delante de» sus servidores actuales mejora el rendimiento y le permite implementar varios servidores de aplicaciones en paralelo.

Independientemente de cómo lo haga, lo fundamental es tener presente que puede multiplicar el rendimiento e incluso aumentar la capacidad en un orden de magnitud, sin apenas modificar el código actual de su aplicación. Siga leyendo para descubrir cómo otras personas ya han logrado, o están en proceso de lograr, estas extraordinarias mejoras de rendimiento.

Nota: Hay una optimización para entornos con varios servidores que no abordaremos en profundidad en estas entradas del blog. Un servidor de bases de datos independiente y una red de distribución de contenidos (CDN) pueden reducir la carga del servidor de aplicaciones y mejorar considerablemente el rendimiento; este tipo de cambios son independientes de las mejoras de la aplicación y de la implementación descritas aquí, y pueden realizarse en paralelo.

Consejo 1 – Actualiza a PHP 7

La principal razón para actualizar a PHP 7 cuanto antes es sencilla: la velocidad de las aplicaciones (favorecida en gran medida por el ahorro de memoria). Se dice que PHP 7 es el doble de rápido que las versiones anteriores de PHP y que utiliza bastante menos memoria. (Sin duda, los resultados variarán en ambos aspectos.)

El tiempo de respuesta es, sencillamente, crucial para las aplicaciones web. Una aplicación web más rápida —que además utiliza menos memoria, lo que reduce la probabilidad de que se produzca paginación y los consiguientes problemas de rendimiento— consigue tres cosas:

Hace que los usuarios estén más satisfechos y sean más propensos a visitar tu sitio y realizar tareas en él, como leer artículos, consultar información sobre productos, pedir un vehículo de transporte, alquilar una habitación libre o comprar cosas. Es decir, los motivos por los que creaste el sitio o la aplicación en primer lugar.
Permite que un servidor determinado admita más usuarios sin correr el riesgo de que se ralentice o incluso se colapse debido al aumento de usuarios. Posponer el desastre siempre es algo positivo.
Hace que tu servidor sea menos vulnerable a los ataques de hackers que lo sobrecargan para dejarlo fuera de servicio. Hoy en día todo el mundo sufre ataques, pero los sistemas más débiles los sufren con mayor frecuencia y agresividad. Por tanto, reducir la vulnerabilidad puede ser exponencialmente mejor que aumentarla.

Todas estas son excelentes razones para actualizar; en conjunto, los argumentos a favor de la actualización parecen casi abrumadores. Además, «actualizar a la última versión» es siempre la primera recomendación para solucionar muchos problemas, incluso cuando la mejora del rendimiento no es tan evidente. Entonces, ¿por qué no actualiza todo el mundo de inmediato?

Las actualizaciones según xkcd

Es sencillo: a la gente no le gusta tocar código antiguo, y con razón. Si una aplicación antigua funciona lo suficientemente bien y los desarrolladores obtienen mejores resultados creando aplicaciones nuevas que actualizando las antiguas, la aplicación antigua puede seguir utilizándose, sin cambios, durante mucho tiempo. (Consulta la segunda entrada de esta serie para obtener información sobre cómo utilizar NGINX para mejorar el rendimiento de tu aplicación sin realizar ningún cambio en tu servidor web ni en tu aplicación actuales).

Pero, si es posible, lo más eficiente es comenzar la búsqueda de un mayor rendimiento actualizando a PHP 7. Eso sí, no empiece hasta que disponga de tiempo suficiente para terminar, sobre todo sin escatimar en las pruebas.

Veamos qué se necesita para actualizar a PHP 7:

Cambios en la evaluación de expresiones. Es posible que tengas que cambiar la forma de escribir algunas expresiones para que se evalúen correctamente en PHP 7. (O, si estás siendo especialmente prudente y no vas a actualizar todos tus servidores PHP a la vez, para que se evalúen correctamente tanto en PHP 5.6 como en PHP 7). Si utilizas variables variables o propiedades variables, tendrás que revisar el código para que se evalúen de la misma manera en ambas versiones de PHP.
Cambios de sintaxis. PHP 7 no admite etiquetas ASP ni script. No se pueden incluir varios casos predeterminados en una sentencia switch. (Dejamos de lado la controversia sobre switch frente a if-then-else.)
Eliminación de funcionalidades obsoletas. Todo tipo de elementos que quedaron obsoletos en distintas versiones 5.x de PHP están ahora más muertos que un loro muerto. Sencillamente, no funcionan en PHP 7. Si están presentes en tu código, intentas eliminarlos todos y no lo consigues, puedes tener la certeza de que las funciones del código de tu carrito de compra desaparecerán a las 23:59 de la noche anterior al Cyber Monday.
Nuevas funcionalidades. PHP 7 incorpora varias funcionalidades nuevas que pueden resultar tentadoras para quienes actualicen código antiguo, pero hay que tener cuidado al añadirlas durante una limpieza de código. Las nuevas funcionalidades suelen ser estupendas —de lo contrario, no se habrían incorporado—, pero también atraen errores (tanto propios como ajenos) y futuras revisiones a medida que PHP siga actualizándose.
Revisión general del código. Cada vez que toques el código —es más, cada vez que abras un archivo de código y no tengas claro si lo has modificado o no—, debes revisar a fondo todo su contenido, especialmente aquello que hayas cambiado.
Pruebas. Todo debe probarse en todo momento. Si haces algún cambio, debes volver a probarlo todo, y aun así eso no significa que vayas a detectar todos los errores. Un entorno DevOps bien implementado puede facilitar relativamente estas pruebas, pero, a día de hoy, solo unos pocos vivimos en esa tierra prometida.

Este blog de Engine Yard ofrece buenos ejemplos de la mayoría de estos problemas.

Si decides seguir adelante y actualizar a PHP 7, plantéate realizar un análisis exhaustivo del rendimiento y revisar tu código, o al menos sus funciones críticas, aprovechando las nuevas características de PHP 7. No hay mejor manera de que tanto tú como tu equipo mejoréis vuestras competencias, y es probable que los cambios que hagáis, reviséis y probéis hoy os resulten útiles durante muchos años. También sacarás el máximo partido a las demás recomendaciones de rendimiento de esta entrada del blog, ya que el código optimizado se beneficia enormemente de ejecutarse en un entorno optimizado.

Así pues, aunque los sitios web suelen implementar NGINX para mejorar el rendimiento sin modificar el código de la aplicación, le recomendamos que tome las riendas y siga adelante. Hay mucha ayuda disponible para realizar la migración, o puede simplemente ponerse manos a la obra y hacerlo usted mismo. En el sitio web oficial de PHP encontrará una guía de migración a PHP 7, y O’Reilly ofrece un manual práctico para actualizar a PHP 7.

Consejo 2 – Elige NGINX Open Source o NGINX Plus

NGINX es el software en el que se ejecutan más de 140 millones de sitios web, entre ellos la mitad de los 10.000 sitios web con más tráfico. (Estas mediciones detectan el servidor web en los sitios con un único servidor y el servidor proxy inverso en los sitios con varios servidores). Como servidores web, ambos ofrecen una mejora inmediata del rendimiento —en algunos casos, cuando un servidor que ejecuta otro software está sobrecargado y sufre una paginación excesiva, de hasta 10 veces—. Como servidores proxy inversos, ambos permiten utilizar varios servidores dedicados para ampliar horizontalmente una implementación tanto como sea necesario.

Tanto PHP como Apache asignan recursos a cada solicitud abierta; si uno de ellos o ambos tienen que cargar varias bibliotecas, el tiempo de inicio por solicitud y el consumo de memoria pueden ser considerables. Usar NGINX como software de servidor web elimina este problema en el servidor. Aprovechar las funciones de NGINX para delegar tareas en el servidor web (como servir archivos estáticos) o en un servidor proxy inverso (todo tipo de almacenamiento en caché, terminación de protocolos, balanceo de carga, etc.) reduce al mínimo el trabajo que debe realizar PHP, lo que simplifica y acelera el procesamiento de las aplicaciones.

Si utiliza módulos de Apache personalizados o propietarios en su sitio, es posible que no pueda sustituir Apache por NGINX hasta que reemplace dichos módulos. Consulte con NGINX si existen soluciones alternativas sencillas; de no ser así, calcule el tiempo y el esfuerzo necesarios para realizar el cambio.

Una vez que decida utilizar NGINX, puede elegir entre NGINX Open Source y NGINX Plus. Algunas de las características más destacadas de NGINX Plus frente a NGINX Open Source son:

Código precompilado. NGINX Plus se distribuye en formato compilado e incluye bibliotecas populares y módulos dinámicos que se pueden añadir y eliminar sobre la marcha. (NGINX Open Source está disponible como código tanto compilado como sin compilar). Se pueden realizar numerosos cambios de configuración sin reiniciar el servidor.
Soporte. NGINX Plus incluye un paquete de soporte, que le permite acceder directamente a los ingenieros de NGINX.
Supervisión y gestión. Las herramientas compatibles con DevOps le ayudan a mantener su servidor en funcionamiento para cumplir los acuerdos de nivel de servicio (SLA).

Como servidor proxy inverso, NGINX Plus ofrece ventajas adicionales:

Equilibrado de carga. Ambas versiones de NGINX admiten el equilibrado de carga HTTP básico, pero NGINX Plus incorpora algoritmos más sofisticados y equilibrado de carga TCP.
Persistencia de sesión. Además del equilibrio de carga, NGINX Plus ofrece una persistencia de sesión más sofisticada, que suele ser muy relevante para los servidores de aplicaciones PHP.
Supervisión y gestión. Toda la gama de funcionalidades de supervisión y gestión de NGINX Plus entra en juego en una implementación con varios servidores; el valor del código precompilado y del soporte también se maximiza en implementaciones más complejas.

Tanto NGINX Open Source como NGINX Plus admiten el almacenamiento en caché de contenido y el microalmacenamiento en caché (también denominado «almacenamiento en caché de aplicaciones»). El almacenamiento en caché resulta útil en el contexto de un servidor web, ya que reduce la carga del servidor de aplicaciones, aunque ambas funciones siguen compartiendo una única máquina o instancia de máquina virtual. En un servidor proxy inverso, el almacenamiento en caché puede descargar una cantidad considerable de trabajo del dispositivo que actúa como servidor de aplicaciones, lo que ofrece mayores ventajas de rendimiento.

Puede descargar el software NGINX Open Source directamente desde nginx.org, donde también encontrará asistencia de la comunidad. Para iniciar una suscripción individual a NGINX Plus, regístrese para obtener una prueba gratuita de 30 días o compre en línea. Para paquetes de varias instancias, póngase en contacto con el equipo de ventas de NGINX.

Consejo 3 – Convierta la configuración de Apache a la sintaxis de NGINX

Cuando migre de Apache a NGINX como software de servidor web, deberá realizar algunos cambios, que se explican en un excelente artículo de sitepoint.com:

Cree o convierta archivos de configuración. Modifique el código de configuración para especificar qué archivos debe utilizar NGINX (en lugar de Apache) para la configuración.
Cambiar los permisos de lectura y escritura. Añada permisos a su cuenta para realizar operaciones CRUD (crear, leer, actualizar y eliminar) en los archivos del directorio raíz del sitio web.
Especificar patrones de búsqueda válidos. Añada un bloque location para especificar qué patrones puede y no puede probar NGINX al procesar las solicitudes.
Sustituya el código de configuración de .htaccess. Los detalles de configuración de Apache suelen encontrarse en archivos .htaccess o en archivos de configuración estáticos (mod_rewrite directivas, por ejemplo). Sustitúyalos por las especificaciones de configuración correspondientes en los archivos de configuración de NGINX. Para ver algunos ejemplos, consulte nuestro blog.

Realizar estos cambios le permitirá familiarizarse con NGINX y le preparará para optimizar sitios más complejos, tal como explicamos en la parte 2 de esta entrada del blog. No obstante, si estos cambios de configuración suponen una cantidad de trabajo o un nivel de riesgo inaceptables para el funcionamiento de su sitio, no se preocupe: puede implementar las arquitecturas multiservidor descritas en la parte 2 sin sustituir Apache como software principal del servidor web y, por tanto, sin modificar los archivos de configuración de su servidor web.

Consejo 4 – Implementa el almacenamiento en caché de archivos estáticos

Los archivos estáticos son simplemente archivos que no cambian con frecuencia, al menos en términos de servidores web. Suelen incluir archivos gráficos, como JPEG y PNG, y archivos de código, como CSS y JavaScript. Si almacena estos archivos en el servidor de aplicaciones o en un servidor de bases de datos independiente, las solicitudes correspondientes deben ser procesadas por el código de la aplicación, con toda la sobrecarga que conlleva realizar y atender una solicitud. Esto «distrae» al servidor de aplicaciones de tareas más importantes y puede acercarlo al punto en que la memoria física se satura y las nuevas solicitudes hacen que las solicitudes en curso se transfieran al disco.

El almacenamiento en caché de archivos estáticos es una función esencial de NGINX. Puede implementarlo en un servidor web o en un servidor proxy inverso:

En un servidor web NGINX, el almacenamiento en caché de archivos estáticos reduce la carga del servidor de aplicaciones; los archivos se recuperan más rápidamente y con un consumo de memoria mucho menor. Sin embargo, la recuperación de archivos sigue realizándose desde el mismo servidor físico o la misma instancia de servidor virtual, por lo que el procesador del servidor sigue teniendo que ocuparse de otras tareas además de ejecutar la aplicación.
Un servidor proxy inverso NGINX se ejecuta en una máquina o instancia distinta de la del servidor web, por lo que el almacenamiento en caché de archivos estáticos no consume recursos de los servidores de aplicaciones. El servidor de aplicaciones puede centrarse exclusivamente en ejecutar su aplicación.

La implementación del almacenamiento en caché de archivos estáticos en NGINX consta de tres pasos generales:

Especificar el directorio raíz para las búsquedas.
Procesamiento de solicitudes.
Optimización de la velocidad de respuesta.

En un servidor web NGINX sin un servidor proxy inverso, no se utiliza la caché en el sentido habitual. Simplemente se redirigen al servidor web las solicitudes de archivos estáticos mediante la cabecera X-Accel-Redirect. El servidor de aplicaciones nunca recibe la solicitud y puede dedicar todos sus recursos a las solicitudes de la aplicación. Con un servidor proxy inverso, sí se utiliza la caché de archivos estáticos, y el servidor físico o la instancia de servidor virtual donde se ejecuta la aplicación no interviene en la respuesta a las solicitudes de archivos estáticos.

Como ejemplo de optimización de la velocidad de respuesta, el siguiente fragmento de configuración permite que NGINX utilice la llamada al sistema sendfile del sistema operativo, lo que evita un paso en la transmisión de archivos al no copiar el archivo en un búfer intermedio:

location /mp3 {    sendfile           on;
    sendfile_max_chunk 1m;
    # ...
}

Para obtener información detallada sobre cómo configurar NGINX para el almacenamiento en caché de archivos estáticos, consulte la Guía de administración de NGINX Plus.

Consejo 5 – Implemente el microalmacenamiento en caché

La microcaché, aunque resulte confuso, recibe muchos nombres, entre ellos caché de aplicaciones o simplemente caché. En NGINX utilizamos el término microcaché para destacar el breve periodo de validez de estos archivos.

Supongamos que tiene una página con una entrada de blog que permite a los usuarios publicar comentarios. Quiere incluir los comentarios más recientes e interesantes cada vez que un nuevo visitante acceda a la página, o cuando los usuarios existentes la actualicen para ver un comentario nuevo, ya sea suyo o de otra persona. En este caso, parece buena idea volver a generar la página cada vez que alguien la visite.

Sin embargo, hacerlo «cada vez» puede resultar costoso. Si una página recibe una visita por segundo, tiene sentido generarla de nuevo con cada visita. Pero si recibe diez, cien o mil visitas por segundo, además de las que reciben todas las demás páginas del sitio, el servidor de aplicaciones puede sobrecargarse. Al intentar ofrecer contenido actualizado a los usuarios, se acaba consiguiendo que nadie reciba ningún contenido con rapidez.

El microalmacenamiento en caché consiste en generar una página una vez y marcar la versión almacenada en caché como válida durante un breve periodo de tiempo —por ejemplo, uno o varios segundos—. Cuando la versión almacenada en caché caduca, la siguiente solicitud hace que se genere una página actualizada, y las solicitudes inmediatamente posteriores reciben la versión almacenada en caché. Es el mismo comportamiento que con un archivo estático, pero en intervalos de tiempo mucho más cortos.

Esta imagen indica en qué partes de su sitio debe buscar contenido que pueda almacenar en microcaché. Procede de una entrada de blog sobre microcaché de nuestro compañero Owen Garrett.

Gran parte del contenido dinámico es apto para el microalmacenamiento en caché

El microalmacenamiento en caché es fantástico porque reduce la carga de trabajo del servidor de aplicaciones justo cuando más se necesita, sin apenas perjudicar al usuario. Es tan útil que viene integrado en algunos sistemas. Drupal considera tan esenciales sus sólidas funciones integradas de microalmacenamiento en caché que, en el mundo de Drupal, se denomina simplemente «almacenamiento en caché».

Sin embargo, la solución de Drupal se queda un poco corta, al igual que cualquier solución similar. El servidor de aplicaciones realiza menos trabajo, pero sigue siendo Drupal (o, de forma más general, PHP) quien tiene que gestionar la configuración, la implementación y el servicio de archivos. Al utilizar NGINX para el microalmacenamiento en caché, el servidor de aplicaciones queda totalmente liberado de cualquier tarea, salvo la de generar una página nueva con la frecuencia especificada por la microcaché. Ni siquiera recibe las demás solicitudes, y mucho menos tiene que almacenar o recuperar contenido cuando se producen aciertos de caché.

Con NGINX Plus u otras herramientas, puede supervisar su sitio web y determinar qué páginas se beneficiarán del microalmacenamiento en caché. El siguiente fragmento de configuración establece un periodo de almacenamiento en caché de 1 segundo para las respuestas con un código de estado 200 OK.

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;server {
    proxy_cache cache;
    proxy_cache_valid 200 1s;
    # ...
}

Conclusión de la primera parte

Esta primera parte de nuestra entrada de blog sobre PHP se centra en las soluciones de servidor único y en el almacenamiento en caché, que resulta eficaz en implementaciones de servidor único, pero aún más cuando se incorpora un servidor proxy inverso. La parte 2 describe las ventajas de implementar varios servidores en torno a su aplicación PHP mediante un servidor proxy inverso.

Para probar NGINX Plus, empiece hoy mismo su prueba gratuita de 30 días o póngase en contacto con nosotros para hablar sobre sus casos de uso.