Оптимизирует ли mod_wsgi / Python вещи? - PullRequest
2 голосов
/ 05 июня 2009

Я пытался отследить странные проблемы с моим веб-приложением mod_wsgi / Python. У меня есть обработчик приложения, который создает объект и вызывает метод:

def my_method(self, file):
    self.sapi.write("In my method for %d time"%self.mmcount)
    self.mmcount += 1

    # ... open file (absolute path to file), extract list of files inside
    # ... exit if file contains no path/file strings
    for f in extracted_files:
        self.num_files_found += 1
        self.my_method(f)

В начале и конце этого я пишу

obj.num_files_found

в браузер.

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

Можно ожидать, что результат будет детерминированным

Например

Files found: 0
In my method for the 0 time
In my method for the 1 time
In my method for the 2 time
In my method for the 3 time
...
In my method for the n time
Files found: 128

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

Files found: 0
In my method for the 0 time
Files found: 128

Несмотря на то, что я знаю, из предыдущих обновлений и без изменений кода / файла, для перечисления 128 файлов требуется n раз.

Итак, вопрос: Включает ли mod_wsgi / Python внутреннюю оптимизацию, которая остановит полное выполнение? Предполагается ли вывод является детерминированным и кэш-память?

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

Я новичок в Python, будь нежнее

решаемые

Кто знает, что это было, но удаление Apache, mod_python, mod_wsgi и почти всего, что связано с HTTP, и переустановка устранили проблему. Что-то было довольно сломано , но теперь кажется нормально:)

Ответы [ 3 ]

3 голосов
/ 24 июня 2009

То, что Apache / mod_wsgi может работать как в многопроцессорных, так и в многопоточных конфигурациях, может привести к сбою кода, который написан при условии, что он выполняется в одном процессе, причем этот процесс может быть однопоточным. Для обсуждения различных возможностей конфигурации и того, что это все означает для общих данных, см .:

http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

1 голос
/ 06 июня 2009

Кажется, установка Python / mod_wsgi должна быть прервана. Я никогда не видел таких странных ошибок. Следы рядом с возвратами:

self.sapi.write("Returning at line 22 for call %d"%self.times_called)
return someval

Появляется много раз:

Возвращение в строке 22 для вызова 3

Возвращение в строке 22 для вызова 3

Возвращение в строке 22 для вызова 3

Просто нет последовательной логики в потоке управления чем-либо :( Я также почти уверен, что могу написать простой инкрементный код для подсчета количества вызовов метода. Абсолютный, разочаровывающий, глупый. время рядом с каждым вызовом sapi.write (), чтобы убедиться, что это не бессмысленный повтор кода. Они уникальны: S

Время вытащить Apache, Python, mod_wsgi и все остальное и начать заново.

решаемые

Кто знает, что это было, но удаление Apache, mod_python, mod_wsgi и почти всего, что связано с HTTP, и переустановка устранили проблему. Что-то было довольно сломано , но теперь кажется нормально:)

1 голос
/ 05 июня 2009

"Включает ли mod_wsgi / Python внутреннюю оптимизацию, которая остановит полное выполнение? Предполагается ли, что выходные данные являются детерминированными и кэшированы?"

номер

Проблема (в общем) в том, что в вашей программе есть глобальная переменная, которая не сбрасывается так, как вы надеялись.

Иногда это может быть непреднамеренным, поскольку Python проверяет локальное пространство имен и глобальное пространство имен на наличие переменных.

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

Вероятно, вы увидите несколько процессов демона mod_wsgi, каждый из которых имеет проблему с глобальной переменной. Первый запрос для каждого демона работает. Тогда ваша глобальная переменная находится в состоянии, которое препятствует работе. [Файл оставлен открытым, переменная каталога верхнего уровня перезаписана, кто знает?]

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

...