« Rev
@mongodb_ru   1334
Fwd »


RapidCodeLab
В интернетах полно статей про разницу
Easy Rider
параллельность это одновременное выполнение нескольких потоков или процессов на логическом уровне (а не на физическом)
Easy Rider
если речь идет о 2-х ядрах, то может и на физическом, а так она эмулируется
Easy Rider
этот термин применяется например даже в названиях классов на C#. Так что не вижу проблем
RapidCodeLab
«Эмуляция» параллельности это и есть concurrency
RapidCodeLab
https://wiki.haskell.org/Parallelism_vs._Concurrency
RapidCodeLab
Да хотя бы здесь почитать
Easy Rider
ну пофиг... это вопрос терминологии просто.
Easy Rider
он не принципиально важен. вот отличие асинхронности от параллельности это важно понимать, это разные вещи на прикладном уровне
RapidCodeLab
Ну может и пофиг, только лучше наверно понимать как все работает внутри ))
Easy Rider
иногда лучше не забивать себе голову ненужными вещами 😂
RapidCodeLab
В любом случае, все что пишет товарищ про nginx полный бред и непонимание принципа его работы) прелоадер у него крутится для второго пользователя )) а десятый наверно ваше не дождется ответа никогда 😂
Easy Rider
может быть на каком-то этапе там и правда однопоточно всё
RapidCodeLab
Однопоточно != блокируется
Arams
Вы совсем не понимаете как работает Nginx! В его документации четко написано, что он не блокируется.
Напишите функцию которая будет отдавать данные через 15 секунд после запроса, и запустите в 2х окнах с разницей в 5 секунд. Вас ждёт много открытий
Easy Rider
Напишите функцию которая будет отдавать данные через 15 секунд после запроса, и запустите в 2х окнах с разницей в 5 секунд. Вас ждёт много открытий
я думаю что если написать такой контроллер, который отдает через 15 секунд, и запуститть хоть 1000 их сразу параллельно, то каждый будет ровно через 15 сек отдавать
Easy Rider
это очевидно что даже проверять лень
Arams
вы реально думаете, что 1000 пользователей ждут, пока все предыдущие запросы выполнит nginx ?😂
Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту На дефолте и 1 ядре это однозначно так
Thunder
Напишите функцию которая будет отдавать данные через 15 секунд после запроса, и запустите в 2х окнах с разницей в 5 секунд. Вас ждёт много открытий
то есть, по вашему, если пользователь номер 1 выполняет запрос к бд длительностью 15 сек, пользователь номер 2 видит прелоадер? а что далет пользователь номер 10 тогда? ждет 15*10 ? а пользователь номер 1000?
Thunder
тому походу вообще без вариантов)
Thunder
https://www.nginx.com/resources/library/infographic-inside-nginx/ The innovative non-blocking, event-driven architecture that allows NGINX to schedule multiple state machines simultaneously думаю на этом можно закончить
Arams
@x_thunder_bird а теперь внимательно, я не говорю про блокировки, я говорю о том что на 1 ядре по дефолту nginx обработает 1 запрос и пока не отдаст ответа не приступит к следующему
Thunder
нет! и еще раз нет! вы можете так думать, но это нет так. читайте доки, я уже все что мог сказал
Артем
Ну дак 1 ядро не убивает Async же
Артем
заинтриговали прям, пойду разверну
Arams
Ну дак 1 ядро не убивает Async же
Дело не в асунке, пишем функцию которая берёт данные из коллекции и пробегает например мапом
Артем
При чем здесь какой-то мап и коллекции? Ты про Nginx говоришь
Thunder
да, да, и в это время второй пользователь смотрит на прелоадер, уже все поняли))) и еще очередь из 100 пользователей ждут вечера)))
Arams
При чем здесь какой-то мап и коллекции? Ты про Nginx говоришь
Так вот nginx пока не дождётся отработки мапа, не приступит к следующему запросу
Easy Rider
Так вот nginx пока не дождётся отработки мапа, не приступит к следующему запросу
не может быть. такой нгинкс никому не был бы нужен
Thunder
пздц...)))
Thunder
других слов просто нет, шикарный уровень компетенций
Артем
Ты вот пытаешься просто убедить сейчас, что у тебя если 16 ядер, то параллельно работают 16 запросов Что точно вранье, но ради опровержения я уже начал ставить nginx на 1 ядре))
Arams
Щас до офиса доберусь через пару часов тоже попробую)
Thunder
не надо ничего пробовать даже, читаем два абзаца по ссылке, все!!! https://www.nginx.com/resources/library/infographic-inside-nginx/
Артем
В MongoDB есть возможность вызвать SLEEP? Я помню в постгресах всяких была
Артем
чтобы имитировать работу не через sleep в языке, а sleep в базе при запросе
RapidCodeLab
https://habr.com/ru/articles/267721/
Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов. Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие. Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла. Этот подход к обработке соединений позволяет Nginx'у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках. цитата из вашей же ссылки, неужели не очевидно, что тут написано обратное вашему представлению о работе nginx?
Arams
Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов. Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие. Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла. Этот подход к обработке соединений позволяет Nginx'у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках. цитата из вашей же ссылки, неужели не очевидно, что тут написано обратное вашему представлению о работе nginx?
Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов. Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие. Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла. Этот подход к обработке соединений позволяет Nginx'у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках. Там же
RapidCodeLab
ну и о чем тут написано?
RapidCodeLab
о том что он не принимает новый запрос, пока не выполнит предыдущий? разве?
Arams
Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту
RapidCodeLab
ну и как это противоречит тому, что nginx может обрабатывать новые запросы?
RapidCodeLab
до завершение предыдущих
RapidCodeLab
где тут написано, что новые коннекты не принимаются и не обрабатываются?
Arams
Он будет ждать пока генерируется ответ и после этого приступит к следующему
Arams
Следующие запросы встанут в очередь просто
Артем
@app.get('/{seconds}') async def index(seconds: int): start_date = datetime.datetime.now() if seconds >= 0: await asyncio.sleep(seconds) end_date = datetime.datetime.now() return { 'start_date': start_date, 'end_date': end_date } Такое ведь норм для теста?
RapidCodeLab
где это написано? что приступит к следующему после обработки текущего? нет такого там, это вы додумали просто
RapidCodeLab
Он будет ждать пока генерируется ответ и после этого приступит к следующему
ключевое, "подождать" это не значит ничего больше не делать. Статья сама по себе перевод не очень хороший, лучше все таки к документации аппелировать в таких вопросах
RapidCodeLab
тут наверно нужно понимание event-loop модели, судя по всему его нет.
RapidCodeLab
это никакая не очередь
RapidCodeLab
очередь это FIFO , и это не то, как работает nginx
RapidCodeLab
если по простому, зашло в nginx 1000 коннектов, в каждом запрос к бд с разной нагрузкой. первый ответ получит тот пользователь, чей запрос в бд быстрее выполнится, и не важно какой он по очереди обратился к nginx.
RapidCodeLab
при то новые коннекты продолжают приниматься
RapidCodeLab
и могут получить ответ быстрее, чем те что уже были в евент лупе
RapidCodeLab
и даже на 1 ядре))
Артем
на 100 одновременных запросах всё более чем ок, щас запустил тест на 10к запросов одновременных
Артем
Максимальное время разницы времени между отправкой запроса и получения запроса приложением — 53мс
Артем
это возможно вообще парсинг json`и время работы фреймворка (aiohttp на отправку запроса и fastapi на приложение)
Arams
А слип на сколько?
Артем
20 секунд
Артем
хм, а вот на 1к запросов уже есть задержка между отправкой и получением приложения в 180 секунд
Артем
10к думаю нет смысла проверять, задержка вырастит но вряд ли кто-то получает на 1 ядре 1к одновременных запросов
Arams
хм, а вот на 1к запросов уже есть задержка между отправкой и получением приложения в 180 секунд
Втыкни мап какой нибудь без слипа, интересно, я просто Клаву после чистки дома забыл, возвращаюсь
Артем
Может быть стоит поиграться с proxy pass, чтобы он через сокет проксировал я не особо шарю за такую тонкую настройку
Артем
Артем
« Rev
@mongodb_ru   1334
Fwd »