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

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

Python es famoso por ser fácil y divertido de usar, por hacer más sencillo el desarrollo de software y por tener un rendimiento en tiempo de ejecución que se dice supera a otros lenguajes de programación. (Aunque la última versión de PHP, PHP 7, puede darle competencia a Python).

Todo el mundo quiere que su sitio web y su aplicação funcionen más rápido. Además, cualquier sitio web con tráfico creciente o picos de tráfico pronunciados es vulnerable a problemas de rendimiento y tiempos de inactividad, que a menudo ocurren en los peores momentos, es decir, los de mayor actividad. Además, casi todos los sitios web sufren problemas de rendimiento y tiempos de inactividad, ya sea porque el volumen de tráfico crece de manera constante o porque experimentan picos bruscos de uso.

Ahí es donde entran en juego NGINX y NGINX Plus. Mejoran el rendimiento del sitio web de tres maneras diferentes:

1. Como servidor web , NGINX se desarrolló originalmente para resolver el problema C10K , es decir, para soportar fácilmente 10 000 o más conexiones simultáneas. Usar NGINX como servidor web para su aplicación Python hace que su sitio web sea más rápido, incluso con niveles bajos de tráfico. Cuando tienes miles de usuarios, es prácticamente seguro que obtendrás un rendimiento mucho mayor, menos fallos y menos tiempos de inactividad. También puede realizar almacenamiento en caché de archivos estático o microcaching en su servidor web NGINX, aunque ambos funcionan mejor cuando se ejecutan en un servidor proxy inverso NGINX separado (consulte el siguiente párrafo).
2. Como servidor proxy inverso : puede “instalar NGINX” como servidor proxy inverso frente a su configuración actual de servidor de aplicação . NGINX se conecta a la Web y pasa solicitudes a su servidor de aplicação . Este “truco extraño” hace que su sitio web funcione más rápido, reduce el tiempo de inactividad, consume menos recursos del servidor y mejora la seguridad. También puede almacenar en caché archivos estáticos en el servidor proxy inverso (muy eficiente), agregar microcaching de contenido dinámico para reducir la carga en la aplicação en sí y más.
3. Como equilibrador de carga para múltiples servidores de aplicação : comience implementando un servidor proxy inverso. Luego, escale horizontalmente ejecutando múltiples servidores de aplicação en paralelo y usando NGINX o NGINX Plus para equilibrar la carga del tráfico entre ellos. Con este tipo de implementación, puede escalar fácilmente el rendimiento de su sitio web de acuerdo con los requisitos de tráfico, aumentando la confiabilidad y el tiempo de actividad. Si necesita que una sesión de usuario determinada permanezca en el mismo servidor, configure el balanceador de carga para admitir la persistencia de la sesión .

NGINX y NGINX Plus ofrecen ventajas independientemente de si los utiliza como servidor web para su aplicación Python, como servidor proxy inverso, como equilibrador de carga o para los tres propósitos.

En este primer artículo de una serie de dos partes, describimos cinco consejos para mejorar el rendimiento de sus aplicaciones Python, incluido el uso de NGINX y NGINX Plus como servidor web, cómo implementar el almacenamiento en caché de archivos estáticos y el microalmacenamiento en caché de archivos generados por la aplicação. En la Parte 2 , describiremos cómo utilizar NGINX y NGINX Plus como un servidor proxy inverso y como un equilibrador de carga para múltiples servidores de aplicação .

Consejo 1: Encuentra cuellos de botella en el rendimiento de Python

Hay dos condiciones muy diferentes en las que el rendimiento de su aplicação Python es importante: primero, con una cantidad “razonable” de usuarios todos los días; y segundo, bajo cargas pesadas. A muchos propietarios de sitios web les preocupa demasiado poco el rendimiento bajo cargas ligeras cuando, en nuestra humilde opinión, deberían estar esforzándose cada décima de segundo en tiempo de respuesta. Recortar milisegundos de los tiempos de respuesta es un trabajo difícil e ingrato, pero hace que los usuarios estén más contentos y los resultados comerciales sean mejores.

