Comments 8
UFO just landed and posted this here
Вот, например.
А просто подкрутить Томкат вы не думали?
6 рпс это смешно и глупо одновременно.
Если внешние сервисы обладают бесконечный ресурсом, то все 1000 запросов должны завершится за MAX(СУММА(время внешних вызовов для одного запроса))+эпсилон время. Любой другой результат это явно ошибка настроек.
6 рпс это смешно и глупо одновременно.
Если внешние сервисы обладают бесконечный ресурсом, то все 1000 запросов должны завершится за MAX(СУММА(время внешних вызовов для одного запроса))+эпсилон время. Любой другой результат это явно ошибка настроек.
Ответ от автора статьи:
Настройки Tomkat и Netty брались по-умолчанию. Цель эксперимента показать как себя ведет каждый сервер под капотом и как видно на скринах томкат создает огромное количество потоков в своем thread pool и использует эти потоки не эффективно. А Netty ограничивает количество потоков до количества ядер используемых процессором и они работают постоянно
Настройки Tomkat и Netty брались по-умолчанию. Цель эксперимента показать как себя ведет каждый сервер под капотом и как видно на скринах томкат создает огромное количество потоков в своем thread pool и использует эти потоки не эффективно. А Netty ограничивает количество потоков до количества ядер используемых процессором и они работают постоянно
Логичный вывод: Настройки Томката по умолчанию для такого паттерна нагрузки на подходят.
Потоки можно не экономить. Они очень дешевые. https://habr.com/ru/post/562482/comments/#comment_23146166
Кроме увеличения количества потоков томкета вы могли написать код, используя асинхронные сервлеты, которые он поддерживет уже лет десять «из коробки», которые добавлялись в servlet-API 3.0 специально для поддержки неблокирующей обработки и тогда вся ваша статья теряет смысл.
Для полноты картины надо бы добавить к сравнению Servlet 3.1 имплементацию Spring MVC.
почему такой маленький рпс?
почему в стандартной реализации 23% ошибок?
Sign up to leave a comment.
Spring MVC vs Spring WebFlux. Что лучше? Объясняем на пингвинах