Django1.3 проблемы кэширования нескольких рабочих-оружейников - PullRequest
Новая
       15

Django1.3 проблемы кэширования нескольких рабочих-оружейников

3 голосов
/ 21 июня 2011

У меня странные проблемы с кешированием в версии django 1.3.Возможно, у меня что-то неправильно настроено, но я не уверен, что.

Хорошим примером является django-avatar, который использует кэширование, и многие используют его.Даже если у меня нет определенного бэкэнда кеша, аватар кажется кэшированным, что само по себе было бы нормально, но он продолжает переключаться между последними кэшированными значениями.Пример: я загружаю новый аватар, теперь примерно в 50% запросов он покажет мне новый, 50% - старый.Если я удаляю старый, я все равно получаю его на сайте в 50% случаев.Единственный способ исправить это - отключить кэширование аватара, установив его на одну секунду.

Сначала я подумал, что это потому, что я использовал django.core.cache.backends.locmem.LocMemCache, который раньше никогда не использовал, но это даже происходит, когда я вообще не настраиваю бэкэнд кеша.

Я обнаружил одну похожую ошибку: Ошибка кэширования Django .. даже если кэширование отключено

, но мои страницы отображаются нормально, это теги-шаблоны (на данный момент), которые вызываютпроблемы в моей настройке.

Я использую django 1.3, postgres, nginx, gunicorn 0.12.0, greenlet == 0.3.1, eventlet == 0.9.16

Я только что сделал ещепроверил и понял, что это происходит только тогда, когда я запускаю gunicorn, используя файл конфигурации.Если я начну с ./manage.py run_gunicorn, то все в порядке.Запуск «gunicorn_django -c deploy / gunicorn.conf.py» вызывает проблемы.

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

Обновление: выполняется ./manage.py run_gunicorn -w 4 также вызывает те же проблемы.Поэтому я почти уверен, что проблемы вызваны несколькими работниками, и каждый работник кэширует значения по отдельности.

Моя конфигурация: 

import os
import socket
import sys

PORT = 8000
PROC_NAME = 'myapp_gunicorn'
LOGFILE_NAME = 'gunicorn.log'
TIMEOUT = 3600
IP = '127.0.0.1'
DEPLOYMENT_ROOT = os.path.dirname(os.path.abspath(__file__))
SITE_ROOT = os.path.abspath(os.path.sep.join([DEPLOYMENT_ROOT, '..']))
CPU_CORES = os.sysconf("SC_NPROCESSORS_ONLN")
sys.path.insert(0, os.path.join(SITE_ROOT, "apps"))
bind = '%s:%s' % (IP, PORT)
logfile = os.path.sep.join([DEPLOYMENT_ROOT, 'logs', LOGFILE_NAME])
proc_name = PROC_NAME
timeout = TIMEOUT
worker_class = 'eventlet'
workers = 2 * CPU_CORES + 1

Я также пробовал без использования 'eventlet', но получил те же ошибки.

Спасибо за любую помощь.

1 Ответ

6 голосов
/ 21 июня 2011

Скорее всего, по умолчанию используется кэш-память в памяти, что означает, что у каждого работника есть своя версия кеша в своем собственном пространстве памяти.Если вы нажмете на поток 1, вы получите другой кэш, чем поток 3. Nginx распределяет нагрузку между каждым потоком, скорее всего, с помощью циклического распределения, поэтому вы меняете потоки при каждом обращении.Что объясняет ваши дурацкие результаты.

Когда вы управляете manage.py run_gunicorn, он, скорее всего, запускает однопоточный, и, следовательно, только один кеш, и поэтому вы не видите те же результаты.1004 * Использование memcached или чего-то подобного - путь.

...