Как использовать django-компрессор за балансировщиком нагрузки? - PullRequest
Новая
       13

Как использовать django-компрессор за балансировщиком нагрузки?

11 голосов
/ 30 августа 2011

У меня есть два сервера за балансировщиком нагрузки.На каждом сервере запущен сервер memcached, и в файле настроек (который идентичен на обоих серверах) определены оба (короче: общий кеш).

Я хочу, чтобы пути к сгенерированным файлам были идентичны насерверы, так что клиент не должен загружать более одного раза.

Чтобы получить эту работу, мне нужно понять, как работает компрессор django.

  • Какова реальная целькеш в компрессоре django?
  • Содержимое файла хранится как в кеше, так и в файловой системе?
    • Если так, что произойдет первым?
  • Надеюсь, я задаю правильные вопросы здесь.Не стесняйтесь добавлять некоторые.

Более детальная и лучше построенная последовательность, чем , эта была бы очень полезна.

Редактировать

  • Поскольку оба сервера совместно используют сервер memcached, должен ли я установить COMPRESS_CACHE_KEY_FUNCTION = 'compressor.cache.socket_cachekey' (см. развернуть ветку ) или использование одного и того же ключа кэша способствует тому, что у меня одинаковые имена файлов?
  • Как я понимаю, mtime собирается из исходных файлов js / css, чтобы определить, могли ли они измениться, и из них должен быть создан новый файл.Правильный?
    • Это, вероятно, не происходит при каждой загрузке.Когда это происходит?

Ответы [ 3 ]

12 голосов
/ 05 сентября 2011

В ветке разработки появилась новая опция для изменения метода хэширования css. https://github.com/jezdez/django_compressor

См. строка 61 в filters / css_default.py

Используемые настройки: 

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

Нет такой опции для js-файлов, поскольку их хеш-ключ никогда не генерируется с помощью mtime.

Это отлично работает за моим loadbalancer.

Когда это написано, последним коммитом в ветке разработки является: https://github.com/jezdez/django_compressor/commit/d48bc5f45d5a55b0f826eb605ccf09a6bf33fcb9

4 голосов
/ 30 августа 2011

Если вы хотите иметь идентичные файлы кеша, вы должны быть уверены, что у вас одинаковый ввод на обоих серверах.

Вам следует проверить:

  • , есликод в {% compress %}...{% endcompress %} идентичен на обоих серверах (если вы развертываете на обоих серверах сразу, это должно быть)
  • , если все ваши файлы .css / .js идентичны на обоих серверах (если вы развертываете на обоих серверахсразу должно быть)
  • если mtime (время изменения) ваших файлов .css / .js одинаково на обоих серверах (ваш скрипт развертывания может повлиять на них и установить текущую дату)

Если все эти требования выполнены, сгенерированные файлы должны быть идентичны (содержимое и имена).

Вы можете проверить mtime с помощью команды stat "unix.

Ответы на ваши вопросы:

  • Назначение кэша в django-компрессоре - уменьшить чтение из файловой системы.
  • Сгенерированный файл с комбинированным кодом хранится только в файловой системе.

Редактировать:

У меня есть чвзломал его на одном из моих сайтов за балансировщиком нагрузки.У меня есть разные имена файлов .css, но они идентичны для .js.

. Для файлов .css я использую препроцессор (http://lesscss.org/),, поэтому он влияет на mtime.

Edit(после разработки темы):

Что находится в кеше?

Из-за документации Джанго-компрессор хранит в кеше дваразные вещи:

  • mtime кэшированных файлов (перепроверяется каждые COMPRESS_MTIME_DELAY секунд)

  • полный сгенерированный код, т. е .:

Из-за последующего использования кэша django-compress уменьшает количество чтений в файловой системе до 0. Это важно для скорости страниц, поскольку чтение из памяти в сотни раз быстрее, чем чтение из файловой системы.Также файловая система очень часто является узким местом.

Как она хранится в кеше?

django-compress хранит код в кеше, используя сгенерированный ключ.Ключ генерируется из:

  • кода в {% compress %}...{% endcompress %}
  • m файлов, упомянутых в {% compress %}...{% endcompress %}

Так что они должны быть одинаковыми на всехсервера, если вы хотите получать последовательные ответы.

PS.

Пожалуйста, проверьте ограничения (например, mtime) на вашем сервере и опубликуйте здесь информацию, если они совпадают.

Я исправлю эту проблему на моем сайте, вероятно, на следующей неделе, тогда я опубликую дополнительные сведения.

0 голосов
/ 06 мая 2015

Что вам нужно сделать, это поместить все ваши сжатые файлы в хранилище вне ваших вычислительных экземпляров, которые находятся за балансировщиком нагрузки. Например, используйте Amazon S3 для хранения всех ваших файлов на другом поддомене, чем остальная часть вашего приложения.

Таким образом, http://myapp.com указывает на ваш балансировщик нагрузки, а http://s3.myapp.com указывает на ваше хранилище, такое как Amazon S3. Вам не придется беспокоиться о хранении нескольких разных версий в разных экземплярах.

Здесь вы можете найти полное руководство по настройке Amazon S3, сжатия Gzip и django-компрессора с помощью Django.

...