Вот у меня получается каждый контроллер идет к сервису своему,

который сразу начинает транзакцию. для атомарности. пока работает одна транзакция, никакая другая не может получить доступ к коллекции?

она в очередь встанет если нет воркеров и на сервере 1 ядро

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

да хз.

конфиг глянь nginx и кол-во ядер на проце)))

пока что ядро одно но их будет 16 когда все будет работать уже в боевом режиме

Вы совсем не понимаете как работает Nginx! В его документации четко написано, что он не блокируется.

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

Напишите функцию которая будет отдавать данные через 15 секунд после запроса, и запустите в 2х окнах с разницей в 5 секунд. Вас ждёт много открытий

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

вы реально думаете, что 1000 пользователей ждут, пока все предыдущие запросы выполнит nginx ?😂

Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту На дефолте и 1 ядре это однозначно так

то есть, по вашему, если пользователь номер 1 выполняет запрос к бд длительностью 15 сек, пользователь номер 2 видит прелоадер? а что далет пользователь номер 10 тогда? ждет 15*10 ? а пользователь номер 1000?

https://habr.com/ru/articles/267721/

Помоему то что выполняется 15 секунд это чуток не здоровая тема и такое обычно живёт в сервисах на отдельных боксах)

Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов. Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие. Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла. Этот подход к обработке соединений позволяет Nginx'у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках. цитата из вашей же ссылки, неужели не очевидно, что тут написано обратное вашему представлению о работе nginx?

Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов. Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие. Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла. Этот подход к обработке соединений позволяет Nginx'у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках. Там же

вот отсюда треш пошел)

У вас авы одинаковые, спутал