Озверинот вас слышу только про идиотов, воду, бесполезность микросеврисов и уши ;)Ну а как иначе? Вот пишут:авторOption 1: Increase the thread pool size
Yes, this is a good workaround, BUT only workaround!!! Because we cannot set this value to several thousand, because it’s is Docker with very limited memory. And each thread requires stack memory.У кота, по моим наблюдениям, http-поток отжирает где-то в районе аж 100Kb, т.е. на тысячу потоков будет аж целых 100Mb, а пишут что это много (на машине времени чтоли на 30 лет назад сгоняли?), я бы понял еще если бы написали что слишком много экзекьюшн юнитов и все начинает тупить (ну и там график бы еще с насыщением привели), а здесь какая-то левая отмазка про память. Если продолжать верить в то, что они таки в количестве памяти ограничены, то в реальности получается так: разница межу t2.micro и t2.medium в цене 15$ в месяц, при этом 1Gb против 4Gb, "исследование" по ссылке заняло наверное дня 4 и стоило заказчику косаря 2, вопрос: на сколько обули заказчика?

questionerАндрей Панфиловпропущено...
Вопрос: сколько можно в сокет написать без блокировки?
Вот вообще не представляю даже. И вообще не понимаю этот механизм. Для меня NIO это некая выведенная унифицированная абстракция над улучшениями ОС, которая на Юниксе дать один прирост, а на Винде ничего не дать.Ну а чего не нагулили-то?
man 2 send :

размер send buffer по-умолчанию в linux 122Kb, причем его еще можно увеличивать, теперь второй вопрос: с повальным увлечением REST в вебе, 122Kb - это большой размер для ответа или маленький?

Озвериня не понял: вы не отличаете stack memory от heap?Насколько я помню это у вас в прошлый раз возникали проблемы с размером стэка, вот из интернетов: 10 тысяч потоков на 2Gb кучи , чес про память из статьи, что вы привели, несостоятелен.

Озверинили не понимаеет, что у микросервисов есть своя нишаПока понимание такое, что ниша микросервисов - обуть лохов.

redwhite90Процентное соотношение мне не известно, но с уверенностью можно сказать, что не редки случаи когда ответ превышает 122 кббольше 122Kb - это видосики чтоли? на странице A4 где-то 3000 печатных знаков, ну с пробелами пусть будет 4000, ладно, форум русскоязычный, пусть A4 - будет 8Kb, т.е. чтобы в попасть в блокировку на send() нужно отправить >15 страниц текста (и при этом ничего в ОС не крутить!)... вы точно адекватно оцениваете объемы передаваемой информации? или в JSON html пихаете?

Андрей Панфиловчес про память из статьи, что вы привели, несостоятелен.Дальше, смотрим на картинку где сравнивается throughput разных подходов:
"классика" - 831

async - 1313

WebFlux - 1469

замечаем, что цифры от WebFlux не особо-то и хорошо смотрятся на фоне servlet api 3.0 , теперь смотрим код:




я правильно понял, что автор статьи в случае "синхронного" выполнения утилизирует 2 потока одновременно: один с CompletableFuture, второй с join, а потом говорит потоков как-то много и памяти не хватает?

Озверинnetflix горько плачету них же бизнес видосики стримить, не?

ОзверинТолько микросервисы там выполняют совершенно разные ф-ии..идиоты, думаю.ну а как еще? сидит там отдел разработки и думает: как бы вытянуть из бизнеса еще денег! о! нужно сказать что все что мы до этого делали чуть собачья и нужно все переписать заново. Мы вон в 2005 киношки стримили с посредственного сервера и спокойно забивали 4 гигабита, и никаких микросервисов не было, только perl и nginx.

questionerпохоже на правду?Нет. за tcp/ip полностью отвечает ядро, если со стороны используются вызовы send/recv ("классика"), то концепция такая:
- send блокируется только тогда, когда приложение хочет отправить данных больше, чем можно записать в send buffer (ядро читает оттуда и отправляет в сеть, т.е. в определенные моменты там могут находиться еще неотправленные данные, или данные, на которые не получено подтверждение)
- recv блокируется только тогда приложение хочет прочесть данных больше чем сейчас есть в receive buffer (ядро получает данные из сети и складывает их туда), кроме этого через recv еще приходят ошибки таймаута от send (т.е. send для приложения асинхронный, однако о том что данные не доставлены нужно приложению сообщать, вот ядро сообщает в recv)

и в случае "классики" основная беда в recv, потому что он блокирующий в большинстве случаев и в больших send, поэтому чтобы одновременно обрабатывать много соединений нужно много потоков (условно поток на соединение). В случае же асинхронного I/O много потоков не нужно, потому что там сценарий работы отличается: мы открываем сокетов столько сколько захотим, а у ядра ОС спрашиваем расклад по нашим сокетам, т.е. ответ будет:
- сюда можно писать
- отсюда можно читать
- здесь ошибка

по факту в примере из https://medium.com/@filia.aleks/microservice-performance-battle-spring-mvc-vs-webflux-80d39fd81bf0 написана какая-то дичь: там на 800 клиентов получается 60 потоков в пике, что для прокси несколько странно, например если сравнивать с "референсной реализацией" прокси-сервера, то там пишут так:
nginxNGINX can run multiple worker processes, each capable of processing a large number of simultaneous connections. You can control the number of worker processes and how they handle connections with the following directives:

- worker_processes – The number of NGINX worker processes (the default is 1). In most cases, running one worker process per CPU core works well, and we recommend setting this directive to auto to achieve that. There are times when you may want to increase this number, such as when the worker processes have to do a lot of disk I/O.
- worker_connections – The maximum number of connections that each worker process can handle simultaneously. The default is 512, but most systems have enough resources to support a larger number. The appropriate setting depends on the size of the server and the nature of the traffic, and can be discovered through testing.

т.е. с конфигурацией по-умолчанию, достаточной чтобы запускаться на каком-то хламе, Сысоев преполагает что один экзекьюшн юнит способен проксировать 512 соединений, если сравнивать с "результатами" полученным для WebFlux видно, что в консерватории что-то не так.