10 consejos para multiplicar por 10 el rendimiento de las aplicaciones

NGINX | 05 de octubre de 2015

Floyd SmithDirector de marketing de contenidos

Mejorar el rendimiento de las aplicaciones web es más importante que nunca. La proporción de la actividad económica que se desarrolla en línea está aumentando; más del 5 % de la economía del mundo desarrollado ya está en Internet (consulte «Recursos sobre estadísticas de Internet» más abajo). Además, en nuestro mundo moderno, siempre conectado e hiperconectado, las expectativas de los usuarios son más altas que nunca. Si su sitio no responde al instante o su aplicación no funciona sin demora, los usuarios se pasan rápidamente a la competencia.

Por ejemplo, un estudio realizado por Amazon hace casi 10 años demostró que, ya entonces, una reducción de 100 milisegundos en el tiempo de carga de las páginas se traducía en un aumento del 1 % de sus ingresos. Otro estudio reciente puso de manifiesto que más de la mitad de los propietarios de sitios web encuestados afirmaron haber perdido ingresos o clientes debido al bajo rendimiento de sus aplicaciones.

¿Qué velocidad debe tener un sitio web? Por cada segundo que tarda una página en cargarse, alrededor del 4 % de los usuarios la abandonan. Los principales sitios de comercio electrónico ofrecen un tiempo hasta la primera interacción de entre uno y tres segundos, lo que permite alcanzar la tasa de conversión más alta. Está claro que hay mucho en juego en lo que respecta al rendimiento de las aplicaciones web, y es probable que su importancia siga aumentando.

Querer mejorar el rendimiento es fácil, pero obtener resultados reales es difícil. Para ayudarte en este proceso, esta entrada del blog te ofrece diez consejos con los que podrás multiplicar hasta por 10 el rendimiento de tu sitio web. Es la primera de una serie en la que se explica cómo aumentar el rendimiento de tu aplicación mediante técnicas de optimización ampliamente probadas y con un poco de ayuda de NGINX. Esta serie también describe las posibles mejoras de seguridad que puedes conseguir durante el proceso.

Consejo 1: acelera y protege las aplicaciones con un servidor proxy inverso

Si su aplicación web se ejecuta en una sola máquina, la solución a los problemas de rendimiento puede parecer obvia: basta con adquirir una máquina más rápida, con más capacidad de procesamiento, más RAM, una matriz de discos rápida, etc. De este modo, la nueva máquina podrá ejecutar su servidor de WordPress, su aplicación Node.js, su aplicación Java, etc., más rápido que antes. (Si su aplicación accede a un servidor de bases de datos, la solución podría seguir pareciendo sencilla: adquirir dos máquinas más rápidas y disponer de una conexión más rápida entre ellas).

El problema es que quizá la velocidad de la máquina no sea la causa. Las aplicaciones web suelen funcionar con lentitud porque el equipo alterna entre distintos tipos de tareas: interactuar con usuarios a través de miles de conexiones, acceder a archivos del disco y ejecutar código de la aplicación, entre otras. Es posible que el servidor de aplicaciones esté saturado: se queda sin memoria, vuelca bloques de memoria al disco y hace que muchas solicitudes tengan que esperar a que finalice una única tarea, como una operación de E/S de disco.

En lugar de actualizar el hardware, puede adoptar un enfoque completamente distinto: añadir un servidor proxy inverso para descargar algunas de estas tareas. Un servidor proxy inverso se sitúa delante de la máquina que ejecuta la aplicación y gestiona el tráfico de Internet. Solo el servidor proxy inverso está conectado directamente a Internet; la comunicación con los servidores de aplicaciones se realiza a través de una red interna rápida.

El uso de un servidor proxy inverso evita que el servidor de aplicaciones tenga que esperar a que los usuarios interactúen con la aplicación web y le permite centrarse en generar páginas para que el servidor proxy inverso las envíe a través de Internet. Al no tener que esperar las respuestas de los clientes, el servidor de aplicaciones puede funcionar a velocidades similares a las alcanzadas en pruebas de rendimiento optimizadas.

Añadir un servidor proxy inverso también aporta flexibilidad a la configuración de los servidores web. Por ejemplo, si un servidor de un tipo determinado está sobrecargado, se puede añadir fácilmente otro del mismo tipo; si un servidor deja de funcionar, se puede sustituir fácilmente.

Gracias a la flexibilidad que ofrece, un servidor proxy inverso también es un requisito previo para muchas otras funciones que mejoran el rendimiento, como:

