Что будет если на сервер придет одновременно два запроса?

@Михалыч · Регистрация: 28.02.2013

Студворк — интернет-сервис помощи студентам

Доброго дня!) Вопрос теоретический, но все же. Смотрите например есть форма куда забиваются данные, по нажатию кнопки эти данные отправляются на сервер, на сервере на основе этих данных формируется отчет в word (например отчет формируется в течении 5 минут) и возвращается обратно пользователю.

Что будет если в то время пока формируется отчет, с другого компа отправят еще запрос (или 2 запроса)?

Что в этом случае будет делать сервер, он эти запросы в очередь поставит?

Добавлено через 3 минуты
Т.е. я к чему: если например с интервалом в 1 секунду (чисто гипотетически) придет 10 запросов из формы, то если принять что на один отчет сервер тратит 5 минут, последний пользователь который отправил запрос получит ответ через 10*5=50 минут?

@Kifsif · 01.07.2020, 19:55

Я не знаток веб-серверов.
Если я не ошибаюсь, то Nignix - событийный, основанный на round-robin.
А Apache форкнет поток. Боюсь тут ввести в заблуждение.

Т.е. если я не ошибаюсь, то Апач создаст полностью новый поток. Запустит в нем Джангу, проделает всю бизнес-логику.
Тут прилетает новый запрос, новый поток, новая джанга. Возможно, есть настройки у Апача, чтобы он работал событийно.

В общем, так до потери сознания сервером. Т.е. можно его положить - до 500-й ошибки.

Nginx форкать ничего не будет, новую Джангу создавать не будет. Он существующей Джанге даст во вьюху новый запрос. А когда Джанга отработает, поймает ее ответ. И вернет юзеру.

Т.е. положить сервак тоже можно - но он должен протянуть на Nginx чуть дольше.

В общем, мне кажется, что:
1. Архитектура классического веб-приложения тут не очень подходит. Потому что будет открытое соединение по http держаться 5 минут.
Это плохо.
2. Надо бы такую длительную задачу ставить в очередь на серваке. Будут ресурсы у сервака - он сделает задачу и отдаст юзеру.
3. Юзеру надо сообщить о том, что задача в работе. Включить спиннер.
4. Периодически опрашивать сервак Аяксом: готов ли отчет.
5. Когда отчет готов, забрать его аяксом и дать юзеру.

Но я вот в этом всем очень плаваю. И если кто из гуру ответит на поставленный вопрос, было бы просто здорово.
Так что присоединяюсь к вопросу.

Добавлено через 6 минут

Сообщение от Михалыч

Т.е. я к чему: если например с интервалом в 1 секунду (чисто гипотетически) придет 10 запросов из формы, то если принять что на один отчет сервер тратит 5 минут, последний пользователь который отправил запрос получит ответ через 10*5=50 минут?

Не через 50, конечно. Параллельные вычисления.
Минут за 5+ . Плюс - потому что точно не за 5 минут. Даже если будет 16 ядер на 10 задач. Закон Амдала не позволит закончить в один срок.

Рыжий Лис · 14.07.2020, 15:10

Смотря как развёрнуто приложение. Если более-менее стандартная связка nginx+uwsgi, то второй запрос придёт на свободный воркер и будет выполнен параллельно. Если всего воркеров 4, то максимум будет обработано 4 запроса параллельно. nginx будет остальные запросы придерживать, пока не освободится воркер. Скорее всего клиенту отдастся ошибка 502 по истечении таймаута (около минуты).

@Kifsif · 14.07.2020, 15:57

А worker в nginx - это же поток. Т.е. будет все же новый поток, в нем новая Django. Так?

Рыжий Лис · 14.07.2020, 16:10

Нет, речь шла про worker uwsgi. Их создаётся фиксированное количество. nginx вообще не умеет запускать никакой код и только проксирует запросы.

Добавлено через 1 минуту

Сообщение от Kifsif

А worker в nginx - это же поток.

Нет, процесс:

