Si tienes grandes cantidades de dinero, simplemente puedes irle arrojando hardware a los problemas de escalado. Para el resto de nosotros, sin embargo, el ajuste de rendimiento es una obligación.
Nota Si alguien con monstruosas cantidades de dinero está leyendo este libro, por favor considere una donación sustancial al proyecto Django. Aceptamos diamantes en bruto y lingotes de oro.
Desafortunadamente, el ajuste de rendimiento es más un arte que una ciencia, y es aun más dificil de escribir sobre eso que sobre escalamiento. Si estás pensando seriamente en desplegar una aplicación Django de gran escala, deberás pasar un un buen tiempo aprendiendo como ajustar cada pieza de tu stack.
Las siguientes secciones, sin embargo, presentan algunos consejos específicos para mejorar el rendimiento de Django que hemos descubierto a lo largo de los años.
20.6.1. Cuanta más memoria RAM, mejor
En el momento de escribir este libro, la mejor memoria RAM cuesta unos 200 dólares por gigabyte — lo que es muy poco comparado con el tiempo empleado en ajustar el rendimiento. Compra toda la RAM que puedas, y después compra un poco más.
Los procesadores más rápidos no mejoran tanto el rendimiento. La mayoría de los servidores Web desperdician el 90% de su tiempo esperando I/O del disco. En cuanto empieces a swappear, el rendimiento directamente se muere. Los discos más rápidos pueden ayudar levemente, pero son mucho más caros que la RAM, así que no cuentan.
Si tienes varios servidores, el primer lugar donde poner tu RAM es en el servidor de base de datos. Si puedes, compra suficiente ram como para tener toda tu base de datos en memoria. Esto no es tan difícil. La base de datos de LJWorld.com — que incluye medio millón de artículos desde 1989 — tiene menos de 2 GB.
Después, maximiza la RAM de tu servidor Web. La situación ideal es aquella en la que ningún servidor swapea — nunca. Si llegas a ese punto, debes poder manejar la mayor parte del tráfico normal.
20.6.2. Deshabilita Keep-Alive
Keep-Alive es una característica de HTTP que permite reutilizar la misma
conexión TCP para responder a varias peticiones HTTP. De esta manera se evita
el proceso de creación y destrucción de conexiones.
Esto parece bueno a primera vista, pero puede afectar gravemente al rendimiento de un sitio Django. Si estás sirviendo medios desde un servidor separado, cada usuario que esté navegando tu sitio solo requerirá una página del servidor Django cada diez segundos aproximadamente. Esto deja a los servidores HTTP esperando el siguiente pedido keep-alive, y un servidor HTTP ocioso consume RAM que debería estar usando un servidor activo.
20.6.3. Usa memcached
A pesar de que Django admite varios back-ends de cache diferentes, ninguno de ellos siquiera se acerca a ser tan rápido como memcached. Si tienes un sitio con tráfico alto, ni pierdas tiempo con los otros — ve directamente a memcached.
20.6.4. Usa memcached siempre
Por supuesto, seleccionar memcached no te hace mejor si no lo usas realmente. El Capítulo 13 explica cómo usar el framework de cache de Django, así que úsalo en todas partes que te sea posible. Usar una estrategia agresiva de cache es normalmente lo único que se puede hacer para mantener un sitio funcionando bajo el mayor tráfico.
20.6.5. Únete a la Conversación
Cada pieza del stack de Django — desde Linux a Apache a PostgreSQL o MySQL — tiene una comunidad maravillosa detrás. Si realmente quieres obtener ese último 1% de tus servidores, únete a las comunidades open source que están detrás de tu software y pide ayuda. La mayoría de los miembros de la comunidad del software libre estarán felices de ayudar.
Y también asegúrate de unirte a la comunidad Django. Tus humildes autores son solo dos miembros de un grupo increíblemente activo y creciente de desarrolladores Django. Nuestra comunidad tiene una enorme cantidad de experiencia colectiva para ofrecer.