Equilibrado de carga (consulte el Consejo 2) : un equilibrador de carga se ejecuta en un servidor proxy inverso para distribuir el tráfico de manera uniforme entre varios servidores de aplicaciones. Con un equilibrador de carga, puede añadir servidores de aplicaciones sin modificar en absoluto su aplicación.
Almacenamiento en caché de archivos estáticos (véase Consejo 3) – Los archivos que se solicitan directamente, como los archivos de imagen o de código, pueden almacenarse en el servidor proxy inverso y enviarse directamente al cliente, lo que permite servir los recursos con mayor rapidez y reduce la carga del servidor de aplicaciones, haciendo que la aplicación funcione más rápido.
Proteger su sitio web – El servidor proxy inverso se puede configurar con un alto nivel de seguridad y supervisar para detectar y responder rápidamente a los ataques, manteniendo protegidos los servidores de aplicaciones.

El software NGINX está diseñado específicamente para utilizarse como servidor proxy inverso, con las funcionalidades adicionales descritas anteriormente. NGINX utiliza un enfoque de procesamiento basado en eventos que resulta más eficiente que el de los servidores tradicionales. NGINX Plus incorpora funciones de proxy inverso más avanzadas, como las comprobaciones de estado de las aplicaciones, el enrutamiento especializado de solicitudes, el almacenamiento en caché avanzado y el soporte técnico.

Consejo 2 – Añade un equilibrador de carga

Añadir un balanceador de carga es un cambio relativamente sencillo que puede mejorar drásticamente el rendimiento y la seguridad de tu sitio web. En lugar de aumentar el tamaño y la potencia de un servidor web principal, puedes utilizar un balanceador de carga para distribuir el tráfico entre varios servidores. Incluso si una aplicación está mal programada o tiene problemas de escalabilidad, un balanceador de carga puede mejorar la experiencia del usuario sin necesidad de realizar ningún otro cambio.

Un balanceador de carga es, ante todo, un servidor proxy inverso (consulte el Consejo 1): recibe tráfico de Internet y reenvía las solicitudes a otro servidor. La clave está en que el balanceador de carga admite dos o más servidores de aplicaciones y utiliza diversos algoritmos para distribuir las solicitudes entre ellos. El método de balanceo de carga más sencillo es el de turno rotatorio (round robin), en el que cada nueva solicitud se envía al siguiente servidor de la lista. Otros métodos consisten en enviar las solicitudes al servidor con menos conexiones activas. NGINX Plus ofrece funcionalidades para mantener una sesión de usuario determinada en el mismo servidor, lo que se denomina persistencia de sesión.

Los balanceadores de carga pueden mejorar considerablemente el rendimiento, ya que evitan que un servidor se sobrecargue mientras otros esperan a recibir tráfico. También facilitan la ampliación de la capacidad de los servidores web, puesto que permiten añadir servidores de coste relativamente bajo con la certeza de que se aprovecharán al máximo.

Entre los protocolos en los que se puede equilibrar la carga se incluyen HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI, SCGI, uwsgi, memcached y otros tipos de aplicaciones, incluidas las aplicaciones basadas en TCP y otros protocolos de capa 4. Analice sus aplicaciones web para determinar cuáles utiliza y dónde se producen problemas de rendimiento.

El mismo servidor o los mismos servidores utilizados para el balanceo de carga también pueden realizar otras tareas, como la terminación SSL, la compatibilidad con HTTP/1.x y HTTP/2 para los clientes, y el almacenamiento en caché de archivos estáticos.

NGINX se utiliza a menudo para el balanceo de carga. Para obtener más información, descargue nuestro libro electrónico, «Cinco razones para elegir un balanceador de carga de software». Puede consultar las instrucciones básicas de configuración en «Balanceo de carga con NGINX y NGINX Plus, parte 1» y la documentación completa en la «Guía de administración de NGINX Plus». NGINX Plus es nuestro producto comercial y admite funciones de balanceo de carga más especializadas, como el enrutamiento de la carga en función del tiempo de respuesta del servidor y la posibilidad de balancear la carga mediante el protocolo NTLM de Microsoft.

Consejo 3: almacena en caché el contenido estático y dinámico

El almacenamiento en caché mejora el rendimiento de las aplicaciones web al entregar el contenido a los clientes con mayor rapidez. Puede incluir varias estrategias: preprocesar el contenido para entregarlo rápidamente cuando sea necesario, almacenarlo en dispositivos más rápidos, guardarlo más cerca del cliente o combinar estas opciones.

