¿Cómo usar django-compressor detrás del equilibrador de carga?

Question

Tengo dos servidores detrás de un equilibrador de carga. Cada servidor ejecuta un servidor memcached y el archivo de configuración (que es idéntico en ambos servidores) los tiene definidos (en resumen: caché compartido).

Quiero que las rutas a los archivos generados sean idénticas en los servidores para que el cliente no tenga que descargar más de una vez.

Para que esto funcione, necesito entender cómo funciona el compresor django.

• ¿Cuál es el propósito real de la memoria caché en el compresor django?
• ¿El contenido del archivo está almacenado tanto en la memoria caché como en el sistema de archivos?
  • En caso afirmativo, ¿qué sucede primero?
• Espero que esté haciendo las preguntas correctas aquí. Siéntase libre de agregar algunos.

Una secuencia más detallada y mejor construida que this sería muy útil.

Editar

• Desde los servidores de ambas comparten un servidor memcached, debo establecer COMPRESS_CACHE_KEY_FUNCTION = 'compressor.cache.socket_cachekey' (ver develop branch) o ¿Si se usa la misma clave de caché contribuir a mi punto de tener los mismos nombres de archivo?
• De la manera en que lo entiendo, mtime se recopila de los archivos js/css de origen para determinar si pueden haber cambiado y se debe generar un nuevo archivo a partir de ellos. ¿Correcto?
  • Esto probablemente no ocurra en todas y cada una de las cargas. ¿Cuando sucede?

Answer 1

Si usted quiere tener los archivos de caché idénticas usted debe estar seguro de que usted tiene de entrada idéntica en ambos servidores.

usted debe comprobar:

• si el código de {% compress %}...{% endcompress %} es idéntica en ambos servidores (si el despliegue de ambos servidores a la vez que debería ser)
• si todo su css/js archivos son idénticos en ambos servidores (si implementa en ambos servidores a la vez)
• si mtime (modificar el tiempo) de sus archivos .css/.js es idéntico en ambos servidores (su script de implementación puede afectarlos y establecer el nivel actual fecha)

Si se cumplen todos estos requisitos, los archivos generados deben ser idénticos (contenido y nombres).

Puede verificar mtime con el comando "stat" unix.

Las respuestas a sus preguntas:

• Propósito de la memoria caché en django-compresor es reducir lee de sistema de archivos.
• El archivo generado con código combinado se almacena solo en el sistema de archivos.

Editar:

He comprobado que en uno de mis sitios web detrás de un equilibrador de carga. Tengo diferentes nombres de archivo para archivos .css, pero son idénticos para .js.

Para los archivos .css utilizo preprocesador (http://lesscss.org/), por lo que afecta a -mtime.

Editar (después de tema desarrollado):

Lo que está en la memoria caché?

Debido a documentation tiendas django-compresor en el caché de dos cosas diferentes:

• -mtime de los archivos almacenados en caché (revisar cada COMPRESS_MTIME_DELAY segundos)

• completa código generado es decir .:

  < link rel = "stylesheet" href = "http://cdn.inprl.pl/CACHE/css/117f97d818b8.css" type = "text/css">

Debido al uso de la caché después de django-compresor reduce el número de lecturas al sistema de ficheros a 0. Esto es esencial para la velocidad de la página, ya que la lectura de la memoria es cientos de veces más rápido que la lectura del sistema de archivos. También el sistema de archivos es a menudo un cuello de botella.

cómo se almacena en la memoria caché?

django-compresa es el almacenamiento de código en la memoria caché utilizando la clave generada. Clave se genera a partir de:

• código en {% compress %}...{% endcompress %}
• -mtime de archivos mencionados en {% compress %}...{% endcompress %}

Así que estos deben ser los mismos en todos los servidores, si usted quiere tener respuestas coherentes.

PS.

por confirmar limitaciones (como mtime) en el servidor y la información post aquí si coinciden.

estaré arreglando el mismo problema en mi sitio probablemente la próxima semana, voy a publicar más detalles a continuación.

Answer 2

En la rama de desarrollo hay una nueva opción para cambiar el método de hash de css. https://github.com/jezdez/django_compressor

Ver line 61 in filters/css_default.py

Los ajustes que estoy usando:

COMPRESS_ENABLED = True 
COMPRESS_OFFLINE = False 
COMPRESS_STORAGE = 'compressor.storage.GzipCompressorFileStorage' 
COMPRESS_CSS_HASHING_METHOD = 'hash' # not using mtime since it differs between servers. 

No hay ninguna opción como esta para los archivos js ya que su clave hash no se genera utilizando -mtime de todos modos.

Esto funciona perfectamente detrás de mi loadbalancer.

Cuando esto se escribe, la siguiente es la última Aprobar de la rama de desarrollo: https://github.com/jezdez/django_compressor/commit/d48bc5f45d5a55b0f826eb605ccf09a6bf33fcb9

Answer 3

Lo que debe hacer es poner todos los archivos comprimidos en un almacenamiento en las afueras de las instancias de computación que están detrás del equilibrador de carga. Por ejemplo, use Amazon S3 para almacenar todos sus archivos en otro subdominio que el resto de su aplicación.

Así que http://myapp.com apunta a su equilibrador de carga y http://s3.myapp.com apunta a su almacenamiento, como Amazon S3. No tendrá que preocuparse por el almacenamiento de múltiples versiones diferentes en instancias diferentes.

Aquí puede encontrar un complete guide of how to setup Amazon S3, Gzip Compression and django-compressor con Django.