Bash
1
2
3
4
5
6
$ ps aux | grep nginx
root      1020  0.0  0.0 141116   420 ?        Ss   июл11   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data  1021  0.0  0.0 144468  1440 ?        S    июл11   0:00 nginx: worker process
www-data  1022  0.0  0.0 143836   104 ?        S    июл11   0:00 nginx: worker process
www-data  1023  0.0  0.0 143836   104 ?        S    июл11   0:00 nginx: worker process
www-data  1024  0.0  0.0 144136  1428 ?        S    июл11   0:00 nginx: worker process

@Kifsif · 14.07.2020, 16:14

Я запутался worker nginx - это же отдельный поток. Значит в отдельном потоке отработает worker uwsgi. В общем, я потерял нить абсолютно.

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

При этом подчеркнуть разницу Apache и Nginx.
И особо отметить момент: когда запускается новая Django.

Совсем не запускать новую Django нельзя. Когда-то же она должна была создаться хотя бы одна.
А вот будет ли она создаваться заново на каждый запрос - этот вопрос интересен.

Рыжий Лис · 14.07.2020, 16:26

Сообщение от Kifsif

Значит в отдельном потоке отработает worker uwsgi.

Нет, не работает там.

Будет многабукв.

Раз: есть демон nginx'а - он слушает порты и принимает запросы. Он намного проще апача: раздаёт статику (файлы) и не выполняет никакой код. Проксирует запросы дальше. Например, на unix-сокет. Да, у него есть воркеры, которые позволяют утилизировать все ресурсы системы.

Два: есть демон uwsgi - он может выполнять код на различных языках. В том числе питон. Он слушает unix-сокет (со своим бинарным протоколом) и запускает воркеры, внутри которых работает копия wsgi-приложения. Джанго как раз для развёртывания предлагает wsgi-интерфейс.

Таким образом запущенное приложение выглядит так:
* база данных (может быть на другом сервере)
* uwsgi с воркерами
* nginx

Запрос приходит на nginx - он находит нужный location и передаёт запрос uwsgi. uwsgi находит свой свободный воркер и передаёт запрос в приложение. Если воркер упал - он перезапускается.

@Kifsif · 14.07.2020, 16:28

Так, а в воркере uwsgi что происходит? Каждый раз запуск джанги с последующим ее закрытием?

Рыжий Лис · 14.07.2020, 16:35

Нет, один раз запустился - и работает. Обработал запрос, отдал ответ - ждёт нового запроса.

@m0nte-cr1st0 · 14.07.2020, 21:11

Рыжий Лис, отдельный воркер uwsgi, gunicorn etc = отдельный инстанс приложения?

Рыжий Лис · 15.07.2020, 05:00

Да.

@Kifsif · 15.07.2020, 09:03

Сообщение от Рыжий Лис

Да.

Количество воркеров uwsgi ограничено, если я не ошибаюсь. Что-то типа один воркер на виртуальное ядро.

Т.е.:

1. Летит запрос от посетителя сайта.
2. Сработал nginx. Nginx событийный. Он взял и пробросил, допустим, запрос, на gunicorn. И дальше занимается своими делами - когда будет надо, ему дадут ответ, либо таймаут истечет.
3. Gunicorn запускает свой воркер уже в отдельном потоке. В нем новая Django.
4. Django отработала, вернула ответ.
5. Gunicorn получил ответ, завершил работу потока. Вернул ответ серверу nginx.
6. Сервер nginx обнаружил событие ответа на запрос и вернул результат юзеру.

Так получается?

Рыжий Лис · 15.07.2020, 09:12

Сообщение от Kifsif

Что-то типа один воркер на виртуальное ядро.

Типа того. Это прописывается в конфиге:

Code
1
2
3
[uwsgi]
processes = %k
threads = 2

Переменная %k - количество (логических) ядер процессора на машине. https://www.cyberforum.ru/blog... g5330.html

Сообщение от Kifsif

3. Gunicorn запускает свой воркер уже в отдельном потоке. В нем новая Django.

Сообщение от Kifsif

5. Gunicorn получил ответ, завершил работу потока. Вернул ответ серверу nginx.

Нет, воркер запущен заранее. Вот пример из мана:

Bash
1
2
3
4
5
6
7
  $ gunicorn -w 4 myapp:app
  [2014-09-10 10:22:28 +0000] [30869] [INFO] Listening at: http://127.0.0.1:8000 (30869)
  [2014-09-10 10:22:28 +0000] [30869] [INFO] Using worker: sync
  [2014-09-10 10:22:28 +0000] [30874] [INFO] Booting worker with pid: 30874
  [2014-09-10 10:22:28 +0000] [30875] [INFO] Booting worker with pid: 30875
  [2014-09-10 10:22:28 +0000] [30876] [INFO] Booting worker with pid: 30876
  [2014-09-10 10:22:28 +0000] [30877] [INFO] Booting worker with pid: 30877

Получается, что между запросами в коде сохраняется состояние всех глобальных переменных (приложение же не завершалось). Только есть маленький подвох: следующий запрос может прийти на другой воркер, где (сюрприз!) другое состояние глобальных переменных.

Добавлено через 1 минуту
https://docs.gunicorn.org/en/s... deployment

@m0nte-cr1st0 · 15.07.2020, 13:23

Рыжий Лис,

Сообщение от Рыжий Лис

Да.

Если предположить, что запущено 4 инстанса приложения.
Допустим, есть модель А. Приходит запрос на первый инстанс и создаётся экземпляр этой модели (запись в бд, тот же постгрес, к примеру).
На второй инстанс приложения приходит запрос на получение этой записи. Я верно понимаю, что запись будет доступна (так как каждый инстанс обращается к бд, когда есть определённый запрос, и на момент запроса на второй инстанс приложения запись в бд уже есть)?

Рыжий Лис · 15.07.2020, 13:32

Да, всё верно. Если в базу вставили запись (INSERT или обновили UPDATE, или удалили DELETE) и при этом сделали коммит (COMMIT, в джанге по умолчанию autocommit включён), то при следующих запросах (в том числе и из других воркеров) к базе будет отдаваться изменённая версия данных.

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

@m0nte-cr1st0 · 15.07.2020, 13:39

Рыжий Лис, теперь понятно, об что я иногда бился в фласке с алхимией

Рыжий Лис · 15.07.2020, 13:42

Разве там autocommit не включён? Расскажи, что хоть за проблема была.

@m0nte-cr1st0 · 15.07.2020, 13:48

Рыжий Лис, погоди, ты же об этом?

Python
1
2
session.add(object)
session.commit()

https://docs.sqlalchemy.org/en... ssionmaker
autocommit в False выставлен по дефолту

Сообщение от Рыжий Лис

Расскажи, что хоть за проблема была.

Было, что приходило два запроса практически одновременно. Один - на insert, второй - на select. Во время второго запроса не было видно записи добавленной первым запросом..

Рыжий Лис · 15.07.2020, 13:52

Видимо, да, про это.

Сообщение от m0nte-cr1st0

Во время второго запроса не было видно записи добавленной первым запросом..

Скорее всего insert ещё не закоммитили. Либо база успела выполнить select быстрее, чем закоммитить изменения (операция записи занимает больше времени, и чтобы не лочить все запросы чтения, отдаётся предыдущая версия).

@m0nte-cr1st0 · 15.07.2020, 14:42

Рыжий Лис, вот и я теперь понял. Спасибо.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@Михалыч 1011 / 355 / 59 Регистрация: 28.02.2013 Сообщений: 939

	Что будет если на сервер придет одновременно два запроса? 29.06.2020, 10:10. Показов 8661. Ответов 22 Метки django, form, python (Все метки) Доброго дня!) Вопрос теоретический, но все же. Смотрите например есть форма куда забиваются данные, по нажатию кнопки эти данные отправляются на сервер, на сервере на основе этих данных формируется отчет в word (например отчет формируется в течении 5 минут) и возвращается обратно пользователю. Что будет если в то время пока формируется отчет, с другого компа отправят еще запрос (или 2 запроса)? Что в этом случае будет делать сервер, он эти запросы в очередь поставит? Добавлено через 3 минуты Т.е. я к чему: если например с интервалом в 1 секунду (чисто гипотетически) придет 10 запросов из формы, то если принять что на один отчет сервер тратит 5 минут, последний пользователь который отправил запрос получит ответ через 10*5=50 минут? 0

