Как обрабатывать длительные запросы в python-работниках?

Question

У меня есть функция python (ну, теперь это PHP, но мы переписываем), которая принимает некоторые параметры (A и B) и вычисляет некоторые результаты (находит лучший путь от A до B в графе, граф доступен только для чтения) , в типичном сценарии один вызов занимает от 0,1 до 0,9 с. Эта функция доступна пользователям как простой веб-сервис REST (GET bestpath.php? From = A & to = B). Текущая реализация довольно глупа - это простой скрипт php + apache + mod_php + APC, каждый запрос должен загружать все данные (более 12 МБ в массивах php), создавать все структуры, вычислять путь и выходить. Я хочу изменить его.

Я хочу установить с N независимых работников (X на сервер с серверами Y), каждый рабочий является приложением python, работающим в цикле (получение запроса -> обработка -> отправка ответа -> получение req ...) каждый рабочий может обрабатывать один запрос за раз. Мне нужно что-то, что будет действовать как интерфейс: получать запросы от пользователей, управлять очередью запросов (с настраиваемым таймаутом) и кормить моих работников по одному запросу за раз.

Как подойти к этому? можете ли вы предложить некоторые настройки? nginx + fcgi или wsgi или что-то еще? HAproxy? как вы можете видеть, что я новичок в python, обратный прокси и т. д. Мне просто нужна начальная точка архитектуры (и потока данных)

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

Answer 1

Типичным способом обработки такого рода размещения с использованием потоков в Python является использование стандартного библиотечного модуля Queue. Пример использования модуля Queue для управления рабочими можно найти здесь: Queue Example

Answer 2

Похоже, что вам нужны «рабочие», чтобы быть отдельными процессами (по крайней мере некоторые из них, и, следовательно, могли бы также сделать их все отдельными процессами, а чем пучки нитей, разделенных на несколько процессов). Модуль multiprocessing в Python 2.6 и более поздняя стандартная библиотека предлагают хорошие возможности для создания пула процессов и общения с ними через очереди «FIFO»; если по какой-то причине вы застряли с Python 2.5 или даже раньше, есть версии многопроцессорности в репозитории PyPi, которые вы можете скачивать и использовать с более старыми версиями Python.

«frontend» может и должен быть легко выполнен для работы с WSGI (с Apache или Nginx), и он может обрабатывать все сообщения с рабочими процессами с помощью multiprocessing без необходимости использования HTTP, проксирования и т. д. для этой части системы; только внешний интерфейс будет веб-приложением как таковым, рабочие просто получают, обрабатывают и реагируют на единицы работы, как того требует внешний интерфейс. Для меня это кажется самой простой и простой архитектурой.

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

Answer 3

Я думаю, что вы можете настроить modwsgi/Apache поэтому он будет иметь несколько «горячих» интерпретаторов Python в отдельных процессах, готовых идти в любое время, а также использовать их для новых доступов (и породить новый, если они все занятый). В этом случае вы можете загрузить все предварительно обработанные данные в виде глобальных глобалов, и они будут загружаться только один раз за процесс и будут повторно использоваться для каждого нового доступа. На самом деле я не уверен, что это не стандартная конфигурация для modwsgi/Apache.

Основная проблема заключается в том, что вы можете в конечном итоге потреблять много «основной» памяти (но это тоже не проблема). Я думаю, вы также можете настроить modwsgi для одного процесса/несколько потоков , но в этом случае вы можете использовать только один процессор, потому что из Python Global Interpreter Lock (печально известный GIL), я думаю.

Не бойтесь спросить в списке рассылки modwsgi - они очень отзывчивый и дружелюбный.

Answer 4

Вы можете использовать балансировщик нагрузки nginx для прокси-сервера PythonPaste paster (который обслуживает WSGI, например Pylons), который в любом случае запускает каждый запрос как отдельный поток.

Answer 5

Существует много модулей FastCGI с предварительно запрограммированным режимом и интерфейсом WSGI для питона вокруг, наиболее известным является flup. Мое личное предпочтение для такой задачи - superfcgi с nginx. Оба запускают несколько процессов и будут отправлять запросы к ним. 12Mb не так много, чтобы загружать их отдельно в каждом процессе, но если вы хотите делиться данными между рабочими, вам нужны потоки, а не процессы. Обратите внимание, что тяжелая математика в python с одним процессом и многими потоками не будет эффективно использовать несколько CPU/ядер из-за GIL. Вероятно, наилучшим подходом является использование нескольких процессов (столько, сколько у вас есть ядер), каждый из которых запускает несколько потоков (режим по умолчанию - superfcgi).

Answer 6

Самое простое решение в этом случае - использовать веб-сервер для выполнения всего тяжелого подъема. Почему вы должны обрабатывать потоки и/или процессы, когда веб-сервер сделает все, что для вас?

Стандартное расположение в развертывании Питона:

1. Вебсервер начать ряд процессов, каждый из которых выполняет полный интерпретатор питона и при необходимости загружать все данные в памяти.
2. запрос HTTP приходит и получает отправляется в какую-то процесс
3. Процесс делает свой расчет и возвращает результат непосредственно на веб-сервер и пользователь
4. Если вам необходимо изменить свой код или данные графика, перезагрузки веб-сервера и вернитесь к шагу 1.

Это архитектура, используемая Django и другие популярные веб-фреймворки.

Answer 7

Другим вариантом является таблица очередей в базе данных.
Рабочие процессы выполняются в цикле или вне cron и опроса таблицы очередей для новых заданий.