Django-compressor: Ошибка автономного сжатия

Созданный на 25 сент. 2013 · 6Комментарии · Источник: django-compressor/django-compressor

Я потратил неделю на отладку этого (две разные недели) и очень расстроен. Кажется, я прочитал почти все статьи/посты в блогах/выпусках и не знаю, что делать. У меня есть и промежуточный сервер, и рабочий сервер (каждый с отдельными корзинами s3), и это работает на промежуточной стадии, но не в рабочей среде, хотя серверы (на Heroku) и корзины идентичны.

Я сделал так, чтобы теги сжатия отображались только в дочернем шаблоне. Я удалил все теги шаблона из тегов сжатия (например, if/else). Это означает, что у меня больше тегов сжатия, поэтому операторы if/else могут быть вне тегов сжатия.

У кого-нибудь есть работающее автономное сжатие, настроенное в производстве, где-нибудь посмотреть? При сжатии offline=False на сервер ложится значительная дополнительная нагрузка, часто дополнительная задержка на 300-500 мс, что, очевидно, того не стоит и сводит на нет всю цель этого пакета.

Мне действительно не помешала бы некоторая помощь, но в основном я понятия не имею, что делать на этом этапе, потому что это та же проблема, о которой вы можете прочитать с сотнями людей в списке проблем здесь, в сообщениях блога в других местах, и кажется, что нет повторяемого решения. предлагается - что является огромной проблемой для чего-то, что имеет решающее значение для производительности и, вероятно, требуется для любого развертывания Django.

deployment

Источник

dasloss

Самый полезный комментарий

В последние дни я был занят решением той же проблемы, и вот что было исправлено, если кому-то это поможет.

В одном из шаблонов, где проблема воспроизводилась, я использовал context. При автономном сжатии нет доступа к контексту, поэтому ключ, сгенерированный при автономном сжатии, и ключ из цикла ответа, очевидно, будут отличаться.

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

Надеюсь, эта информация кому-нибудь поможет.

jordanjambazov 18 июл. 2016

👍2

Все 6 Комментарий

Тут то же самое. Кажется, COMPRESS_OFFLINE django_compressor создает больше проблем, чем решает. Я не могу заставить его работать, потому что получаю такие сообщения:

OfflineGenerationError: You have offline compression enabled but key "%s" 
is missing from offline manifest. You may need to run "python manage.py compress".

shalakhin 18 окт. 2013

То же самое :/

Не удается заставить работать автономное сжатие. Продолжайте получать OfflineGenerationError.

neara 19 янв. 2014

Поэтому я убедился, что запускаю следующее во время каждого развертывания на всех веб-серверах.

python manage.py сжать --force
python manage.py собирать статический

Это должно обновить файл manifest.json. Также я удостоверяюсь, что имя файла манифеста отличается при каждом нажатии. Например, добавить номер версии. manifest_%s.json
Я использую последний хэш-идентификатор git commit для плагина %s. Таким образом, во время развертывания он выполняет git pull, compress, collectstatic, создавая новые минимизированные/агрегированные css/js с новым файлом manifest.json.
И затем я перезапускаю апач. Так что все должно быть гладко.

Также я убедился, что collectstatic не вызывает --clear для удаления старых static/* media.

Есть смысл?