mod_wsgi - ¿Por qué los documentos de Django sugieren un servidor separado para archivos estáticos?
mod_wsgi apache 2.4 windows (5)
En general, es una buena idea colocar contenido estático, por ejemplo, imágenes, archivos CSS y JS, en un servidor diferente y, además, en un dominio / subdominio diferente. Esto permite que el software que sirve a los archivos estáticos sea altamente optimizado y increíblemente rápido (por ejemplo, nginx ).
El otro beneficio principal proviene de la disminución en el tráfico de la red. Si sirve contenido estático desde el mismo dominio que su aplicación dinámica de Django, entonces los navegadores del cliente envían las cookies de su dominio como parte de su solicitud HTTP, incluso para archivos estáticos. Esto es una sobrecarga innecesaria (los archivos estáticos siempre serán estáticos), pero se requiere porque el cliente no puede distinguir la diferencia entre el contenido estático y dinámico. Si, por otro lado, el contenido estático se servía desde un dominio diferente, entonces podría configurarse como un " dominio sin cookies ", minimizando así la sobrecarga de solicitudes.
Desde la página de Django en mod_wsgi :
Recomendamos utilizar un servidor web independiente, es decir, uno que no esté ejecutando Django, para servir medios.
¿Por qué?
Esta es una estrategia común entre los marcos web. La idea aquí es simplemente usar la mejor herramienta para el trabajo de servicio de contenido estático. Apache, Nginx, lighttpd y otros servidores web modernos son extremadamente buenos para servir contenido estático, por lo que si puede configurar fácilmente estos servidores para hacer ese trabajo, tiene varias ventajas:
- Esas peticiones están ardiendo rápido.
- No está ocupando sus procesos de Python de peso pesado haciendo tareas mundanas, por lo que son libres de procesar solicitudes de aplicaciones.
- En el futuro, al tener este proceso separado para manejar el contenido estático, tiene más flexibilidad en cuanto al uso de CDN o la distribución de activos a otros servidores.
Al mover sus medios a un directorio en particular, tiene un tiempo más sencillo para configurar el servidor web para esta tarea.
Las respuestas aquí son ciertamente correctas desde una perspectiva técnica y teórica. Sin embargo, en la práctica, para la gran mayoría de las implementaciones de Django, ni siquiera pensaría en usar servidores separados (es decir, máquinas, virtuales o físicas) para los medios y la aplicación Django. Simplemente no es necesario. Y es una optimización prematura , la "raíz de todo mal".
En su lugar, lo implementaría utilizando un servidor httpd común (Apache, nginx, ...) y lo dejaría ejecutar la aplicación a través de WSGI / FastCGI y también lo dejaría para servir archivos estáticos y multimedia. Esto simplemente funciona. Usted se ahorra muchos problemas, especialmente si considera usar un servidor separado para los medios de usuario.
Si su sitio es lo suficientemente exitoso como para tener problemas de rendimiento, estará encantado de solucionarlo. Y su primer paso podría ser simplemente alquilar un servidor más rápido.
Esto se aplica al menos si sus únicas preocupaciones están relacionadas con el rendimiento. Por razones de seguridad, es posible que tenga que usar servidores separados, tal vez incluso porque su cliente lo exige.
También es bueno para la seguridad. Un enfoque bastante simple es mantener los archivos cargados por el usuario lejos de los archivos del servidor central. Separar permisos de carpeta, etc. Pero sí, grandes ventajas de velocidad.
Los navegadores web modernos a menudo abrirán dos (¿varios?) Sockets cuando descarguen activos desde un único host. De este modo, obtiene index.html que hace referencia a un grupo de imágenes, archivos js, css, etc. Cada archivo adicional se descarga mediante un solo socket de bloqueo.
Si extrae archivos estáticos de un host separado, obtendrá dos sockets adicionales para descargar los archivos, por lo que en producción esto funciona mucho más rápido.
Esta paralelización también le permite ejecutar diferentes motores de servidor (ok, podrían estar en la misma caja, pero aún así solo obtendrá dos sockets) que se especializan en lo que están sirviendo, por ejemplo, nginx para contenido crudo y fastcgi para el django contenido dinámico