¿Qué se necesita para escalar Django (marco web)?

Aquí hay una breve lista que ayudará:

* use NGINX (o un CDN) para servir activos estáticos comprimidos
* use NGINX para hacer un round robin en varios servidores web que ejecutan Django + Gunicorn
* asegúrese de que sus archivos como favicon, robots.txt, existan y no estén en 404
* use los índices de la base de datos con prudencia para consultas complejas (evite escaneos de tabla completa)
* caché resultados de consultas complicadas en Memcache / Redis
* use Redis para clasificaciones / caché / pub / sub (es realmente rápido)
* minimizar todo el front-end
* use Celery (o similar) para descargar las solicitudes aplicables a las colas asíncronas
* use django-debug-toolbar para encontrar cuellos de botella
* almacenar sesiones en Redis, no una tabla SQL
* considere configurar Gunicorn para usar Gevent en lugar de hilos (no siempre es posible)
* configure los tiempos de espera de NGINX correctamente, no permita que las solicitudes se cuelguen por más de unos segundos

En mi opinión, la decisión de diseño más importante que puede tomar desde el principio: intente crear aplicaciones de una sola página del lado del cliente utilizando enrutadores backbone.js (o algo similar). Esto evitará recargas de página completa (sin pasar por la generación de plantillas / consultas ORM de Django) y obligará a realizar mucho trabajo en el navegador del cliente. Esto puede requerir un RESTAPI, y si es así, use Tastypie o DjangoRestFramework.

Cada aplicación se escala de manera diferente. Realmente depende de cómo crezca la aplicación, cuáles son las diferentes entradas (auth / unauth, locales, etc.).

Por ejemplo, si tiene un sitio con mucha lectura, puede obtener un largo camino con el almacenamiento en caché. Incluso puede almacenar en caché en la capa Nginx.

Si está haciendo muchas transacciones de DB, encontrará que sqlite3 no le servirá bien. Probablemente quiera usar Postgres o MySQL (con el que se sienta más cómodo).

Si puede separar su tráfico de lectura del tráfico de escritura, eso lo ayudará, ya que puede almacenar en caché agresivamente el tráfico de lectura.

Nada de esto es exclusivo de Django. Django es flexible y le ofrece opciones, pero las opciones no son tan diferentes de otros marcos.

Entonces, la verdadera respuesta al escalado es esta: prueba de esfuerzo en tu sitio. Averigüe qué hace que se rompa y qué se necesitaría para arreglarlo. Si se puede aliviar ese estrés simplemente haciendo múltiples instancias (por ejemplo, iniciando más cuadros frontales de Django), entonces tiene un sitio relativamente escalable. Si necesita volver a diseñar cosas (por ejemplo, agregar caché, cambiar la base de datos subyacente, escribir lógica especial), su sitio es menos escalable.

Entonces, si estuviera en su posición, trataría de reproducir mucho tráfico al mismo tiempo, y luego gradualmente marcaría la concurrencia. En algún momento (N consultas / segundo) tu sitio se romperá (es inevitable, te estás DDOS). Luego, averigua qué cambios necesitas hacer para ir a 2N o incluso a 10N. Desea llegar a un punto en el que pueda ver crecer el tráfico y responder al crecimiento agregando más servidores. Por ejemplo, si una sola caja puede servir a 10qps y necesita 20qps, cree una arquitectura que pueda hacer esto, simplemente doblando las cajas.

Sin duda, esto es simplificar demasiado las cosas, pero una vez que lo hayas hecho varias veces, te acostumbrarás. No siempre será “fácil”, pero debería ser capaz de avanzar.

Aquí hay algunas ideas que http://www.hackerearth.com implementó para escalar su sitio web basado en Django que está alojado en AWS.
Aplicación Scaling Python / Django con Apache y mod_wsgi
Escalando la base de datos con Django y HAProxy
El robusto servidor en tiempo real

Hay muchos enfoques para escalar dependiendo de lo que necesite. Para un principiante y una visión general del campo, siempre recomendaría mirar Disqus y algunos de sus recursos. Por ejemplo:
Escalando Django a 8 mil millones de páginas vistas
PyCon 2011 Scaling Disqus