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

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

1 голос
/ 01 марта 2012

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

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

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

То, что я предположил:

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

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

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

1 Ответ

5 голосов
/ 01 марта 2012

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

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

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

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

...