Maximizar el rendimiento de PHP 7 con NGINX, parte 1: Servicios web y almacenamiento en caché

Introducción – Cómo se utiliza NGINX con PHP

PHP es la forma más popular de crear una aplicação web del lado del servidor, con aproximadamente el 80 % de la participación de mercado . (ASP.net ocupa un distante segundo lugar, y Java un aún más distante tercer lugar).

El universo PHP incluye una multitud de frameworks PHP; los más populares incluyen Laravel, Phalcon y Symfony 2. PHP también es la base de sistemas de gestión de contenidos (CMS) populares 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 está lanzando una nueva versión, PHP 7 , más de una década después de la introducción de PHP 5. Durante este tiempo, el uso de la web y las demandas de los sitios web han aumentado exponencialmente. PHP ha contribuido a ese rápido crecimiento, pero sus limitaciones también quedan resaltadas por el mismo crecimiento que ha posibilitado.

Generalmente PHP es considerado potente y flexible, pero sujeto a problemas de rendimiento. Los sitios basados en PHP pueden fácilmente “encallar” después de unas cuantas duplicaciones en el número de tráfico. Apenas cuando un sitio comienza a cumplir sus objetivos comerciales u operativos, comienza a fallar cuando aumenta el volumen de tráfico.

Para miles y miles de aplicações basadas en PHP, algunos cambios relativamente simples han sido suficientes para mejorar el rendimiento. Estos incluyen almacenamiento en caché con herramientas como memcached , ajuste de bases de datos, proxy inverso y equilibrio de carga con NGINX Open Source y NGINX Plus . NGINX ha mejorado enormemente la capacidad de respuesta de las aplicaciones, permitiendo aumentos de orden de magnitud en el número de usuarios y tráfico.

Esta publicación 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 la actualización a PHP 7, la implementación de NGINX Open Source o NGINX Plus como su software de servidor web, la reescritura de URL (necesario para que las solicitudes se gestionen correctamente), el almacenamiento en caché de archivos estáticos y el almacenamiento en caché de archivos dinámicos (también llamado almacenamiento en caché de aplicação o microcaching).

En la próxima publicación del blog, nos centramos en los pasos que puede seguir con servidores adicionales: agregar un servidor proxy inverso, migrar a múltiples servidores de aplicação , equilibrar la carga entre múltiples servidores, admitir la persistencia de la sesión durante el equilibrio de carga y finalizar los protocolos de seguridad, como SSL/TLS y el protocolo HTTP/2 relacionado.

¿Por qué PHP se estanca?

¿Por qué las aplicações PHP se estancan? Por la misma razón que cualquier software de servidor de aplicação se estrella contra un muro. Cuando llega una solicitud de usuario, PHP (y el software de servidor web sobre el que se ejecuta) deben hacer varias cosas:

• Descifrar la solicitud . Primero, el software del servidor web y luego PHP tienen que poner en marcha procesos para recibir, descifrar y actuar en función de la solicitud. El servidor HTTP Apache, por ejemplo, asigna recursos para manejar cada solicitud de datos, ya sea simple (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 bastante grande si el sistema operativo, PHP o ambos tienen que cargar una serie de bibliotecas antes incluso de comenzar a procesar la solicitud.
• Manejar protocolos de soporte . Si ejecuta SSL/TLS y/o HTTP/2, su software de servidor web tiene que decodificar las solicitudes, un proceso que puede consumir mucho tiempo.
• Actuar sobre la solicitud . PHP tiene que reunir los recursos para gestionar la solicitud. Esto puede requerir múltiples llamadas a bases de datos, llamadas a través de Internet a servicios externos y un procesamiento interno complicado.
• Responder a la solicitud . PHP tiene que devolver los resultados al software del servidor web para transmitirlos 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 el reconocimiento final.

Eso es mucho para que un servidor físico, una máquina virtual o una instancia de servidor en la nube lo gestionen por cada solicitud. El rendimiento tiende a disminuir cuando se agota la memoria física del servidor (ya sea física o virtual). A continuación, el servidor comienza a paginar las sesiones actuales en el disco a medida que llegan nuevas solicitudes. Esperar que se completen las solicitudes de archivos también introduce estados de espera que también contribuyen a la paginación. Pasado un 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 la finalización total de la sesión para usuarios frustrados.

Abordar los problemas de rendimiento

Superar las barreras de rendimiento de PHP ciertamente es posible y requiere varios pasos complementarios. Cada paso se puede combinar con otros. A grandes rasgos, incluyen:

• Lanzando hardware al problema . Más memoria, más memoria, discos más rápidos, servidores de bases de datos separados, una red de distribución de contenido, mayor capacidad de rendimiento y otras soluciones mecánicas son una solución rápida y sencilla a los problemas de rendimiento. Estas soluciones pueden preservar el tiempo de actividad o escalar el rendimiento de forma lineal.
• Mejorando PHP y el código de la aplicação . Las nuevas versiones de PHP, los nuevos marcos y el código de aplicação mejorado pueden ayudar mucho. De nuevo, es posible duplicar o incluso cuadriplicar el rendimiento sin gastos adicionales en nuevo hardware.
• Software de servidor mejorado . La mayoría de los servidores web y PHP asignan recursos dedicados a cada solicitud abierta en progreso. El software de servidor NGINX maneja las solicitudes a medida que llegan, sin ocupar recursos, lo que minimiza el espacio del servidor.
• Implementación multiservidor . Puede implementar un servidor proxy inverso para manejar solicitudes de Internet y compartirlas (equilibrio de carga) entre uno o más servidores de aplicação . El servidor proxy inverso también puede gestionar el almacenamiento en caché de archivos, la finalización de protocolos como SSL/TLS y HTTP/2 y la gestión de múltiples servidores de aplicação . Incluso con un solo servidor de aplicação , esto descarga una gran parte de su carga de trabajo. El equilibrio de carga garantiza que ningún servidor se sature con más de su parte de carga a medida que se agregan más servidores.

No es necesario implementar estos pasos en ningún orden particular; por ejemplo, incluso si mantiene Apache como su servidor web y no actualiza su servidor de aplicaciones a PHP 7, simplemente implementar NGINX como un proxy inverso "delante" de sus servidores existentes mejora el rendimiento y le permite implementar múltiples servidores de aplicação en paralelo.

Independientemente de cómo haga las cosas, el hecho clave a tener en cuenta es que puede obtener múltiples factores de aumento del rendimiento, incluso un orden de magnitud en capacidad, con poco o ningún cambio en el código de su aplicação actual. Continúe leyendo para ver cómo las personas ya han logrado, o están en proceso de lograr, estas extraordinarias mejoras de rendimiento.

Nota : Hay una optimización multiservidor que ignoraremos un poco en estas publicaciones del blog. Un servidor de base de datos independiente y una red de distribución de contenido (CDN) pueden descargar su servidor de aplicação y mejorar enormemente el rendimiento; este tipo de cambios son independientes y paralelos a las mejoras de aplicação e implementación que se describen aquí.

Consejo 1 – Actualice a PHP 7

La razón principal para actualizar a PHP 7, más temprano que tarde, es simple: la velocidad de la aplicação (significativamente facilitada 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 considerablemente menos memoria. (Sin duda, los resultados variarán en ambos aspectos).

El tiempo de respuesta es, sencillamente, crítico para las aplicações web. Una aplicación web más rápida, que también utiliza menos memoria, lo que reduce la probabilidad de intercambio de páginas y los consiguientes problemas de rendimiento, logra tres cosas:

1. Hace que los usuarios estén más contentos y tengan más probabilidades de visitar y completar tareas en su sitio, como leer artículos, obtener información sobre productos, tomar un autobús, alquilar una habitación libre o comprar cosas. Es decir, las razones por las que creaste el sitio o la aplicación en primer lugar.
2. Permite que un servidor determinado admita más usuarios sin correr el riesgo de que se ralentice o incluso deje de funcionar debido a usuarios adicionales. Posponer el desastre siempre es algo bueno.
3. Hace que su servidor sea menos vulnerable a ataques de piratas informáticos que sobrecargan su servidor y lo sacan de producción. Hoy en día todos son atacados, pero los débiles son atacados más y más agresivamente. Por lo tanto, una menor vulnerabilidad puede ser exponencialmente mejor que una mayor.

Todas ellas son excelentes razones para actualizar; en conjunto, la justificación para hacerlo parece casi abrumadora. Y “actualizar a la última versión” es siempre la primera recomendación para solucionar muchos problemas, incluso cuando no hay un beneficio de rendimiento tan claro. Entonces, ¿por qué no todo el mundo actualiza de inmediato?

Sencillo: a la gente le disgusta manipular códigos antiguos, y con buena razón. Si una aplicación antigua funciona suficientemente bien y los desarrolladores obtienen mejores resultados al crear aplicaciones nuevas que al actualizar las antiguas, la aplicación antigua puede permanecer sin cambios durante mucho tiempo. (Consulte la segunda publicación del blog de esta serie para obtener información sobre cómo usar NGINX para mejorar el rendimiento de su aplicación sin realizar cambios en su servidor web y aplicación actuales).

Pero lo más eficiente, si es que es posible, es comenzar la búsqueda de un mayor rendimiento actualizándose a PHP 7. Sin embargo, no empieces hasta que tengas tiempo suficiente para terminar, especialmente sin escatimar en pruebas.

Echemos un vistazo a lo que se necesita para actualizar a PHP 7:

• Cambios en la evaluación de expresiones . Es posible que necesites cambiar la forma en que se escriben algunas expresiones para que se evalúen correctamente en PHP 7. (O, si eres realmente cuidadoso y no actualizas todos tus servidores PHP a la vez, para que se evalúen correctamente tanto en PHP 5.6 como en PHP 7). Si tiene variables variables o propiedades variables, deberá 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 o script. No es posible tener varios casos predeterminados para un conmutador. (Dejamos de lado la polémica entre switch versus if-then-else .)
• Eliminación de funcionalidad obsoleta . Todo tipo de cosas que quedaron obsoletas en varias versiones 5.x de PHP ahora están más muertas que un loro muerto . Simplemente no funcionan en PHP 7. Si están en tu código y tratas de eliminarlos todos y no lo logras, la funcionalidad de tu código de carrito de compras seguramente desaparecerá a las 11:59 p. m. la noche anterior al Cyber Monday.
• Nuevas funciones . PHP 7 agrega una serie de nuevas características para tentar a cualquiera que actualice el código antiguo, pero tenga cuidado al agregar nuevas características en una limpieza de código. Las nuevas características suelen ser maravillosas, o no se habrían agregado, pero también son imanes para errores (los suyos y los de otros) y futuras revisiones a medida que PHP se actualiza aún más.
• Revisión general del código . Cada vez que tocas un código (o incluso cada vez que abres un archivo de código y no estás seguro de si lo modificaste o no), realmente necesitas revisar todo lo que contiene, especialmente lo que hayas modificado.
• Prueba . Todo necesita ser probado todo el tiempo. Si realiza algún cambio, deberá volver a probar todo, y eso no significa que detectará todos los errores. Un entorno DevOps bien implementado puede hacer que estas pruebas sean relativamente fáciles, pero hoy en día solo unos pocos de nosotros vivimos en esa tierra prometida.

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

Si decide seguir adelante y actualizar a PHP 7, considere realizar una revisión y análisis de rendimiento completo de su código, o al menos de sus características críticas, aprovechando las nuevas características de PHP 7. No hay mejor manera para que usted y su equipo mejoren sus habilidades, y los cambios que haga, revise y pruebe hoy probablemente le servirán durante muchos años. También aprovechará al máximo las otras sugerencias de rendimiento de esta publicación del blog, porque el código optimizado se beneficia enormemente al ejecutarse en un entorno optimizado.

Por lo tanto, a pesar del hecho de que los sitios a menudo implementan NGINX para obtener un mejor rendimiento sin tocar el código de la aplicação , le recomendamos que tome las riendas y avance. Hay mucha ayuda disponible para realizar el traslado, o simplemente puedes arremangarte y hacerlo tú mismo . Hay una guía de migración a PHP 7 en el sitio oficial de PHP y un libro con instrucciones para actualizar a PHP 7 de O'Reilly.

Consejo 2 – Elija NGINX Open Source o NGINX Plus

NGINX es el software que ejecuta más de 140 millones de sitios web, incluida la mitad de los 10.000 sitios web más activos . (Estas mediciones detectan el servidor web en sitios con un solo servidor y el servidor proxy inverso en sitios con múltiples servidores). Como servidores web, ambos ofrecen un aumento de rendimiento inmediato (en algunos casos, cuando un servidor que ejecuta otro software se ha sobrecargado y colapsado, hasta 10 veces). Como servidor proxy inverso, ambos permiten el uso de múltiples servidores dedicados para escalar una implementación tanto como sea necesario.

Tanto PHP como Apache asignan recursos a cada solicitud abierta; si uno o ambos tienen que cargar varias bibliotecas, el tiempo de inicio por solicitud y el consumo de memoria pueden ser considerables. Pasar a NGINX como software de servidor web elimina este problema a nivel de servidor. El uso de la funcionalidad de NGINX para descargar trabajo al servidor web (como servir archivos estáticos) o a un servidor proxy inverso (todo tipo de almacenamiento en caché, terminación de protocolo, equilibrio de carga, etc.) minimiza lo que PHP tiene que hacer, simplificando y acelerando el procesamiento de la aplicação .

Si tiene módulos Apache personalizados o propietarios para su sitio, es posible que no pueda reemplazar Apache con NGINX hasta que reemplace los módulos. Consulte con NGINX para ver si hay soluciones alternativas sencillas; si no, calcule el tiempo y el esfuerzo necesarios para realizar el cambio.

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

• Código precompilado . NGINX Plus se distribuye en forma compilada, incluyendo bibliotecas populares y módulos dinámicos que puedes agregar y eliminar sobre la marcha. (NGINX Open Source está disponible como código compilado y no compilado ). Puede realizar una amplia gama de cambios de configuración sin reiniciar el servidor .
• Apoyo . NGINX Plus incluye un paquete de soporte que le brinda acceso directo a los ingenieros de NGINX.
• Monitoreo y gestión . Las herramientas compatibles con DevOps le ayudan a mantener su servidor en funcionamiento para cumplir con los acuerdos de nivel de servicio (SLA).

Como servidor proxy inverso, NGINX Plus tiene ventajas adicionales:

• Equilibrio de carga . Ambas versiones de NGINX admiten el equilibrio de carga HTTP básico, pero NGINX Plus agrega algoritmos más sofisticados y equilibrio de carga TCP .
• Persistencia de la sesión . Junto con el equilibrio de carga, NGINX Plus ofrece una persistencia de sesión más sofisticada, a menudo muy relevante para los servidores de aplicação PHP.
• Monitoreo y gestión . La gama completa de capacidades de monitoreo y administración de NGINX Plus entran en juego en una implementación de múltiples servidores; el valor del código precompilado y el soporte también se maximizan en implementaciones más complejas.

Tanto NGINX Open Source como NGINX Plus admiten el almacenamiento en caché de contenido y el microcaching (también llamado almacenamiento en caché de aplicação ). El almacenamiento en caché es útil en el contexto del servidor web, ya que descarga el servidor de aplicação , pero ambas funciones siguen compartiendo una sola máquina o instancia de máquina virtual . En un servidor proxy inverso, el almacenamiento en caché puede descargar una cantidad significativa de trabajo del dispositivo servidor de aplicação , lo que ofrece mayores ventajas de rendimiento.

Puedes descargar el open source software NGINX directamente desde nginx.org , donde también encontrarás soporte de la comunidad . Para iniciar una suscripción única a NGINX Plus, regístrese para una prueba gratuita de 30 días o compre en línea . Para paquetes de múltiples instancias, comuníquese con el departamento de ventas de NGINX .

Consejo 3: Convertir la configuración de Apache a la sintaxis NGINX

Cuando migra de Apache a NGINX como su software de servidor web, hay algunos cambios que debe realizar, detallados en un excelente artículo en sitepoint.com :

• Crear o convertir archivos de configuración . Cambie el código de configuración para especificar qué archivos NGINX (ya no Apache) debe usar para la configuración.
• Cambiar permisos de lectura/escritura . Agregue permiso a su cuenta para realizar operaciones CRUD (Crear, Leer, Actualizar, Eliminar) en archivos en el directorio raíz del sitio web.
• Especifique patrones de búsqueda válidos . Agregue un bloque de ubicación para especificar qué patrones NGINX puede y no puede probar mientras procesa solicitudes.
• Reemplace el código de configuración .htaccess . Los detalles de configuración de Apache tienden a residir en archivos .htaccess o en archivos de configuración estática (directivas mod_rewrite , por ejemplo). Reemplácelos con especificaciones de configuración relevantes en los archivos de configuración de NGINX. Para ver algunos ejemplos, consulte nuestro blog .

Realizar estos cambios lo familiarizará con NGINX y lo preparará para optimizar sitios más complejos, como describimos en la Parte 2 de esta publicación del blog. Sin embargo, si realizar estos cambios de configuración representa una cantidad inaceptable de trabajo o un grado de riesgo para las operaciones de su sitio, no tema: puede implementar las arquitecturas multiservidor descritas en la Parte 2 sin actualizar el software principal del servidor web de Apache y, por lo tanto, sin cambiar los archivos de configuración de su servidor web.

Consejo 4: Implementar 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 servidor web. Los archivos estáticos generalmente incluyen archivos gráficos como JPEG y PNG y archivos de código como archivos CSS y JavaScript. Si coloca estos archivos en su servidor de aplicação o en un servidor de base de datos separado, las solicitudes de estos deben ser procesadas por el código de la aplicação , con toda la sobrecarga requerida para realizar y cumplir una solicitud. Esto “distrae” al servidor de aplicação de trabajo más importante y puede acercarlo al punto en que la memoria física se sobrecargue y las nuevas solicitudes hagan que las solicitudes actuales se exporten al disco.

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

• En un servidor web NGINX, el almacenamiento en caché de archivos estáticos descarga el servidor de aplicação ; los archivos se recuperan más rápido y con mucha menos sobrecarga de memoria. Sin embargo, la recuperación de archivos todavía se realiza desde el mismo servidor físico o instancia de servidor virtual , por lo que el procesador del servidor aún se ve obligado a lidiar con tareas distintas a la ejecución de la aplicação.
• Un servidor proxy inverso NGINX se ejecuta en una máquina o instancia diferente del servidor web, por lo que su almacenamiento en caché de archivos estáticos no consume recursos en los servidores de aplicação . El servidor de aplicação puede centrarse exclusivamente en ejecutar su aplicação.

Hay tres pasos generales para implementar el almacenamiento en caché de archivos estáticos en NGINX:

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

En un servidor web NGINX, sin un servidor proxy inverso involucrado, no se almacena en caché en el sentido habitual. Simplemente redirige las consultas de archivos estáticos al servidor web, utilizando el encabezado X-Accel-Redirect . El servidor de aplicação nunca ve la solicitud y puede dedicar todos sus recursos a las solicitudes de aplicação . Con un servidor proxy inverso, se utiliza almacenamiento en caché de archivos estáticos y el servidor físico o la instancia del servidor virtual que ejecuta la aplicação no tiene ninguna participación en responder 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 ahorra un paso en la transmisión del archivo al no copiar el archivo a un búfer intermedio:

ubicación /mp3 { enviar archivo activado;
sendfile_max_chunk 1m;
# ...
}

Para obtener información específica sobre la configuración de NGINX para el almacenamiento en caché de archivos estáticos, consulte la Guía de administración de NGINX Plus .

Consejo 5: Implementar microcaching

El microcaching, aunque resulte confuso, tiene muchos nombres, que también incluyen el caché de aplicação y el caché simple. Aquí en NGINX, utilizamos el término microcaching para enfatizar el breve período durante el cual dichos archivos son válidos.

Digamos que tienes una página de publicaciones de blog que proporciona un mecanismo para comentarios de los usuarios. Desea incluir los mejores y más recientes comentarios cada vez que un nuevo visitante llega a la página, o cada vez que los usuarios existentes actualizan la página para ver sus propios comentarios o los de otra persona. En este caso, parece una buena idea generar la página nueva cada vez que alguien la visita.

Sin embargo, “cada vez” puede llegar a resultar una carga. Si una página recibe una visita por segundo, tiene sentido generarla de nuevo para cada visita. Pero si la página recibe diez, cien o mil visitas por segundo, junto con todas las demás páginas del sitio, el servidor de aplicação puede sobrecargarse. Alcanzar el objetivo de ofrecer a las personas contenido nuevo significa que nadie obtiene contenido rápidamente.

El microcaching significa generar una página una vez que se marca la versión almacenada en caché como válida por un breve período de tiempo, digamos uno o unos pocos segundos. Cuando la versión en caché expira, la siguiente solicitud solicita la generación de una página nueva y las solicitudes posteriores obtienen su versión en caché. Este es el mismo comportamiento que para un archivo estático, pero en períodos de tiempo mucho más cortos.

Esta imagen indica dónde buscar en su sitio contenido que pueda almacenar en microcaché. Proviene de una publicación de blog sobre microcaching de nuestro propio Owen Garrett.

El microcaching es fantástico porque elimina trabajo del servidor de aplicação justo cuando más se necesita y con muy poco o ningún perjuicio para el usuario. Es tan asombroso que está integrado en algunos sistemas. Drupal considera que sus capacidades de microcaching integradas y robustas son tan esenciales que, en el mundo de Drupal, al microcaching simplemente se le llama “caching”.

Pero la solución de Drupal es un poco deficiente, como también lo es cualquier solución similar. El servidor de aplicação hace menos trabajo, pero sigue siendo Drupal (o, más generalmente, PHP) el que tiene que gestionar la configuración, la implementación y el servicio de archivos. Al utilizar NGINX para microcaché, el servidor de aplicação queda totalmente liberado de cualquier tarea, excepto de generar una página nueva con la frecuencia especificada por el microcaché. Ni siquiera ve las otras solicitudes, y mucho menos tiene que almacenar o recuperar algo para los accesos a la caché.

Usando NGINX Plus u otras herramientas, puede monitorear su sitio y ver qué páginas se beneficiarán del microcaching. El siguiente fragmento de configuración implementa un período de almacenamiento en caché de 1 segundo para las respuestas con un 200Código de estado OK .

ruta_caché_proxy /tmp/cache zona_claves=caché:10m niveles=1:2 inactivo=600s tamaño_máximo=100m;servidor {
caché_proxy caché;
caché_proxy_válido 200 1s;
# ...
}

Conclusión de la Parte 1

Esta primera parte de nuestra publicación del blog sobre PHP se centra en las soluciones de servidor único, además del almacenamiento en caché, que es efectivo en implementaciones de servidor único, pero más aún cuando hay un servidor proxy inverso en la mezcla. La Parte 2 describe los beneficios de un servidor proxy inverso y una implementación multiservidor alrededor de su aplicação PHP.

Para probar NGINX Plus, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso.