10 consejos para multiplicar por 10 el rendimiento de aplicação

Mejorar el rendimiento de las aplicação web es más importante que nunca. La proporción de actividad económica que se realiza en línea está creciendo: más del 5% de la economía del mundo desarrollado está ahora en Internet (ver Recursos para estadísticas de Internet a continuación). Y nuestro mundo moderno, siempre activo e hiperconectado, implica que las expectativas de los usuarios son más altas que nunca. Si su sitio no responde instantáneamente o su aplicación no funciona sin demora, los usuarios rápidamente se van a la competencia.

Por ejemplo, un estudio realizado por Amazon hace casi 10 años demostró que, incluso entonces, una disminución de 100 milisegundos en el tiempo de carga de una página se traducía en un aumento del 1% en sus ingresos. Otro estudio reciente destacó el hecho de que más de la mitad de los propietarios de sitios encuestados dijeron que perdieron ingresos o clientes debido al bajo rendimiento de las aplicação .

¿Qué tan rápido debe ser un sitio web? Por cada segundo que una página tarda en cargarse, aproximadamente el 4% de los usuarios la abandonan. Los mejores sitios de comercio electrónico ofrecen un tiempo hasta la primera interacción que varía de uno a tres segundos, lo que ofrece la tasa de conversión más alta. Está claro que lo que está en juego en cuanto al rendimiento de las aplicação web es mucho y es probable que aumente.

Querer mejorar el rendimiento es fácil, pero ver resultados reales es difícil. Para ayudarlo en su viaje, esta publicación de blog le ofrece diez consejos que lo ayudarán a aumentar el rendimiento de su sitio web hasta diez veces. Este es el primero de una serie que detalla cómo puedes aumentar el rendimiento de tu aplicação con técnicas de optimización de eficacia probada y con el apoyo de NGINX. Esta serie también describe posibles mejoras de seguridad que puedes obtener durante el proceso.

Consejo 1: Acelere y proteja aplicações con un servidor proxy inverso

Si su aplicação web se ejecuta en una sola máquina, la solución a los problemas de rendimiento puede parecer obvia: simplemente conseguir una máquina más rápida, con más procesador, más RAM, una matriz de discos rápida, etc. Entonces, la nueva máquina puede ejecutar su servidor WordPress, aplicação Node.js, aplicação Java, etc., más rápido que antes. (Si su aplicação accede a un servidor de base de datos, la solución puede parecer sencilla: conseguir dos máquinas más rápidas y una conexión más rápida entre ellas).

El problema es que la velocidad de la máquina podría no ser el problema. Las aplicações web a menudo se ejecutan lentamente porque la computadora cambia entre distintos tipos de tareas: interactuar con usuarios en miles de conexiones, acceder a archivos desde el disco y ejecutar código de aplicação , entre otras. Es posible que el servidor de aplicação esté funcionando mal: se esté quedando sin memoria, intercambiando fragmentos de memoria con el disco y haciendo que muchas solicitudes esperen una sola tarea, como la E/S del disco.

En lugar de actualizar su hardware, puede adoptar un enfoque totalmente diferente: agregar un servidor proxy inverso para descargar algunas de estas tareas. Un servidor proxy inverso se ubica frente a la máquina que ejecuta la aplicação y maneja el tráfico de Internet. Sólo el servidor proxy inverso está conectado directamente a Internet; la comunicación con los servidores de aplicação se realiza a través de una red interna rápida.

El uso de un servidor proxy inverso libera al servidor de aplicação de tener que esperar a que los usuarios interactúen con la aplicación web y le permite concentrarse en crear páginas para que el servidor proxy inverso las envíe a través de Internet. El servidor de aplicação , que ya no tiene que esperar respuestas del cliente, puede funcionar a velocidades cercanas a las alcanzadas en los benchmarks optimizados.

Agregar un servidor proxy inverso también agrega flexibilidad a la configuración de su servidor web. Por ejemplo, si un servidor de un tipo determinado está sobrecargado, se puede agregar fácilmente otro servidor del mismo tipo; si un servidor no funciona, se puede reemplazar fácilmente.

Debido a la flexibilidad que proporciona, un servidor proxy inverso también es un requisito previo para muchas otras capacidades de mejora del rendimiento, como:

• Equilibrio de carga (ver Consejo 2 ): un equilibrador de carga se ejecuta en un servidor proxy inverso para compartir el tráfico de manera uniforme entre varios servidores de aplicação . Con un balanceador de carga instalado, puede agregar servidores de aplicação sin cambiar su aplicação en absoluto.
• Almacenamiento en caché de archivos estáticos (ver Consejo 3 ): los archivos que se solicitan directamente, como archivos de imágenes o archivos de código, se pueden almacenar en el servidor proxy inverso y enviar directamente al cliente, que sirve activos más rápidamente y descarga el servidor de aplicação , lo que permite que la aplicação se ejecute más rápido.
• Protección de su sitio : el servidor proxy inverso se puede configurar para alta seguridad y monitorear para un rápido reconocimiento y respuesta a ataques, manteniendo protegidos los servidores de aplicação .

El software NGINX está diseñado específicamente para su uso como servidor proxy inverso, con las capacidades adicionales descritas anteriormente. NGINX utiliza un enfoque de procesamiento basado en eventos que es más eficiente que los servidores tradicionales. NGINX Plus agrega funciones de proxy inverso más avanzadas, como controles del estado de la aplicação , enrutamiento de solicitudes especializado, almacenamiento en caché avanzado y soporte.

Consejo 2 – Agregar un balanceador de carga

Agregar un balanceador de carga es un cambio relativamente fácil que puede crear una mejora drástica en el rendimiento y la seguridad de su sitio. En lugar de hacer que un servidor web central sea más grande y más potente, se utiliza un equilibrador de carga para distribuir el tráfico entre varios servidores. Incluso si una aplicação está mal escrita o tiene problemas de escalabilidad, un balanceador de carga puede mejorar la experiencia del usuario sin ningún otro cambio.

Un balanceador de carga es, en primer lugar, un servidor proxy inverso (ver Consejo 1 ): recibe tráfico de Internet y reenvía solicitudes a otro servidor. El truco es que el balanceador de carga admite dos o más servidores de aplicação , utilizando una selección de algoritmos para dividir las solicitudes entre los servidores. El enfoque de equilibrio de carga más simple es el de turno rotatorio, en el que cada nueva solicitud se envía al siguiente servidor de la lista. Otros métodos incluyen enviar solicitudes al servidor con menos conexiones activas. NGINX Plus tiene capacidades para continuar una sesión de usuario determinada en el mismo servidor, lo que se denomina persistencia de sesión.

Los balanceadores de carga pueden generar importantes mejoras en el rendimiento porque evitan que un servidor se sobrecargue mientras otros esperan tráfico. También facilitan la expansión de la capacidad de su servidor web, ya que puede agregar servidores de costo relativamente bajo y estar seguro de que se utilizarán en su totalidad.

Los protocolos que pueden equilibrarse incluyen HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI , SCGI, uwsgi, memcached y varios otros tipos de aplicação , incluidas aplicações basadas en TCP y otros protocolos de capa 4. Analice sus aplicações web para determinar cuáles utiliza y dónde el rendimiento es menor.

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

NGINX se utiliza a menudo para equilibrar la carga. Para obtener más información, descargue nuestro libro electrónico, Cinco razones para elegir un balanceador de carga de software . Puede obtener instrucciones de configuración básicas en Equilibrio de carga con NGINX y NGINX Plus, Parte 1 , y documentación completa en la Guía de administración de NGINX Plus . NGINX Plus es nuestro producto comercial y admite funciones de equilibrio de carga más especializadas, como el enrutamiento de carga basado en el tiempo de respuesta del servidor y la capacidad de equilibrar la carga en el protocolo NTLM de Microsoft.

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

El almacenamiento en caché mejora el rendimiento de las aplicação web al entregar el contenido a los clientes más rápido. El almacenamiento en caché puede implicar varias estrategias: preprocesar el contenido para una entrega rápida cuando sea necesario, almacenar el contenido en dispositivos más rápidos, almacenar el contenido más cerca del cliente o una combinación.

Hay dos tipos diferentes de almacenamiento en caché a considerar:

• Almacenamiento en caché de contenido estático : los archivos que cambian con poca frecuencia, como archivos de imagen (JPEG, PNG) y archivos de código (CSS, JavaScript), se pueden almacenar en un servidor perimetral para recuperarlos rápidamente de la memoria o el disco.
• Almacenamiento en caché de contenido dinámico : muchas aplicações web generan HTML nuevo para cada solicitud de página. Al almacenar en caché brevemente una copia del HTML generado durante un breve período de tiempo, puede reducir drásticamente la cantidad total de páginas que se deben generar y, al mismo tiempo, ofrecer contenido lo suficientemente actualizado para satisfacer sus requisitos.

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

Hay tres técnicas principales para almacenar en caché el contenido generado por aplicações web:

• Acercar el contenido a los usuarios : mantener una copia del contenido más cerca del usuario reduce su tiempo de transmisión.
• Mover contenido a máquinas más rápidas : el contenido se puede mantener en una máquina más rápida para una recuperación más rápida.
• Trasladar contenido de máquinas sobreutilizadas : a veces las máquinas funcionan mucho más lento que su rendimiento de referencia en una tarea particular porque están ocupadas con otras tareas. El almacenamiento en caché en una máquina diferente mejora el rendimiento de los recursos almacenados en caché y también de los recursos no almacenados en caché, porque la máquina host está menos sobrecargada.

El almacenamiento en caché de aplicações web se puede implementar desde adentro (desde el servidor de aplicação web) hacia afuera. En primer lugar, el almacenamiento en caché se utiliza para contenido dinámico, para reducir la carga en los servidores de aplicação . Luego, el almacenamiento en caché se utiliza para contenido estático (incluidas copias temporales de lo que de otro modo sería contenido dinámico), lo que descarga aún más los servidores de aplicação . Luego, el almacenamiento en caché se traslada desde los servidores de aplicação a máquinas que son más rápidas o están más cerca del usuario, lo que descarga los servidores de aplicação y reduce los tiempos de recuperación y transmisión.

Un almacenamiento en caché mejorado puede acelerar enormemente las aplicações . En muchas páginas web, los datos estáticos, como archivos de imágenes grandes, representan más de la mitad del contenido. Puede que lleve varios segundos recuperar y transmitir dichos datos sin almacenamiento en caché, pero solo fracciones de segundo si los datos se almacenan en caché localmente.

Como ejemplo de cómo se utiliza el almacenamiento en caché en la práctica, NGINX y NGINX Plus utilizan dos directivas para configurar el almacenamiento en caché : proxy_cache_path y proxy_cache . Usted especifica la ubicación y el tamaño del caché, el tiempo máximo que los archivos se mantienen en el caché y otros parámetros. Usando una tercera directiva (y bastante popular), proxy_cache_use_stale , puedes incluso indicarle al caché que suministre contenido obsoleto cuando el servidor que suministra contenido nuevo está ocupado o inactivo, brindándole al cliente algo en lugar de nada. Desde la perspectiva del usuario, esto puede mejorar considerablemente el tiempo de actividad de su sitio o aplicación.

NGINX Plus tiene funciones de almacenamiento en caché avanzadas , incluido soporte para la purga de caché y visualización del estado de caché en un tablero para monitoreo de actividad en vivo.

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é cruza las líneas organizacionales entre las personas que desarrollan aplicações, las personas que toman decisiones de inversión de capital y las personas que ejecutan redes en tiempo real. Las estrategias de almacenamiento en caché sofisticadas, como las que se mencionan aquí, son un buen ejemplo del valor de una perspectiva DevOps , en la que las perspectivas de desarrollador de aplicaciones, arquitectura y operaciones se fusionan para ayudar a cumplir los objetivos de funcionalidad del sitio, tiempo de respuesta, seguridad y resultados comerciales (como transacciones o ventas completadas).

Consejo 4 – Comprimir datos

La compresión es un enorme acelerador potencial del rendimiento. Existen estándares de compresión cuidadosamente diseñados y altamente efectivos para fotos (JPEG y PNG), videos (MPEG-4) y música (MP3), entre otros. Cada uno de estos estándares reduce el tamaño del archivo en un orden de magnitud o más.

Los datos de texto, incluidos HTML (que incluye texto simple y etiquetas HTML), CSS y código como JavaScript, a menudo se transmiten sin comprimir. Comprimir estos datos puede tener un impacto desproporcionado en el rendimiento percibido de la aplicação web, especialmente para clientes con conexiones móviles lentas o restringidas.

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 ser más útiles o decorativos. La compresión de contenido inteligente 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 una reducción correspondiente en el tiempo de carga.

Si usa SSL, la compresión reduce la cantidad de datos que deben codificarse con SSL, lo que compensa parte del tiempo de CPU que se necesita para comprimir los datos.

Los métodos para comprimir datos de texto varían. Por ejemplo, consulte el Consejo 6 para conocer un nuevo esquema de compresión de texto en SPDY y HTTP/2, adaptado específicamente para datos de encabezado. Como otro ejemplo de compresión de texto, puede activar la compresión GZIP en NGINX. Tras precomprimir los datos de texto en sus servicios, puede servir el archivo .gz comprimido directamente mediante la directiva gzip_static .

Consejo 5 – Optimizar SSL/TLS

El protocolo Secure Sockets Layer ( SSL ) y su sucesor, el protocolo Transport Layer Security (TLS), se utilizan cada vez en más sitios web. SSL/TLS cifra los datos transportados desde los servidores de origen a los usuarios para ayudar a mejorar la seguridad del sitio. Parte de lo que puede estar influyendo en esta tendencia es que Google ahora utiliza la presencia de SSL/TLS como una influencia positiva en las clasificaciones de los motores de búsqueda.

A pesar de la creciente popularidad, el impacto en el rendimiento que implica SSL/TLS es un punto conflictivo para muchos sitios. SSL/TLS ralentiza el rendimiento del sitio web por dos motivos:

1. El protocolo de enlace inicial necesario para establecer claves de cifrado cada vez que se abre una nueva conexión. La forma en que los navegadores que utilizan HTTP/1. x establecen múltiples conexiones por servidor multiplica ese impacto.
2. Sobrecarga continua por el 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 en gran medida una de las dos principales fuentes de sobrecarga de SSL. Sin embargo, hoy en día se puede hacer aún más para mejorar el rendimiento de las aplicações entregadas mediante SSL/TLS.

El mecanismo para optimizar SSL/TLS varía según el servidor web. Como ejemplo, NGINX utiliza OpenSSL , que se ejecuta en hardware estándar, para brindar un rendimiento similar al de las soluciones de hardware dedicadas. El rendimiento de NGINX SSL está bien documentado y minimiza el tiempo y la pérdida de CPU al realizar el cifrado y descifrado SSL/TLS.

Además, consulte esta publicación de blog para obtener detalles sobre formas de aumentar el rendimiento de SSL/TLS. Para resumir brevemente, las técnicas son:

• 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 ID de sesión : almacenan información sobre sesiones SSL/TLS específicas en un ticket o ID para que una conexión pueda reutilizarse sin problemas, sin necesidad de un nuevo protocolo de enlace.
• Grapado de OCSP : reduce el tiempo de protocolo de enlace al almacenar en caché la información del certificado SSL/TLS.

NGINX y NGINX Plus se pueden usar para la terminación SSL/TLS (manejo del cifrado y descifrado del tráfico del cliente), mientras se comunica con otros servidores en texto sin cifrar. Para configurar NGINX o NGINX Plus para manejar la terminación SSL/TLS, consulte las instrucciones para conexiones HTTPS y conexiones TCP cifradas .

Consejo 6 – Implementar HTTP/2 o SPDY

Para los sitios que ya usan SSL/TLS, es muy probable que HTTP/2 y SPDY mejoren el rendimiento, porque la conexión única requiere solo un protocolo de enlace. Para los sitios que aún no usan SSL/TLS, HTTP/2 y SPDY hacen que la transición a SSL/TLS (que normalmente ralentiza el rendimiento) sea un fracaso desde el punto de vista de la capacidad de respuesta.

Google introdujo SPDY en 2012 como una forma de lograr un rendimiento más rápido sobre HTTP/1. x . HTTP/2 es el estándar IETF recientemente aprobado basado en SPDY. SPDY tiene un amplio soporte, pero pronto quedará obsoleto y será reemplazado por HTTP/2.

La característica clave de SPDY y HTTP/2 es el uso de una única conexión en lugar de múltiples conexiones. La conexión única está multiplexada, por lo que puede transportar fragmentos de múltiples solicitudes y respuestas al mismo tiempo.

Al aprovechar al máximo una conexión, estos protocolos evitan la sobrecarga de configurar y administrar múltiples conexiones, como lo requiere la forma en que los navegadores implementan HTTP/1. x . El uso de una única conexión es especialmente útil con SSL, porque minimiza el lento protocolo de enlace que SSL/TLS necesita para configurar una conexión segura.

El protocolo SPDY requiere el uso de SSL/TLS; HTTP/2 no lo requiere oficialmente, pero hasta ahora todos los navegadores que admiten HTTP/2 lo utilizan solo si SSL/TLS está habilitado. Es decir, un navegador que soporta HTTP/2 lo utiliza sólo si el sitio web utiliza SSL y su servidor acepta tráfico HTTP/2. De lo contrario, el navegador se comunica a través de HTTP/1. x .

Cuando implementa SPDY o HTTP/2, ya no necesita optimizaciones de rendimiento HTTP típicas, como fragmentación de dominio, fusión de recursos y creación de imágenes. Estos cambios hacen que su código y sus implementaciones sean más simples y fáciles de administrar. Para obtener más información sobre los cambios que HTTP/2 está generando, lea nuestro informe técnico, HTTP/2 para desarrolladores de aplicação 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 funcionan con NGINX. NGINX también es pionero en la compatibilidad con HTTP/2, con soporte para 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 completamente SSL y migren a HTTP/2. Esto conducirá a una mayor seguridad y, a medida que se encuentren e implementen nuevas optimizaciones, a un código más simple que funcione mejor.

Consejo 7 – Actualizar las versiones del software

Una forma sencilla de mejorar el rendimiento de las aplicação es seleccionar componentes para su pila de software en función de su reputación de estabilidad y rendimiento. Además, dado que es probable que los desarrolladores de componentes de alta calidad busquen mejoras de rendimiento y corrijan errores con el tiempo, conviene utilizar la última versión estable del software. Los nuevos lanzamientos reciben más atención de los desarrolladores y la comunidad de usuarios. Las compilaciones más nuevas también aprovechan las nuevas optimizaciones del compilador, incluido el ajuste para nuevo hardware.

Las nuevas versiones estables suelen ser más compatibles y tener mayor rendimiento que las versiones anteriores. También es más fácil mantenerse al tanto de las optimizaciones de ajuste, las correcciones de errores y las alertas de seguridad cuando se está al tanto de las actualizaciones de software.

Quedarse con un software antiguo también puede impedirle aprovechar las nuevas capacidades. Por ejemplo, HTTP/2, descrito anteriormente, actualmente requiere OpenSSL 1.0.1. A partir de mediados de 2016, HTTP/2 requerirá OpenSSL 1.0.2, que se lanzó en enero de 2015.

Los usuarios de NGINX pueden comenzar migrando a la última versión de NGINX o NGINX Plus ; estas incluyen nuevas capacidades como fragmentación de sockets y grupos de subprocesos (ver Consejo 9 ), y ambas se optimizan constantemente para mejorar el rendimiento. Luego, mire el software más profundamente en su pila y pase a la versión más reciente siempre que pueda.

Consejo 8: Optimice Linux para el rendimiento

Linux es el sistema operativo subyacente para la mayoría de las implementaciones de servidores web actuales y, como base de su infraestructura, Linux representa una oportunidad importante para mejorar el rendimiento. De manera predeterminada, muchos sistemas Linux están configurados de forma conservadora para utilizar pocos recursos y adaptarse a una carga de trabajo de escritorio típica. Esto significa que los casos de uso de aplicação web requieren al menos cierto grado de ajuste para lograr el máximo rendimiento.

Las optimizaciones de Linux son específicas del servidor web. Usando NGINX como ejemplo, aquí hay algunos cambios destacados que puedes considerar para acelerar Linux:

• Cola de espera : si tiene conexiones que parecen estar bloqueadas, considere aumentar net.core.somaxconn , el número máximo de conexiones que se pueden poner en cola esperando la atención de NGINX. Verá mensajes de error si el límite de conexiones existente es demasiado pequeño; puede aumentar este parámetro gradualmente hasta que desaparezcan los mensajes de error.
• Descriptores de archivos : NGINX utiliza hasta dos descriptores de archivos para cada conexión. Si su sistema atiende muchas conexiones, es posible que necesite aumentar sys.fs.file_max , el límite de todo el sistema para los descriptores de archivos, y nofile , el límite de descriptores de archivos del usuario, para soportar el aumento de carga.
• Puertos efímeros : cuando se utiliza como proxy, NGINX crea puertos temporales (“efímeros”) para cada servidor ascendente. Puede aumentar el rango de valores de puerto, establecido por net.ipv4.ip_local_port_range , para aumentar la cantidad de puertos disponibles. También puede reducir el tiempo de espera antes de que un puerto inactivo se reutilice con la configuración net.ipv4.tcp_fin_timeout , lo que permite una rotación más rápida.

Para NGINX, consulte la guía de ajuste de rendimiento de NGINX para aprender a optimizar su sistema Linux para que pueda manejar grandes volúmenes de tráfico de red sin problemas.

Consejo 9: Optimice el rendimiento de su servidor web

Cualquiera que sea el servidor web que utilice, debe ajustarlo para el rendimiento de la aplicação web. Las siguientes recomendaciones se aplican generalmente a cualquier servidor web, pero se proporcionan configuraciones específicas para NGINX. Las optimizaciones clave incluyen:

• Registro de acceso : en lugar de escribir inmediatamente una entrada de registro para cada solicitud al disco, puede almacenar en búfer las entradas en la memoria y escribirlas en el disco como un grupo. Para NGINX, agregue el parámetro buffer= size a la directiva access_log para escribir entradas de registro en el disco cuando el búfer de memoria se llena. Si agrega el parámetro de tiempo flush= , el contenido del búfer también se escribirá en el disco después de la cantidad de tiempo especificada.
• Almacenamiento en búfer : el almacenamiento en búfer retiene parte de una respuesta en la memoria hasta que se llena, lo que puede hacer que las comunicaciones con el cliente sean más eficientes. Las respuestas que no caben en la memoria se escriben en el disco, lo que puede ralentizar el rendimiento. Cuando el almacenamiento en búfer de NGINX está activado , se utilizan las directivas proxy_buffer_size y proxy_buffers para administrarlo.
• Keepalives del cliente : las conexiones Keepalive reducen la sobrecarga, especialmente cuando se utiliza SSL/TLS. Para NGINX, puede aumentar la cantidad máxima de keepalive_requests que un cliente puede realizar en una conexión determinada desde el valor predeterminado de 100, y puede aumentar keepalive_timeout para permitir que la conexión keepalive permanezca abierta por más tiempo, lo que da como resultado solicitudes posteriores más rápidas.
• Keepalives ascendentes : Las conexiones ascendentes (conexiones a servidores de aplicação , servidores de bases de datos, etc.) también se benefician de las conexiones keepalive. Para las conexiones ascendentes, puede aumentar keepalive , la cantidad de conexiones keepalive inactivas que permanecen abiertas para cada proceso de trabajo. Esto permite una mayor reutilización de la conexión, reduciendo la necesidad de abrir conexiones nuevas. Para obtener más información, consulte nuestra publicación de blog, Conexiones HTTP Keepalive y rendimiento web .
• Límites : limitar los recursos que utilizan los clientes puede mejorar el rendimiento y la seguridad. Para NGINX, las directivas limit_conn y limit_conn_zone restringen la cantidad de conexiones desde una fuente determinada, mientras que limit_rate restringe el ancho de banda. Estas configuraciones pueden evitar que un usuario legítimo “acapara” 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 en la directiva del servidor en un bloque de configuración ascendente . Esto limita las conexiones a un servidor ascendente, evitando la sobrecarga. La directiva de cola asociada crea una cola que contiene una cantidad específica de solicitudes durante un período de tiempo específico después de que se alcanza el límite max_conns .
• Procesos de trabajo : Los procesos de trabajo son responsables del procesamiento de las solicitudes. NGINX emplea un modelo basado en eventos y mecanismos dependientes del sistema operativo para distribuir eficientemente las solicitudes entre los procesos de trabajo. La recomendación es establecer el valor de workers_processes en uno por CPU. El número máximo de workers_connections (512 por defecto) se puede aumentar de manera segura en la mayoría de los sistemas si es necesario; experimente para encontrar el valor que funcione mejor para su sistema.
• Fragmentación de sockets : normalmente, un único oyente de sockets distribuye nuevas conexiones a todos los procesos de trabajo. La fragmentación de sockets crea un oyente de sockets para cada proceso de trabajo, y el núcleo asigna conexiones a los oyentes de sockets a medida que están disponibles. Esto puede reducir la contención de bloqueo 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 interrumpido por una única operación lenta. Para el software de servidor web, el acceso al disco puede permitir 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 separado de tareas, mientras que el bucle de procesamiento principal continúa ejecutando operaciones más rápidas. Cuando se completa la operación del disco, los resultados vuelven al bucle de procesamiento principal. En NGINX, dos operaciones (la llamada al sistema read() y sendfile()) se descargan en grupos de subprocesos .

Consejo . Al cambiar la configuración de cualquier sistema operativo o servicio de soporte, cambie una sola configuración a la vez y luego pruebe el rendimiento. Si el cambio causa problemas o no hace que su sitio funcione más rápido, cámbielo nuevamente.

Para obtener más información sobre cómo ajustar un servidor web NGINX, consulte nuestra publicación de blog, Ajuste de NGINX para mejorar el rendimiento .

Consejo 10: Supervisar la actividad en vivo para resolver problemas y cuellos de botella

La clave para un enfoque de alto rendimiento para el desarrollo y la entrega de aplicação es observar de cerca y en tiempo real el rendimiento de su aplicación en el mundo real. Debe poder monitorear la actividad dentro de dispositivos específicos y en toda su infraestructura web.

El monitoreo de la actividad del sitio es mayormente pasivo: le dice qué está sucediendo y le deja a usted la tarea de detectar los problemas y solucionarlos.

El monitoreo puede detectar varios tipos diferentes de problemas. Entre ellos se incluyen:

• Un servidor está caído.
• Un servidor está cojeando y perdiendo conexiones.
• Un servidor sufre una alta proporción de fallas de caché.
• Un servidor no está enviando contenido correcto.

Una herramienta de monitoreo del rendimiento de aplicação globales como New Relic o Dynatrace lo ayuda a monitorear el tiempo de carga de la página desde ubicaciones remotas, mientras que NGINX lo ayuda a monitorear la entrega de la aplicação . Los datos de rendimiento de las aplicação le indican cuándo sus optimizaciones están generando una diferencia real para sus usuarios y cuándo necesita considerar agregar capacidad a su infraestructura para sostener el tráfico.

Para ayudar a identificar y resolver problemas rápidamente, NGINX Plus agrega controles de estado que reconocen las aplicação : transacciones sintéticas que se repiten regularmente y se utilizan para alertarlo sobre problemas. NGINX Plus también cuenta con drenaje de sesiones , que detiene nuevas conexiones mientras se completan las tareas existentes, y una capacidad de inicio lento, lo que permite que un servidor recuperado alcance su velocidad dentro de un grupo con equilibrio de carga. Cuando se utilizan de manera eficaz, los controles de estado permiten identificar problemas antes de que afecten significativamente la experiencia del usuario, mientras que la interrupción de la sesión y el inicio lento permiten reemplazar servidores y garantizar que el proceso no afecte negativamente el rendimiento percibido o el tiempo de actividad. La figura muestra el panel de monitoreo de actividad en vivo NGINX Plus integrado para una infraestructura web con servidores, conexiones TCP y almacenamiento en caché.

Conclusión: Ver una mejora del rendimiento de 10 veces

Las mejoras de rendimiento disponibles para cualquier aplicação web varían enormemente, y las ganancias reales dependen de su presupuesto, el tiempo que pueda invertir y las brechas en su implementación existente. Entonces, ¿cómo podría usted lograr una mejora de 10 veces en el rendimiento de sus propias aplicações?

Para guiarlo sobre el impacto potencial de cada optimización, aquí hay indicadores de las mejoras que pueden lograrse con cada consejo detallado anteriormente, aunque es casi seguro que los resultados variarán:

• Servidor proxy inverso y equilibrio de carga : la falta de equilibrio de carga, o un equilibrio de carga deficiente, puede provocar episodios de rendimiento muy deficiente. Agregar un servidor proxy inverso, como NGINX, puede evitar que las aplicações web se alteren entre la memoria y el disco. El equilibrio de carga puede trasladar el procesamiento desde servidores sobrecargados a los disponibles y facilitar el escalamiento. Estos cambios pueden resultar en una mejora espectacular del rendimiento, con una mejora de 10 veces que se puede lograr fácilmente en comparación con los peores momentos de su implementación actual, y logros menores pero sustanciales disponibles para 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 aplicação , se pueden lograr mejoras de 10 veces en el rendimiento en horas pico almacenando en caché únicamente el contenido dinámico. El almacenamiento en caché de archivos estáticos también puede mejorar el rendimiento en múltiplos de un solo dígito.
• Compresión de datos : el uso de compresión de archivos multimedia, como JPEG para fotos, PNG para gráficos, MPEG-4 para películas y MP3 para archivos de música, puede mejorar enormemente el rendimiento. Una vez que todo esto esté en uso, la compresión de los datos de texto (código y HTML) puede mejorar los tiempos de carga iniciales de la página en un factor de dos.
• Optimización de SSL/TLS : los protocolos de enlace seguros pueden tener un gran impacto en el rendimiento, por lo que optimizarlos puede llevar a una mejora de quizás el doble en la capacidad de respuesta inicial, en particular para sitios con mucho texto. Es probable que la optimización de la transmisión de archivos multimedia bajo SSL/TLS solo produzca pequeñas mejoras en el rendimiento.
• Implementación de HTTP/2 y SPDY : cuando se utilizan con SSL/TLS, es probable que estos protocolos resulten en mejoras incrementales en el rendimiento general del sitio.
• Ajuste del software de servidores web y Linux (como NGINX) : correcciones como la optimización del almacenamiento en búfer, el uso de conexiones keepalive y la descarga de tareas que requieren mucho tiempo a un grupo de subprocesos separado pueden aumentar significativamente el rendimiento; los grupos de subprocesos, por ejemplo, pueden acelerar las tareas que requieren un uso intensivo del disco en casi un orden de magnitud .

Esperamos que pruebes estas técnicas tú mismo. Queremos escuchar el tipo de mejoras en el rendimiento de las aplicação que puedes lograr. ¡Comparte tus resultados en los comentarios a continuación o tuitea tu historia con los hashtags #NGINX y #webperf!

Recursos para estadísticas de Internet

Statista.com – Participación de la economía de Internet en el producto interno bruto de los países del G-20 en 2016

Kissmetrics – Cómo el tiempo de carga afecta a tus resultados finales (infografía)

Econsultancy – Velocidad del sitio: casos prácticos, consejos y herramientas para mejorar tu tasa de conversión