Тестирование на загадочные ошибки загрузки в python / django

Question

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

Настройка: сайт с поддержкой django начнет выдавать ошибки после нескольких дней использования. Это всегда были ошибки ImportError s или ImproperlyConfigured, которые равносильны одному и тому же, поскольку в сообщении всегда указывалось, что при загрузке какого-либо модуля, указанного в файле settings.py, возникла проблема. Это был вообще не тот же класс. Я использую предварительно разветвленный Apache с 8 разветвленными детьми, и всякий раз, когда возникает эта проблема, один процесс будет нарушен, а семь будет в порядке. После сбоя каждый запрос (с Debug On в apache conf) будет отображать одну и ту же трассировку каждый раз, когда он обслуживал запрос, даже если неудачная загрузка не относится к конкретному запросу. httpd restart всегда устранял проблему в краткосрочной перспективе.

Отмеченные проблемы: установка и обновление выполняются через svn с некоторыми скриптами после обновления. Несколько .pyc файлов случайно были проверены в хранилище. Кроме того, сам проект принадлежал одному пользователю (не apache, хотя у apache были права на проект), и существовал постоянный плагин, который в конечном итоге стал фоновым для пользователя root. Я называю эти отмеченные проблемы, потому что они будут неправильными, независимо от того, заметил ли я эту ошибку, и, следовательно, я их исправил. Проект принадлежит apache, а плагин задуман как apache. Все файлы .pyc находятся вне репозитория, и все они принудительно перекомпилируются после каждой проверки, пока сервер и плагин были остановлены.

То, что я хочу знать, это

1. Эти катастрофы конфигурации кажутся вероятным объяснением случайных ImportError s?
2. Если все еще есть проблема в моем коде, , как бы я лучше воспроизвел это?

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

Кстати, с момента исправления она работала без происшествий в течение примерно 2 дней, но проблема наблюдалась с интервалами от 1 до 10 дней.

Answer 1

"Эти катастрофы конфигурации кажутся вероятным объяснением спорадических ошибок ImportErrors"

Да. Старый .pyc файл - это катастрофа первой величины.

Мы разрабатываем на Windows, но работаем на Red Hat Linux. Случайно перемещенный файл .pyc является абсолютной загадкой для отладки, поскольку (1) он обычно запускается и (2) у него есть имя файла Windows для исходного источника, что делает ошибку трассировки абсолютно бессмысленной. Я часами смотрел на логи - на linux - задаваясь вопросом, почему файл был «C: \ This \ N \ That».

«Если в моем коде еще есть проблема, как бы я лучше ее воспроизвел?»

Перед воспроизведением ошибок постарайтесь их предотвратить.

Сначала создайте юнит-тесты, чтобы тренироваться во всем.

Начните с tests.py тестирования Джанго . Затем разверните до unittest для всех компонентов, не относящихся к Django. Затем напишите себе скрипт «run_tests», который запускает каждый ваш тест. Запускайте это периодически. Ежедневно не достаточно часто.

Во-вторых, убедитесь, что вы используете logging . Крупный.

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

try:
    some_external_resource_processing()
except Exception, e:
    logger.exception( e )
    raise

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

На данный момент вы предотвратили большое количество ошибок. Если вы хотите запустить циклическое нагрузочное тестирование, это тоже неплохая идея. Используйте unittest для этого.

class SomeLoadtest( unittest.TestCase ):
    def test_something( self ):
        self.connection = urllib2.urlopen( "localhost:8000/some/path" )
        results = self.connection.read()

Это не лучший способ сделать что-то, но он показывает один подход. Возможно, вы захотите начать использовать Selenium для тестирования веб-сайта «извне» в качестве дополнения к вашим тестам юнитов.