Рыжий Лис Просто Лис 5973 / 3735 / 1099 Регистрация: 17.05.2012 Сообщений: 10,791 Записей в блоге: 9
	14.07.2020, 15:10
	Смотря как развёрнуто приложение. Если более-менее стандартная связка nginx+uwsgi, то второй запрос придёт на свободный воркер и будет выполнен параллельно. Если всего воркеров 4, то максимум будет обработано 4 запроса параллельно. nginx будет остальные запросы придерживать, пока не освободится воркер. Скорее всего клиенту отдастся ошибка 502 по истечении таймаута (около минуты). 3

@Kifsif 145 / 113 / 31 Регистрация: 12.06.2011 Сообщений: 1,246
	14.07.2020, 15:57
	А worker в nginx - это же поток. Т.е. будет все же новый поток, в нем новая Django. Так? 0

@Kifsif 145 / 113 / 31 Регистрация: 12.06.2011 Сообщений: 1,246
	14.07.2020, 16:14
	Я запутался worker nginx - это же отдельный поток. Значит в отдельном потоке отработает worker uwsgi. В общем, я потерял нить абсолютно. Нельзя ли расписать всю схему полностью от запуска веб-сервера через прилет первого запроса и последующих запросов до отдачи ответа на каждый запрос. При этом подчеркнуть разницу Apache и Nginx. И особо отметить момент: когда запускается новая Django. Совсем не запускать новую Django нельзя. Когда-то же она должна была создаться хотя бы одна. А вот будет ли она создаваться заново на каждый запрос - этот вопрос интересен. 1

@Kifsif 145 / 113 / 31 Регистрация: 12.06.2011 Сообщений: 1,246
	14.07.2020, 16:28
	Так, а в воркере uwsgi что происходит? Каждый раз запуск джанги с последующим ее закрытием? 0

Рыжий Лис Просто Лис 5973 / 3735 / 1099 Регистрация: 17.05.2012 Сообщений: 10,791 Записей в блоге: 9
	14.07.2020, 16:35
	Нет, один раз запустился - и работает. Обработал запрос, отдал ответ - ждёт нового запроса. 0

@m0nte-cr1st0 1043 / 578 / 242 Регистрация: 15.01.2019 Сообщений: 2,178 Записей в блоге: 1
	14.07.2020, 21:11
	Рыжий Лис, отдельный воркер uwsgi, gunicorn etc = отдельный инстанс приложения? 0

Рыжий Лис Просто Лис 5973 / 3735 / 1099 Регистрация: 17.05.2012 Сообщений: 10,791 Записей в блоге: 9
	15.07.2020, 05:00
	Да. 1

Рыжий Лис Просто Лис 5973 / 3735 / 1099 Регистрация: 17.05.2012 Сообщений: 10,791 Записей в блоге: 9
	15.07.2020, 13:32
	Да, всё верно. Если в базу вставили запись (INSERT или обновили UPDATE, или удалили DELETE) и при этом сделали коммит (COMMIT, в джанге по умолчанию autocommit включён), то при следующих запросах (в том числе и из других воркеров) к базе будет отдаваться изменённая версия данных. А вот если коммит не делать (я периодически об это обжигаюсь), то всем остальным клиента будет отдаваться старая версия данных, и только ты в текущей сессии будешь видеть новые (пока не закоммитишь или не откатишь изменения). Впрочем, для джанги такие случаи редки (хотя она тоже умеет в транзакции). 1

@m0nte-cr1st0 1043 / 578 / 242 Регистрация: 15.01.2019 Сообщений: 2,178 Записей в блоге: 1
	15.07.2020, 13:39
	Рыжий Лис, теперь понятно, об что я иногда бился в фласке с алхимией 0

Рыжий Лис Просто Лис 5973 / 3735 / 1099 Регистрация: 17.05.2012 Сообщений: 10,791 Записей в блоге: 9
	15.07.2020, 13:42
	Разве там autocommit не включён? Расскажи, что хоть за проблема была. 0

@m0nte-cr1st0 1043 / 578 / 242 Регистрация: 15.01.2019 Сообщений: 2,178 Записей в блоге: 1
	15.07.2020, 14:42
	Рыжий Лис, вот и я теперь понял. Спасибо. 0