Sin embargo, esta entrada del blog, y la Parte 2 que la acompaña, se centran en el escenario que preocupa a todos: los problemas de rendimiento que ocurren cuando un sitio se sobrecarga, como grandes ralentizaciones y fallos del rendimiento. Además, muchos ataques de piratas informáticos imitan los efectos de aumentos repentinos en el número de usuarios, y mejorar el rendimiento del sitio suele ser también un paso importante para abordar los ataques .

Con un sistema que asigna una cierta cantidad de memoria por usuario, como Apache HTTP Server, agregar usuarios hace que la memoria física se sobrecargue a medida que se suman más y más usuarios. El servidor comienza a intercambiar con el disco, el rendimiento se desploma y se producen fallas y un rendimiento deficiente. Migrar a NGINX, como se describe en esta publicación del blog, ayuda a resolver este problema.

Python es particularmente propenso a problemas de rendimiento relacionados con la memoria, porque generalmente utiliza más memoria para realizar sus tareas que otros lenguajes de programación (y, como resultado, las ejecuta más rápido). Por lo tanto, en igualdad de condiciones, su aplicación basada en Python puede “fallar” ante una carga de usuarios menor que una aplicación escrita en otro lenguaje.

Optimizar su aplicación puede ayudar un poco, pero generalmente no es la mejor ni la forma más rápida de resolver los problemas de rendimiento del sitio relacionados con el tráfico. Los pasos de esta publicación de blog y la Parte 2 que la acompaña son las mejores y más rápidas formas de abordar los problemas de rendimiento relacionados con el tráfico. Luego, después de abordar los pasos que se indican aquí, no dude en volver atrás y mejorar su aplicación o reescribirla para utilizar una arquitectura de microservicios .

Consejo 2: Elija una implementación de servidor único o de varios servidores

Los sitios web pequeños funcionan bien cuando se implementan en un solo servidor. Los sitios web grandes requieren varios servidores. Pero si usted se encuentra en una zona gris intermedia, o si su sitio está creciendo de ser un sitio pequeño a uno grande, tiene que tomar algunas decisiones interesantes.

Si tiene una implementación de un solo servidor, corre un riesgo significativo si experimenta picos de tráfico o un rápido crecimiento general del tráfico. Su escalabilidad es limitada, con posibles soluciones que incluyen mejorar su aplicación, cambiar su servidor web a NGINX, obtener un servidor más grande y más rápido, o descargar almacenamiento a una red de distribución de contenido (CDN). Cada una de estas opciones requiere tiempo para implementarse, tiene un costo y corre el riesgo de introducir errores o problemas en la implementación.

Además, con una implementación de un solo servidor, su sitio, por definición, tiene un único punto de falla, y muchos de los problemas que pueden dejar su sitio fuera de línea no tienen soluciones rápidas o simples.

Si cambia su servidor a NGINX en una implementación de servidor único, puede elegir libremente entre NGINX Open Source y NGINX Plus. NGINX Plus incluye soporte de nivel empresarial y funciones adicionales . Algunas de las características adicionales, como el monitoreo de actividad en vivo , son relevantes para una implementación de un solo servidor, y otras, como el equilibrio de carga y la persistencia de sesión , entran en juego si usa NGINX Plus como un servidor proxy inverso en una implementación de múltiples servidores.

Todo ello considerado, a menos que esté seguro de que su sitio va a permanecer pequeño durante mucho tiempo y el tiempo de inactividad no sea una preocupación importante, la implementación de un solo servidor implica ciertos riesgos. La implementación de múltiples servidores es casi arbitrariamente escalable: se pueden eliminar los puntos únicos de falla y el rendimiento puede ser el que usted elija, con la capacidad de agregar capacidad rápidamente.

Consejo 3: Cambie su servidor web a NGINX

En los primeros días de la Web, el nombre “Apache” era sinónimo de “servidor web”. Pero NGINX se desarrolló a principios de la década de 2000 y está ganando popularidad de manera constante; ya es el servidor web n.° 1 en los 1000, 10 000, 100 000 y [ngx_snippet name='proportion-top-sites'] del mundo.