Hay dos tipos diferentes de almacenamiento en caché que se deben tener en cuenta:

Almacenamiento en caché de contenido estático – Los archivos que cambian con poca frecuencia, como los archivos de imagen (JPEG, PNG) y los archivos de código (CSS, JavaScript), pueden almacenarse en un servidor perimetral para recuperarlos rápidamente desde la memoria o el disco.
Almacenamiento en caché de contenido dinámico – Muchas aplicaciones web generan HTML nuevo para cada solicitud de página. Al almacenar temporalmente en caché una copia del HTML generado durante un breve periodo, puede reducir drásticamente el número total de páginas que deben generarse y, al mismo tiempo, seguir ofreciendo contenido lo bastante actualizado como para satisfacer sus requisitos.

Por ejemplo, si una página recibe 10 visitas por segundo y se almacena en caché durante 1 segundo, el 90 % de las solicitudes de la página se atenderán desde la caché. Si el contenido estático se almacena en caché por separado, incluso las versiones recién generadas de la página podrían estar compuestas en gran medida por contenido almacenado en caché.

Existen tres técnicas principales para almacenar en caché el contenido generado por las aplicaciones web:

Acercar el contenido a los usuarios – Mantener una copia del contenido más cerca del usuario reduce el tiempo de transmisión.
Trasladar el contenido a máquinas más rápidas – El contenido puede almacenarse en una máquina más rápida para recuperarlo con mayor rapidez.
Trasladar el contenido fuera de máquinas sobrecargadas – A veces, las máquinas funcionan mucho más despacio que su rendimiento de referencia en una tarea concreta porque están ocupadas con otras tareas. Almacenar el contenido en caché en otra máquina mejora el rendimiento tanto de los recursos almacenados en caché como de los que no lo están, ya que la máquina anfitriona está menos sobrecargada.

El almacenamiento en caché para aplicaciones web puede implementarse de dentro hacia fuera, empezando por el servidor de aplicaciones web. En primer lugar, se utiliza para el contenido dinámico con el fin de reducir la carga de los servidores de aplicaciones. A continuación, se aplica al contenido estático (incluidas las copias temporales de lo que, de otro modo, sería contenido dinámico), lo que reduce aún más la carga de dichos servidores. Por último, la caché se traslada de los servidores de aplicaciones a máquinas más rápidas o más cercanas al usuario, aliviando así la carga de los servidores de aplicaciones y reduciendo los tiempos de recuperación y transmisión.

Una caché mejorada puede acelerar enormemente las aplicaciones. En muchas páginas web, los datos estáticos, como los archivos de imagen de gran tamaño, representan más de la mitad del contenido. Recuperar y transmitir estos datos sin usar la caché puede llevar varios segundos, pero solo unas fracciones de segundo si se almacenan en la caché local.

Como ejemplo de cómo se utiliza el almacenamiento en caché en la práctica, NGINX y NGINX Plus emplean dos directivas para configurar el almacenamiento en caché: proxy_cache_path y proxy_cache. Puede especificar la ubicación y el tamaño de la caché, el tiempo máximo que se conservan los archivos en ella y otros parámetros. Mediante una tercera directiva (bastante popular), proxy_cache_use_stale, puede incluso configurar la caché para que proporcione contenido obsoleto cuando el servidor que suministra contenido actualizado esté ocupado o no disponible, de modo que el cliente reciba algo en lugar de nada. Desde la perspectiva del usuario, esto puede mejorar considerablemente la disponibilidad de su sitio web o aplicación.

NGINX Plus cuenta con funciones avanzadas de almacenamiento en caché, incluida la compatibilidad con el vaciado de la caché y la visualización del estado de la caché en un panel de control para supervisar la actividad en tiempo real.

Para obtener más información sobre el almacenamiento en caché con NGINX, consulte la documentación de referencia y la Guía de administración de NGINX Plus.

Nota: El almacenamiento en caché trasciende las divisiones organizativas entre quienes desarrollan aplicaciones, quienes toman decisiones de inversión de capital y quienes gestionan redes en tiempo real. Las estrategias sofisticadas de almacenamiento en caché, como las mencionadas aquí, son un buen ejemplo del valor de una perspectiva DevOps, en la que se integran las perspectivas de los desarrolladores de aplicaciones, de arquitectura y de operaciones para ayudar a alcanzar los objetivos de funcionalidad del sitio, tiempo de respuesta, seguridad y resultados empresariales, como transacciones completadas o ventas.

Consejo 4 – Comprime los datos

La compresión puede mejorar enormemente el rendimiento. Existen estándares de compresión cuidadosamente diseñados y muy eficaces para fotos (JPEG y PNG), vídeos (MPEG‑4) y música (MP3), entre otros. Cada uno de estos estándares reduce el tamaño de los archivos en un orden de magnitud o más.

Los datos de texto —incluido el HTML (que contiene texto sin formato y etiquetas HTML), el CSS y código como JavaScript— suelen transmitirse sin comprimir. Comprimir estos datos puede tener un impacto desproporcionado en el rendimiento percibido de las aplicaciones web, especialmente para los clientes con conexiones móviles lentas o limitadas.

Esto se debe a que los datos de texto suelen ser suficientes para que un usuario interactúe con una página, mientras que los datos multimedia pueden desempeñar una función más complementaria o decorativa. Una compresión inteligente del contenido puede reducir los requisitos de ancho de banda de HTML, Javascript, CSS y otros contenidos basados en texto, normalmente en un 30 % o más, con la consiguiente reducción del tiempo de carga.

Si utiliza SSL, la compresión reduce la cantidad de datos que deben codificarse mediante SSL, lo que compensa parte del tiempo de CPU necesario para comprimirlos.

Los métodos para comprimir datos de texto varían. Por ejemplo, consulte el Consejo 6 para conocer un novedoso método de compresión de texto en SPDY y HTTP/2, adaptado específicamente a los datos de cabecera. Otro ejemplo de compresión de texto consiste en activar la compresión GZIP en NGINX. Después de precomprimir los datos de texto en sus servicios, puede servir directamente el archivo comprimido .gz mediante la directiva gzip_static.

Consejo 5 – Optimiza SSL/TLS

El protocolo de capa de sockets seguros (SSL) y su sucesor, el protocolo de seguridad de la capa de transporte (TLS), se utilizan cada vez en más sitios web. SSL/TLS cifra los datos que se transmiten desde los servidores de origen hasta los usuarios para ayudar a mejorar la seguridad del sitio. Uno de los factores que puede estar impulsando esta tendencia es que Google ahora considera la presencia de SSL/TLS como un factor positivo para el posicionamiento en los motores de búsqueda.

A pesar de su creciente popularidad, el impacto de SSL/TLS en el rendimiento sigue siendo un obstáculo para muchos sitios web. SSL/TLS ralentiza el rendimiento de los sitios web por dos motivos:

El protocolo de enlace inicial necesario para establecer las claves de cifrado cada vez que se abre una nueva conexión. El hecho de que los navegadores que utilizan HTTP/1.x establezcan varias conexiones por servidor multiplica ese impacto.
Sobrecarga continua derivada del cifrado de datos en el servidor y su descifrado en el cliente.

Para fomentar el uso de SSL/TLS, los autores de HTTP/2 y SPDY (descritos en el siguiente consejo) diseñaron estos protocolos de modo que los navegadores solo necesiten una conexión por sesión. Esto reduce considerablemente una de las dos principales fuentes de sobrecarga de SSL. Sin embargo, hoy en día aún se puede hacer más para mejorar el rendimiento de las aplicaciones suministradas mediante SSL/TLS.

El mecanismo para optimizar SSL/TLS varía según el servidor web. Por ejemplo, NGINX utiliza OpenSSL, que se ejecuta en hardware estándar de uso general, para ofrecer un rendimiento similar al de las soluciones de hardware dedicadas. El rendimiento de SSL de NGINX está ampliamente documentado y minimiza el tiempo y la carga de CPU que conllevan el cifrado y descifrado SSL/TLS.

Además, consulte esta entrada del blog para obtener información detallada sobre cómo mejorar el rendimiento de SSL/TLS. En resumen, las técnicas son las siguientes:

Almacenamiento en caché de sesiones – Utiliza la directiva ssl_session_cache para almacenar en caché los parámetros utilizados al proteger cada nueva conexión con SSL/TLS.
Tickets o identificadores de sesión – Almacenan información sobre sesiones SSL/TLS específicas en un ticket o identificador para que una conexión pueda reutilizarse sin problemas y sin tener que realizar un nuevo protocolo de enlace.
Grapado OCSP – Reduce el tiempo de negociación almacenando en caché la información del certificado SSL/TLS.

NGINX y NGINX Plus pueden utilizarse para la terminación SSL/TLS, gestionando el cifrado y descifrado del tráfico de los clientes mientras se comunican con otros servidores mediante texto sin cifrar. Para configurar NGINX o NGINX Plus para gestionar la terminación SSL/TLS, consulte las instrucciones sobre conexiones HTTPS y conexiones TCP cifradas.

Consejo 6 – Implemente HTTP/2 o SPDY

En los sitios que ya utilizan SSL/TLS, es muy probable que HTTP/2 y SPDY mejoren el rendimiento, ya que la conexión única solo requiere un protocolo de enlace. En los sitios que aún no utilizan SSL/TLS, HTTP/2 y SPDY compensan la pérdida de rendimiento que normalmente supone migrar a SSL/TLS, por lo que el cambio no afecta a la capacidad de respuesta.

Google presentó SPDY en 2012 como una forma de mejorar el rendimiento sobre HTTP/1.x. HTTP/2 es el estándar de la IETF basado en SPDY que se ha aprobado recientemente. SPDY cuenta con una amplia compatibilidad, pero pronto quedará obsoleto y será sustituido por HTTP/2.

La característica principal de SPDY y HTTP/2 es el uso de una única conexión en lugar de varias. Esta conexión se multiplexa, por lo que puede transportar fragmentos de varias solicitudes y respuestas al mismo tiempo.

Al aprovechar al máximo una sola conexión, estos protocolos evitan la sobrecarga que supone establecer y gestionar varias conexiones, como exige la forma en que los navegadores implementan HTTP/1.x. El uso de una sola conexión resulta especialmente útil con SSL, ya que reduce al mínimo el laborioso proceso de negociación que SSL/TLS necesita para establecer una conexión segura.

El protocolo SPDY exigía el uso de SSL/TLS; HTTP/2 no lo exige oficialmente, pero hasta ahora todos los navegadores compatibles con HTTP/2 solo lo utilizan si SSL/TLS está habilitado. Es decir, un navegador compatible con HTTP/2 solo lo utiliza si el sitio web usa SSL y su servidor acepta tráfico HTTP/2. De lo contrario, el navegador se comunica mediante HTTP/1.x.

Al implementar SPDY o HTTP/2, ya no se necesitan las optimizaciones de rendimiento habituales de HTTP, como la fragmentación de dominios, la combinación de recursos y el uso de sprites de imágenes. Estos cambios simplifican el código y las implementaciones, y facilitan su gestión. Para obtener más información sobre los cambios que está introduciendo HTTP/2, consulte nuestro libro blanco, «HTTP/2 para desarrolladores de aplicaciones web».

Como ejemplo de compatibilidad con estos protocolos, NGINX ha sido compatible con SPDY desde sus inicios, y la mayoría de los sitios que utilizan SPDY actualmente se ejecutan en NGINX. NGINX también está a la vanguardia de la compatibilidad con HTTP/2, con compatibilidad con HTTP/2 en NGINX de código abierto y NGINX Plus desde septiembre de 2015.

Con el tiempo, en NGINX esperamos que la mayoría de los sitios habiliten SSL por completo y migren a HTTP/2. Esto aumentará la seguridad y, a medida que se descubran e implementen nuevas optimizaciones, permitirá disponer de un código más sencillo y con un mejor rendimiento.

Consejo 7 – Actualiza las versiones del software

Una forma sencilla de mejorar el rendimiento de las aplicaciones es seleccionar los componentes de la pila de software en función de su reputación en cuanto a estabilidad y rendimiento. Además, dado que los desarrolladores de componentes de alta calidad suelen seguir mejorando el rendimiento y corrigiendo errores con el tiempo, conviene utilizar la última versión estable del software. Las nuevas versiones reciben más atención por parte de los desarrolladores y de la comunidad de usuarios. Las compilaciones más recientes también aprovechan las nuevas optimizaciones de los compiladores, incluidos los ajustes para hardware nuevo.

Las nuevas versiones estables suelen ofrecer una mayor compatibilidad y un mejor rendimiento que las versiones anteriores. Además, mantener el software actualizado facilita estar al día de las optimizaciones de rendimiento, las correcciones de errores y las alertas de seguridad.

Seguir utilizando software antiguo también puede impedirle aprovechar nuevas funcionalidades. Por ejemplo, HTTP/2, descrito anteriormente, requiere actualmente OpenSSL 1.0.1. A partir de mediados de 2016, HTTP/2 requerirá OpenSSL 1.0.2, que se publicó en enero de 2015.

Los usuarios de NGINX pueden empezar por actualizar a la última versión de NGINX o NGINX Plus; estas incluyen nuevas funcionalidades, como la fragmentación de sockets y los grupos de subprocesos (consulte el Consejo 9), y ambas se optimizan constantemente para mejorar su rendimiento. A continuación, revise el software de las capas más profundas de su pila y actualícelo a la versión más reciente siempre que sea posible.

Consejo 8 – Ajusta Linux para mejorar el rendimiento

Linux es el sistema operativo subyacente de la mayoría de las implementaciones de servidores web actuales y, como base de su infraestructura, ofrece una importante oportunidad para mejorar el rendimiento. De forma predeterminada, muchos sistemas Linux están configurados de manera conservadora para utilizar pocos recursos y adaptarse a la carga de trabajo habitual de un equipo de escritorio. Esto significa que los casos de uso de aplicaciones web requieren al menos cierto grado de optimización para alcanzar el máximo rendimiento.

Las optimizaciones de Linux dependen del servidor web. Tomando NGINX como ejemplo, estas son algunas de las principales modificaciones que puede plantearse para acelerar Linux:

Cola de conexiones pendientes – Si algunas conexiones parecen quedarse bloqueadas, considere aumentar net.core.somaxconn, el número máximo de conexiones que pueden permanecer en cola a la espera de ser atendidas por NGINX. Si el límite de conexiones actual es demasiado bajo, verá mensajes de error; puede aumentar gradualmente este parámetro hasta que dejen de aparecer.
Descriptores de archivo – NGINX utiliza hasta dos descriptores de archivo por cada conexión. Si su sistema gestiona muchas conexiones, puede que tenga que aumentar sys.fs.file_max, el límite de descriptores de archivo de todo el sistema, y nofile, el límite de descriptores de archivo por usuario, para soportar el aumento de la carga.
Puertos efímeros – Cuando se utiliza como proxy, NGINX crea puertos temporales («efímeros») para cada servidor ascendente. Puede ampliar el intervalo de valores de puerto, definido mediante net.ipv4.ip_local_port_range, para aumentar el número de puertos disponibles. También puede reducir el tiempo de espera antes de que se reutilice un puerto inactivo mediante el ajuste net.ipv4.tcp_fin_timeout, lo que permite una rotación más rápida.

Para NGINX, consulta la guía de optimización del rendimiento de NGINX para aprender a optimizar tu sistema Linux de modo que pueda gestionar grandes volúmenes de tráfico de red sin despeinarse.

Consejo 9 – Optimiza el rendimiento de tu servidor web

Sea cual sea el servidor web que utilice, debe ajustarlo para optimizar el rendimiento de las aplicaciones web. Las siguientes recomendaciones se aplican, en general, a cualquier servidor web, aunque se proporcionan ajustes específicos para NGINX. Entre las principales optimizaciones se incluyen:

Registro de accesos – En lugar de escribir inmediatamente en el disco una entrada de registro por cada solicitud, puede almacenar las entradas temporalmente en la memoria y escribirlas en el disco en bloque. En NGINX, añada el parámetro buffer=size a la directiva access_log para escribir las entradas de registro en el disco cuando se llene el búfer de memoria. Si añade el parámetro flush=time, el contenido del búfer también se escribirá en el disco una vez transcurrido el tiempo especificado.
Almacenamiento en búfer – El almacenamiento en búfer conserva parte de una respuesta en la memoria hasta que el búfer se llena, lo que puede hacer que la comunicación con el cliente sea más eficiente. Las respuestas que no caben en la memoria se escriben en el disco, lo que puede reducir el rendimiento. Cuando el almacenamiento en búfer de NGINX está activado, se utilizan las directivas proxy_buffer_size y proxy_buffers para gestionarlo.
Conexiones persistentes de cliente – Las conexiones persistentes reducen la sobrecarga, especialmente cuando se utiliza SSL/TLS. En NGINX, puede aumentar el número máximo de solicitudes keepalive_requests que un cliente puede realizar a través de una conexión determinada respecto al valor predeterminado de 100, así como aumentar el valor de keepalive_timeout para que la conexión persistente permanezca abierta durante más tiempo, lo que agiliza las solicitudes posteriores.
Conexiones persistentes con servidores upstream – Las conexiones upstream —es decir, las conexiones con servidores de aplicaciones, servidores de bases de datos, etc.— también se benefician de las conexiones persistentes. Para las conexiones upstream, puede aumentar keepalive, el número de conexiones persistentes inactivas que permanecen abiertas para cada proceso de trabajo. Esto permite reutilizar más las conexiones y reduce la necesidad de abrir conexiones completamente nuevas. Para obtener más información, consulte nuestra entrada del blog Conexiones HTTP persistentes y rendimiento web.
Límites – Limitar los recursos que utilizan los clientes puede mejorar el rendimiento y la seguridad. En NGINX, las directivas limit_conn y limit_conn_zone restringen el número de conexiones procedentes de un origen determinado, mientras que limit_rate limita el ancho de banda. Estos ajustes pueden impedir que un usuario legítimo acapare recursos y también ayudan a prevenir ataques. Las directivas limit_req y limit_req_zone limitan las solicitudes de los clientes. Para las conexiones a servidores ascendentes, utilice el parámetro max_conns de la directiva server en un bloque de configuración upstream. Esto limita las conexiones a un servidor ascendente y evita que se sobrecargue. La directiva asociada queue crea una cola que retiene un número determinado de solicitudes durante un periodo de tiempo específico una vez alcanzado el límite de max_conns.
Procesos de trabajo – Los procesos de trabajo se encargan de procesar las solicitudes. NGINX utiliza un modelo basado en eventos y mecanismos dependientes del sistema operativo para distribuir eficazmente las solicitudes entre los procesos de trabajo. Se recomienda establecer el valor de worker_processes en uno por CPU. El número máximo de worker_connections (512 de forma predeterminada) puede aumentarse de forma segura en la mayoría de los sistemas si es necesario; pruebe distintos valores hasta encontrar el que mejor funcione en su sistema.
Fragmentación de sockets – Normalmente, un único socket de escucha distribuye las nuevas conexiones entre todos los procesos de trabajo. La fragmentación de sockets crea un socket de escucha para cada proceso de trabajo, y el kernel asigna las conexiones a los sockets de escucha a medida que están disponibles. Esto puede reducir la contención de bloqueos y mejorar el rendimiento en sistemas multinúcleo. Para habilitar la fragmentación de sockets, incluya el parámetro reuseport en la directiva listen.
Grupos de subprocesos – Cualquier proceso informático puede verse bloqueado por una única operación lenta. En el software de servidores web, el acceso al disco puede bloquear muchas operaciones más rápidas, como calcular o copiar información en la memoria. Cuando se utiliza un grupo de subprocesos, la operación lenta se asigna a un conjunto de tareas independiente, mientras que el bucle de procesamiento principal continúa ejecutando las operaciones más rápidas. Cuando finaliza la operación de disco, los resultados vuelven al bucle de procesamiento principal. En NGINX, dos operaciones – la llamada al sistema read() y sendfile() – se delegan en grupos de subprocesos.

Los grupos de subprocesos ayudan a mejorar el rendimiento de las aplicaciones al asignar las operaciones lentas a un conjunto de tareas independiente

Consejo. Al cambiar la configuración de cualquier sistema operativo o servicio auxiliar, modifique un solo ajuste cada vez y, a continuación, compruebe el rendimiento. Si el cambio causa problemas o no hace que su sitio funcione más rápido, reviértalo.

Para obtener más información sobre cómo optimizar un servidor web NGINX, consulta nuestra publicación del blog «Optimización del rendimiento de NGINX».

Consejo 10 – Supervise la actividad en tiempo real para resolver problemas y cuellos de botella

La clave de un enfoque de alto rendimiento para el desarrollo y la entrega de aplicaciones consiste en supervisar de cerca y en tiempo real el rendimiento de la aplicación en condiciones reales. Debe poder monitorizar la actividad tanto en dispositivos específicos como en toda su infraestructura web.

La monitorización de la actividad del sitio es principalmente pasiva: te informa de lo que está ocurriendo y deja en tus manos detectar y solucionar los problemas.

La monitorización puede detectar varios tipos de problemas, entre ellos:

Un servidor está caído.
Un servidor funciona con dificultades y pierde conexiones.
Un servidor está experimentando una alta proporción de fallos de caché.
Un servidor no está enviando el contenido correcto.

Una herramienta global de monitorización del rendimiento de aplicaciones, como New Relic o Dynatrace, le ayuda a supervisar el tiempo de carga de las páginas desde ubicaciones remotas, mientras que NGINX le permite monitorizar la entrega de la aplicación. Los datos de rendimiento de la aplicación le indican cuándo sus optimizaciones están suponiendo una mejora real para los usuarios y cuándo debe plantearse ampliar la capacidad de su infraestructura para soportar el tráfico.

Para ayudar a identificar y resolver problemas rápidamente, NGINX Plus incorpora comprobaciones de estado con reconocimiento de aplicaciones —transacciones sintéticas que se repiten periódicamente y se utilizan para alertarle de posibles problemas—. NGINX Plus también ofrece drenaje de sesiones, que impide nuevas conexiones mientras se completan las tareas existentes, y una función de inicio lento, que permite que un servidor recuperado alcance gradualmente su pleno rendimiento dentro de un grupo con equilibrio de carga. Cuando se utilizan eficazmente, las comprobaciones de estado permiten identificar problemas antes de que afecten significativamente a la experiencia del usuario, mientras que el drenaje de sesiones y el inicio lento permiten sustituir servidores y garantizar que el proceso no afecte negativamente al rendimiento percibido ni al tiempo de actividad. La figura muestra el panel integrado de NGINX Plus para la supervisión de la actividad en tiempo real de una infraestructura web con servidores, conexiones TCP y almacenamiento en caché.

Conclusión: una mejora del rendimiento de 10 veces

Las mejoras de rendimiento que se pueden conseguir en una aplicación web varían enormemente, y los resultados reales dependen del presupuesto, del tiempo que pueda invertir y de las carencias de su implementación actual. Entonces, ¿cómo podría multiplicar por 10 el rendimiento de sus propias aplicaciones?

Para orientarte sobre el impacto potencial de cada optimización, a continuación se indican las mejoras que podrían lograrse con cada uno de los consejos detallados anteriormente, aunque es casi seguro que los resultados variarán:

Servidor proxy inverso y equilibrio de carga – La ausencia de equilibrio de carga, o un equilibrio de carga deficiente, puede provocar episodios de muy bajo rendimiento. Añadir un servidor proxy inverso, como NGINX, puede evitar que las aplicaciones web alternen constantemente entre la memoria y el disco. El equilibrio de carga permite trasladar el procesamiento de los servidores sobrecargados a otros disponibles y facilita el escalado. Estos cambios pueden mejorar drásticamente el rendimiento: es fácil multiplicarlo por 10 en comparación con los peores momentos de la implementación actual, además de lograr mejoras menores, pero sustanciales, en el rendimiento general.
Almacenamiento en caché de contenido dinámico y estático – Si tiene un servidor web sobrecargado que también funciona como servidor de aplicaciones, puede multiplicar por 10 el rendimiento en horas punta simplemente almacenando en caché el contenido dinámico. El almacenamiento en caché de archivos estáticos también puede multiplicar el rendimiento por una cifra de un solo dígito.
Compresión de datos – El uso de formatos de compresión de archivos multimedia, como JPEG para fotos, PNG para gráficos, MPEG‑4 para vídeos y MP3 para archivos de música, puede mejorar considerablemente el rendimiento. Una vez que se utilicen todos ellos, comprimir los datos de texto (código y HTML) puede reducir a la mitad el tiempo de carga inicial de la página.
Optimización de SSL/TLS – Los protocolos de enlace seguros pueden tener un gran impacto en el rendimiento, por lo que optimizarlos puede llegar a duplicar la capacidad de respuesta inicial, especialmente en sitios con mucho texto. Es probable que la optimización de la transmisión de archivos multimedia mediante SSL/TLS solo aporte pequeñas mejoras de rendimiento.
Implementación de HTTP/2 y SPDY – Cuando se utilizan con SSL/TLS, es probable que estos protocolos mejoren progresivamente el rendimiento general del sitio.
Optimización de Linux y del software del servidor web (como NGINX) – Algunos ajustes, como optimizar el almacenamiento en búfer, usar conexiones persistentes y derivar las tareas que requieren mucho tiempo a un grupo de subprocesos independiente, pueden mejorar considerablemente el rendimiento; por ejemplo, los grupos de subprocesos pueden acelerar las tareas que hacen un uso intensivo del disco en casi un orden de magnitud.

Esperamos que pruebe estas técnicas. Nos gustaría saber qué mejoras de rendimiento consigue en sus aplicaciones. Comparta sus resultados en los comentarios o cuente su experiencia en Twitter con los hashtags #NGINX y #webperf.