Джанго 1.3 протоколирования для отладки в среде разработки

Question

Я использую рамки протоколирования в Джанго 1.3, как описано здесь https://docs.djangoproject.com/en/1.3/topics/logging/

В моем файле settings.py для моей DEV среды, я в основном имею пользовательский форматтер, регистратор и обработчик чтобы я мог записывать отладочный вывод в файл.

Итак, теперь в моем коде у меня есть инструкции logger.debug() повсюду.

Мои вопросы:

1. Когда я разворачивать в производстве делают заявления logger.debug имеют любые (signficant) влияет на производительность? (т. е. мне нужно все это вытащить?)
2. Каков наилучший способ изменить файл settings.py, чтобы он больше не захватывал файл? В настоящее время я просто изменяя обработчик django.utils.log.NullHandler

Answer 1

1. Все эти отладочные будет иметь очень незначительное влияние на общую производительность - проблемы в производительности будет отображаться, если вы пытаясь записать все эти сообщения журнала в файл где-то при большой нагрузке. Написание большого количества файлов в файлы может быть интенсивным CPU и IO. Это не будет проблемой, если у вас низкий уровень вашего журнала (WARNING), поскольку это не должно приводить к большому количеству сообщений. Сохранение отладочных инструкций там будет полезно в будущем, когда вы захотите отладить/улучшить этот код.
2. Использование нулевого обработчика, если оно прекрасное, если вы не знаете, какие сообщения были записаны в файл или выведены. В качестве альтернативы вы можете отключить уровень ведения журнала до ПРЕДУПРЕЖДЕНИЯ, чтобы пройти только важные сообщения.

Answer 2

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

С точки зрения настроек производства/развития, у меня всегда есть это на дне моего settings.py:

try: 
    from local_settings import * 
except ImportError: 
    pass 

Тогда у меня есть local_settings.py, что я не добавить в систему управления версиями и может переопределить настройки. Таким образом, вы можете легко настроить отдельные настройки производства/dev.

Я принял идею от this blog и использовал ее для многих проектов сейчас - очень удобно. Блог расширяет ссылку и показывает, как вы можете добавить параметры разработки и производства в исходный элемент управления, а затем использовать local_settings для включения одного или другого.

Answer 3

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

В производстве мы используем sentry для регистрации уровня приложения и splunk для сбора системных журналов для удобства поиска.

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

Отладочные операторы: Последнее Место, где я хотел бы увеличить производительность. Если вы внедрили memcache или redis, вы получите больше шансов для своего доллара; или просто оптимизировали ваши запросы (поскольку именно здесь начинается большинство проблем с производительностью).