NGINX fue desarrollado para resolver el problema C10K , es decir, manejar más de 10 000 conexiones simultáneas dentro de un presupuesto de memoria determinado. Otros servidores web necesitan una gran cantidad de memoria para cada conexión, por lo que se quedan sin memoria física y se vuelven más lentos o se bloquean cuando miles de usuarios quieren acceder a un sitio al mismo tiempo. NGINX maneja cada solicitud por separado y se escala elegantemente para muchos más usuarios. (También es excelente para fines adicionales, como describiremos a continuación).

A continuación se muestra una descripción general de alto nivel de la arquitectura de NGINX.

En el diagrama, un servidor de aplicação Python se integra en el bloque Servidor de aplicação del backend y se muestra al ser accedido por FastCGI. NGINX no sabe cómo ejecutar Python, por lo que necesita una puerta de enlace a un entorno que sí lo sepa. FastCGI es una interfaz ampliamente utilizada para PHP, Python y otros lenguajes.

Sin embargo, una opción más popular para la comunicación entre Python y NGINX es la Interfaz de Puerta de Enlace de Servidor Web (WSGI). WSGI funciona en entornos multiproceso y multihilo, por lo que se adapta bien a todas las opciones de implementación mencionadas en esta publicación del blog.

Si migra a NGINX como su servidor web, hay mucho soporte disponible para los pasos involucrados:

• Configuración de gunicorn – “Unicornio verde”, un popular servidor WSGI, para su uso con NGINX.
• Configuración de uWSGI : otro servidor WSGI popular, para usar con NGINX. uWSGI incluye soporte directo para NGINX.
• Usando uWSGI, NGINX y Django – Un popular marco web de Python.

Este fragmento muestra cómo se puede configurar NGINX para su uso con uWSGI ; en este caso, un proyecto que utiliza el marco de Python Django:

http { # ...
upstream django {
servidor 127.0.0.1:29000;
}

servidor {
list 80;
nombre_servidor myapp.example.com;

raíz /var/www/myapp/html;

ubicación / {
índice index.html;
}

ubicación /estática/ {
alias /var/django/projects/myapp/estática/;
}

ubicación /principal {
incluir /etc/nginx/uwsgi_params;
uwsgi_pass django;

uwsgi_param Host $host;
uwsgi_param X-Real-IP $dirección_remota;
uwsgi_param X-Reenviado-Para $dirección_proxy_x_reenviado_para; uwsgi_param Proto-reenviado-X $http_x_forwarded_proto;
}
}
}

Consejo 4: Implementar el almacenamiento en caché de archivos estáticos

El almacenamiento en caché de contenido estático implica mantener una copia de los archivos que no cambian con mucha frecuencia (lo que puede significar cada pocas horas o nunca) en una ubicación distinta al servidor de aplicação . Un ejemplo típico de contenido estático es una imagen JPEG que se muestra como parte de una página web.

El almacenamiento en caché de archivos estáticos es una forma común de mejorar el rendimiento de las aplicação y, en realidad, ocurre en varios niveles:

• En el navegador del usuario
• En proveedores de Internet en varios niveles: desde la red interna de una empresa hasta un proveedor de servicios de Internet (ISP)
• En un servidor web, como describiremos aquí

La implementación del almacenamiento en caché de archivos estáticos en el servidor web tiene dos beneficios:

• Entrega más rápida al usuario : NGINX está optimizado para el almacenamiento en caché de archivos estáticos y ejecuta solicitudes de contenido estático mucho más rápido que un servidor de aplicação .
• Carga reducida en el servidor de aplicação : el servidor de aplicação ni siquiera ve solicitudes de archivos estáticos almacenados en caché, porque el servidor web las satisface.

El almacenamiento en caché de archivos estáticos funciona bien con una implementación de un solo servidor, pero el hardware subyacente aún es compartido por el servidor web y el servidor de aplicação . Si el servidor web tiene el hardware ocupado recuperando un archivo en caché, incluso si lo hace de manera muy eficiente, esos recursos de hardware no están disponibles para la aplicação, lo que posiblemente la ralentice hasta cierto punto.

Para admitir el almacenamiento en caché del navegador, configure correctamente los encabezados HTTP para los archivos estáticos. Tenga en cuenta el encabezado HTTP Cache-Control (y su configuración de edad máxima en particular), el encabezado Expires y las etiquetas Entity . Para obtener una buena introducción al tema, consulte Uso de NGINX y NGINX Plus como puerta de enlace de aplicação con uWSGI y Django en la Guía de administración de NGINX Plus.

El siguiente código configura NGINX para almacenar en caché archivos estáticos, incluidos archivos JPEG, GIF, archivos PNG, archivos de video MP4, archivos de Powerpoint y muchos otros. Reemplace www.example.com con la URL de su servidor web.

servidor { # sustituye la URL de tu servidor web por "www.ejemplo.com"
nombre_servidor www.ejemplo.com;
raíz /var/www/ejemplo.com/htdocs;
índice index.php;
registro_acceso /var/log/nginx/ejemplo.com.access.log;
registro_error /var/log/nginx/ejemplo.com.error.log;

ubicación / {
try_files $uri $uri/ /index.php?$args;
}

ubicación ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# sustituye el socket, o la dirección y el puerto, de tu servidor Python
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000; } 

ubicación ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
caduca máx.;
registro_no_encontrado_desactivado;
registro_de_acceso_desactivado;
}
}

Consejo 5: Implementar microcaching

El microcaching aprovecha una enorme oportunidad para mejorar el rendimiento en servidores de aplicação que ejecutan Python, PHP y otros lenguajes. Para fines de almacenamiento en caché, existen tres tipos de páginas web:

• Archivos estáticos : se pueden almacenar en caché, como se describe en el Consejo 4 .
• Páginas generadas por la aplicação, no personalizadas : normalmente no tiene sentido almacenarlas en caché, ya que deben estar actualizadas. Un ejemplo es una página enviada a un usuario de comercio electrónico que no ha iniciado sesión (ver el siguiente punto): los productos disponibles, los productos similares recomendados, etc., pueden cambiar constantemente, por lo que es importante proporcionar una página nueva. Sin embargo, si aparece otro usuario, digamos una décima de segundo después, podría estar bien mostrarle la misma página que al usuario anterior.
• Páginas personalizadas generadas por la aplicação : no es útil almacenarlas en caché porque son específicas del usuario y es poco probable que el mismo usuario vea la misma página personalizada dos veces. Un ejemplo es una página de comercio electrónico para un usuario que ha iniciado sesión; la misma página no se puede mostrar a otros usuarios.

El microalmacenamiento en caché es útil para el segundo tipo de página descrito anteriormente: páginas generadas por la aplicação y no personalizadas. “Micro” se refiere a un período de tiempo breve. Cuando su sitio genera la misma página varias veces por segundo, es posible que no afecte mucho la frescura de la página si la almacena en caché durante un segundo. Sin embargo, este breve período de almacenamiento en caché puede descargar enormemente el servidor de aplicação , especialmente durante picos de tráfico. En lugar de generar 10, 20 o 100 páginas (con el mismo contenido) durante el período de espera de la caché, genera una página determinada solo una vez, luego la página se almacena en caché y se sirve a muchos usuarios desde la caché.

El efecto es algo milagroso. Un servidor que es lento cuando procesa decenas de solicitudes por segundo se vuelve bastante rápido cuando procesa exactamente una. (Además, por supuesto, cualquier página personalizada). Nuestro propio Owen Garrett tiene una publicación de blog que explica los beneficios del microcaching , con código de configuración. El cambio principal, configurar un caché proxy con un tiempo de espera de un segundo, requiere solo unas pocas líneas de código de configuración.

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;
# ...
}

Para obtener más ejemplos de configuración, consulte el blog de Tyler Hicks‑Wright sobre Python y uWSGI con NGINX .

CONCLUSIÓN

En la Parte I, analizamos soluciones para aumentar el rendimiento de una implementación de Python de un solo servidor, así como el almacenamiento en caché, que se puede implementar en una implementación de un solo servidor o se puede ejecutar en un servidor proxy inverso o en un servidor de almacenamiento en caché separado. (El almacenamiento en caché funciona mejor en un servidor separado). La siguiente parte, Parte 2 , describe soluciones de rendimiento que requieren dos o más servidores.

Si desea explorar las funciones avanzadas de NGINX Plus para su aplicação, como soporte, monitoreo de actividad en vivo y reconfiguración sobre la marcha, comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .