Обработка параллелизма в веб-приложении на основе Python

Question

Обработка параллелизма в веб-приложении на основе Python

1

Я разрабатываю веб-приложение на фляже, python, sqlalchemy и postgresql. Мой вопрос здесь в отношении обработки параллелизма в этом приложении.

Как я написал приложение:

Я беру пример добавления пользователя в базу данных. Я отправляю форму и вызывается. Я обрабатываю все данные формы, а затем вызываю add_user (* arg), который использует код sqlalchemy для вставки пользователя в базу данных и возвращается при успешном выполнении, и я возвращаю ответ из представления.

Я предположил:

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

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

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

codecool 01 март 2012, в 15:24

Источник

Теги:

python

postgresql

multithreading

web-applications

concurrency

1 ответ

Ещё вопросы

jd. · Accepted Answer · 2012-03-01T15-12-00.000Z

Flask будет выполнять каждый запрос в отдельном потоке или даже в отдельных процессах. Количество потоков и процессов для появления определяется WSGI-сервером (например, Apache с mod_wsgi).

Если вы используете SQLAlchemy ScopedSessions, сеанс отлично потокобезопасен. Вы не должны делиться объектами, контролируемыми ORM, через потоки (но в большинстве случаев вы не позволяете своим объектам жить дольше, чем запрос, так что это обычно не вызывает беспокойства).

Другими словами, до тех пор, пока вы не собираетесь делиться государством между запросами, кроме как через базу данных или файлы cookie, вам не нужно беспокоиться о проблемах с параллелизмом. Вам не нужно создавать блокировку для записи в базу данных.

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

Что происходит с mod_wsgi, объясняется в code.google.com/p/modwsgi/wiki/ProcessesAndThreading
@jd Что вы подразумеваете под разделением состояния между запросами? Я сохраняю объект sqlalchemy моего текущего пользователя в сеансе пользователя и снова объединяю его с текущим сеансом sqlalchemy при следующем запросе. Это разделение штата?
Как вы храните объект SQLAlchemy в сеансе? О каких сессиях мы говорим? Подписанный файл cookie? Если ваш сеанс является подписанным файлом cookie и он должен ссылаться на объект базы данных, он, вероятно, должен в любом случае хранить идентификатор объекта, при этом объект извлекается из БД по мере необходимости.
Я использую сеансы на стороне сервера, поддерживаемые Redis. Я запрашиваю пользовательский объект, а затем выбираю и сохраняю его при входе в систему и в последующих запросах использую этот пользовательский объект после объединения его с сеансом sqlalchemy каждого запроса. при выходе я удаляю этот объект пользователя из сеанса на стороне сервера.
Тогда у вас все в порядке в том, что касается потоков, поскольку ваш сериализованный объект полностью отделен от сеанса ORM.