Как сделать процесс широким редактируемой переменной (хранилищем) в django? - PullRequest
1 голос
/ 24 августа 2011

Я хочу создать общедоступное хранилище проекта для настроек проекта / приложения.

Чего я хочу достичь: - Каждое приложение имеет свои собственные настройки приложения, сохраненные в БД - При запуске процесса django wsgi все настройки сохраняются в памяти и доступны во всем проекте - Всякий раз, когда вы изменяете любое значение параметрав db есть вызов для восстановления хранилища из db

, поэтому он работает очень близко к кешу, но я не могу использовать механизм кеширования, потому что он сериализует данные.Я также могу использовать memcache для этой цели, но я хочу разработать общее решение (не всегда у вас есть доступ к memcache).

Если у кого-нибудь есть идеи, чтобы решить мою проблему, я был бы очень признателен за то, что поделился.

1 Ответ

0 голосов
/ 24 августа 2011

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

ПРОБЛЕМЫ

  • Архитектурные различия между Django иPHP / другой популярный язык.

    PHP перечитывает и переоценивает все дерево кода при каждом доступе к странице.Это позволяет PHP перечитывать настройки из БД / кэша / чего угодно при каждом запросе.

  • Инициализация

    Многие приложения django инициализируют свои собственные внутренниекэшируйте настройки и параметры и выполняйте проверку этих параметров во время импорта модуля (запуск сервера), а не при каждом запросе.Это означает, что вам все равно потребуется перезапуск сервера при изменении любых настроек для приложений, не поддерживающих db-settings, так почему бы не просто изменить settings.py и перезапустить сервер?

  • Multi-настройки site / Multi-instance и in-memory

    Изменения в памяти строго запрещаются документами Django, поскольку они влияют только на один экземпляр сервера.В случае нескольких сайтов (contrib.sites) только один сайт будет получать обновления общих настроек.В случае экземпляров серверов (ep.io/gondor) любые изменения будут вноситься только в локальный экземпляр, а не в каждый экземпляр, работающий на вашем сайте.Проходите осторожно

ПРОИЗВОДИТЕЛЬНОСТЬ

  • Изменения в памяти

    Изменение значений параметров во время работы сервераdjango docs строго обескуражен по причинам, изложенным выше.Однако с этой опцией производительность не падает.ИСПОЛЬЗУЙТЕ ТОЛЬКО В УСЛОВИЯХ КОНКРЕТНЫХ СПЕЦИАЛЬНЫХ ПРИЛОЖЕНИЙ, СДЕЛАННЫХ ВАМИ И ОДНОМ СЕРВЕРОМ / ИНСТАНЦИЕЙ.

  • Кэш (redis-cache / memcached)

    Thisопция промежуточной скоростиДостаточно быстрый поиск настроек, которые можно легко десериализовать в сложные структуры python - отлично подходит для dict-config.ВАЖНО то, что значения совместно используются Сайтами / Экземплярами безопасно и обновляются атомарно.

  • DB (SLOOOOW)

    Получение одного параметра за разиз БД будет очень очень медленно, если вы не взломаете пул соединений.захват всех настроек за один раз быстрее, но увеличивает передачу дб при каждом отдельном запросе.Настройки синхронизируются между Сайтами / Экземплярами безопасно.Используйте только для 1 или 2 настроек, и было бы разумно использовать.

ЗАКЛЮЧЕНИЕ

Сохранение значений конфигурации в базе данных / кэше / памяти может быть сделано, но у вас естьбыть в курсе предостережений и потенциального снижения производительности.Создание общей замены для settings.py не будет работать, однако создание приложения поддержки, в котором хранятся настройки для других приложений, может оказаться жизнеспособным решением, если другие приложения принимают, что настройки необходимо перезагружать при каждом запросе.

...