Неблокирующий Tomcat? Зачем такие сложности? А приготовили точно правильно? Если бы мы его готовили неправильно, то думаю под 25000 RPS он бы совсем не работал. В любом случае этот тест проводился около 2 лет назад. Сейчас мы перешли на undertow.
В примере 2 не раскрыто на чем скорость +15% Сравнивали по двум показателям:
Среднее значение графиков нагрузки на CPU
Flamegraph из async-profiler
Может вы в реактивной части сильно много объектов создаёте? Может на каждую операцию у вас новый map/flatMap и т.д.? А в императивном стиле завернули это все в 3-4 метода и рады росту скорости? Это всё возможно, но только если речь про код spring/tomcat. Если же говорить про наш код, который отвечает за нашу бизнес логику, то изменения в нём были минимальные и не влияли на производительность.
Вы и правы и не правы одновременно. Если использовать спринг так, как написано в его документации (через @RestController и пр.), то да, для наших задач его производительности не хватает. Однако это можно решить. Например можно сделать так, чтобы запросы в функцию, которая создаёт основную нагрузку, шли "мимо" спринга напрямую в tomcat/undertow/jetty. А все остальные запросы к другим функциям, которые нагрузки не имеют, работали как обычно. Тогда мы с одной стороны сохраняем всё удобство спринга (кроме 1 функции), а с другой - имеем время работы менее 1мс под нагрузкой.
1 мс на вычисления выглядит, конечно, невероятно круто для спринга Да, если готовить спринг так, как написано в его документации (через @RestController и пр.), то производительность деградирует очень сильно. Нам пришлось использовать разные полу-легальные хаки для того, чтобы заставить его работать быстро.
100-150 "активных" это явный артефакт сбора статистики. Возможно. Мы брали метрики прямо из нашего пула потоков.
Правильно я понимаю, что во втором примере у вас были в основном cpu-bound задачи, поэтому обычная многопоточка, которая даёт попроще распарралелить задачи на ядра, дала больше оптимизации, нежели асинхронка, которая больше нацелена на io-bound задачи? Да, верно
И приходим мы к тому что реактив по сути нужен там, где io-bound, scheduled задачи, которые большинство времени держат потоки в состоянии sleep/wait, а там, где cpu-bound задачи, нам нужен параллелизм через классическую многопотчку в жабке? В нашем случае получилось так
сколько занимает обработка одного запроса? 200мс на 95 процентиле
звучит как будто у вас 500 ядер были загружены. Нагрузка на CPU ~25%
И если в модели "один запрос - один поток" вам хватало 2000 потоков на таком количестве ядер, то это выглядит скорее как CPU-bound нагрузка, что не бьётся с "ждут ответа своих соседей". Если же ядер в сервере сильно меньше 500, то асинхронщину вы как-то неправильно приготовили. Количество потоков в идеале должно быть примерно равно количеству ядер. Условно, если у вас 32 или 64 ядра, то 500 потоков не сильно лучше 2000, куча времени будет тратиться на ворочание тредами. Но это не бьётся уже с утверждением "все чем-то занимались". Большая часть потоков в такой кофигурации может заниматься только ожиданием.
Поток веб-сервера, который обрабатывает http-запрос, мы не блокировали. Вместо этого у нас был отдельный пул потоков, который занимался обработкой http запросов и ожиданием ответов от соседей. Размер этого пула у нас был выставлен в 2000 с запасом, но в каждый момент времени активно было не более 100-150. Оставшиеся потоки или ожидали ответов или были неактивны.
Эта реализация была изменена в пользу отказа от пула потоков и отказа от блокировок при ожидании ответов.
Есть разные исследования о том, что такая субъективная оценка, как уровень счастья, у людей в целом выравнивается где-то в районе "чуть выше среднего" (исследования сейчас не найду). Причем, жизненные изменения его сдвигают ненадолго, а потом человек адаптируется и все возвращается на первоначальный уровень... так что вероятно, опрос будет не очень-то показателен.
Как это не банально, Zoom в основном. В каждом из выделенных пунктов много общения.
Кадровый подбор - там есть своя автоматизация. Мы ее постоянно доделываем и переделываем, совершенствуем. Подстраиваемся под рынок. Нет устоявшейся схемы. Уже несколько раз порывались рассказать о результатах, но к тому моменту, когда заканчивали тестирование одной схемы, уже появлялись мысли, как все построить лучше. Так что рассказ каждый раз откладываем.
Общение с клиентами по проектам - это переговорный процесс.
Декомпозиция задач - тут в каждой команде применяют свою привычную схему. Можем о них рассказать, если интересно. Один из наших бывших коллег когда-то рассказывал о своем подходе - https://habr.com/ru/companies/maxilect/articles/489604/.
ППА не окупает усилий, особенно по созданию каких-то узкоспециализированных текстов (когда теме без шансов набрать даже 10 тыс. просмотров, просто потому что интересующихся этой сферой мало). Если начинаются колебания "знаю и могу в эту тему, но написание для себя конфликтует с работой", то ППА точно не станет аргументом в пользу варианта "отложить работу и все-таки написать статью". Если только случайно прилетит за статью, созданную в порыве самореализации.
Статьи в портфолио тоже работают плохо, потому что у каждой компании свои задачи. Проще договариваться с текущим заказчиком о том, чтобы показывать работы в качестве примеров для будущих заказчиков (и всегда сопровождать их описанием задачи, которая была поставлена... потому что без описания внешних условий это бизнесу не очень интересно).
Но спрос на качественный контент есть. И аудитория большая. А раз есть аудитория, значит будут и те, кто заплатит за создание этого контента.
Мне кажется из-за этого "заказных" статей должно со временем становиться больше. Может их уже стало больше, просто их публикуют из под личных аккаунтов и грамотно "прячут" там нативную рекламу - так что это не расценивается модераторами как коммерческое использование. И не вижу в этом ничего плохого. Так что где-то в пределе (мне кажется) Хабр будет подборкой блогов, внутри каждого из которых есть свой "заказчик" статей, который за них и платит. Типа подборка журналов с некими общими элементами подачи.
Спасибо за пояснения. Снаружи детали не разглядеть:) Интересно, можно ли цифрами как-то подтвердить или опровергнуть мою гипотезу о том, что статьи - хорошая площадка для обсуждений вместо очных конференций? Понятно, что сложные перетекания аудитории не отследить... но со временем комментариев к лонгридам технической направленности (в каких-то определенных хабах, допустим) становится больше?
Рассматривали. Согласен с вами, что наверное на Ардуино можно добиться большего времени автономной работы и более компактных размеров. Однако для этого похоже придётся переписать весь OpenAPS... Для нас проще использовать готовое решение, хоть оно и не идеально.
За два года использования к нему нет никаких нареканий (за исключением того, что я описал в статье). Свою основную задачу выполняет стабильно. Главное держать его где-нибудь неподалёку от себя и не забывать ставить на ночь на зарядку. В целом здесь работает принцип "Настроил и забыл".
Запланировали чуть позже опубликовать еще статью на эту тему с подробными ответами на вопросы.
Неблокирующий Tomcat? Зачем такие сложности? А приготовили точно правильно? Если бы мы его готовили неправильно, то думаю под 25000 RPS он бы совсем не работал. В любом случае этот тест проводился около 2 лет назад. Сейчас мы перешли на undertow.
В примере 2 не раскрыто на чем скорость +15% Сравнивали по двум показателям:
Среднее значение графиков нагрузки на CPU
Flamegraph из async-profiler
Может вы в реактивной части сильно много объектов создаёте? Может на каждую операцию у вас новый map/flatMap и т.д.? А в императивном стиле завернули это все в 3-4 метода и рады росту скорости? Это всё возможно, но только если речь про код spring/tomcat. Если же говорить про наш код, который отвечает за нашу бизнес логику, то изменения в нём были минимальные и не влияли на производительность.
Вы и правы и не правы одновременно. Если использовать спринг так, как написано в его документации (через
@RestControllerи пр.), то да, для наших задач его производительности не хватает. Однако это можно решить. Например можно сделать так, чтобы запросы в функцию, которая создаёт основную нагрузку, шли "мимо" спринга напрямую в tomcat/undertow/jetty. А все остальные запросы к другим функциям, которые нагрузки не имеют, работали как обычно. Тогда мы с одной стороны сохраняем всё удобство спринга (кроме 1 функции), а с другой - имеем время работы менее 1мс под нагрузкой.1 мс на вычисления выглядит, конечно, невероятно круто для спринга Да, если готовить спринг так, как написано в его документации (через
@RestControllerи пр.), то производительность деградирует очень сильно. Нам пришлось использовать разные полу-легальные хаки для того, чтобы заставить его работать быстро.100-150 "активных" это явный артефакт сбора статистики. Возможно. Мы брали метрики прямо из нашего пула потоков.
Правильно я понимаю, что во втором примере у вас были в основном cpu-bound задачи, поэтому обычная многопоточка, которая даёт попроще распарралелить задачи на ядра, дала больше оптимизации, нежели асинхронка, которая больше нацелена на io-bound задачи? Да, верно
И приходим мы к тому что реактив по сути нужен там, где io-bound, scheduled задачи, которые большинство времени держат потоки в состоянии sleep/wait, а там, где cpu-bound задачи, нам нужен параллелизм через классическую многопотчку в жабке? В нашем случае получилось так
Ядер-то у вас сколько на сервере? 16/32
Какая нагрузка в RPS? ~25000
сколько занимает обработка одного запроса? 200мс на 95 процентиле
звучит как будто у вас 500 ядер были загружены. Нагрузка на CPU ~25%
И если в модели "один запрос - один поток" вам хватало 2000 потоков на таком количестве ядер, то это выглядит скорее как CPU-bound нагрузка, что не бьётся с "ждут ответа своих соседей". Если же ядер в сервере сильно меньше 500, то асинхронщину вы как-то неправильно приготовили. Количество потоков в идеале должно быть примерно равно количеству ядер. Условно, если у вас 32 или 64 ядра, то 500 потоков не сильно лучше 2000, куча времени будет тратиться на ворочание тредами. Но это не бьётся уже с утверждением "все чем-то занимались". Большая часть потоков в такой кофигурации может заниматься только ожиданием.
Поток веб-сервера, который обрабатывает http-запрос, мы не блокировали. Вместо этого у нас был отдельный пул потоков, который занимался обработкой http запросов и ожиданием ответов от соседей. Размер этого пула у нас был выставлен в 2000 с запасом, но в каждый момент времени активно было не более 100-150. Оставшиеся потоки или ожидали ответов или были неактивны.
Эта реализация была изменена в пользу отказа от пула потоков и отказа от блокировок при ожидании ответов.
Есть разные исследования о том, что такая субъективная оценка, как уровень счастья, у людей в целом выравнивается где-то в районе "чуть выше среднего" (исследования сейчас не найду). Причем, жизненные изменения его сдвигают ненадолго, а потом человек адаптируется и все возвращается на первоначальный уровень... так что вероятно, опрос будет не очень-то показателен.
Мейнстрим или нет - не знаем, но для нас фича была очень необходима, т.к. не хватало встроенных в базу функций.
У нас соотношение между количеством запросов в систему извне и количеством INSERT'ов в базу не 1 к 1.
Как это не банально, Zoom в основном. В каждом из выделенных пунктов много общения.
Кадровый подбор - там есть своя автоматизация. Мы ее постоянно доделываем и переделываем, совершенствуем. Подстраиваемся под рынок. Нет устоявшейся схемы. Уже несколько раз порывались рассказать о результатах, но к тому моменту, когда заканчивали тестирование одной схемы, уже появлялись мысли, как все построить лучше. Так что рассказ каждый раз откладываем.
Общение с клиентами по проектам - это переговорный процесс.
Декомпозиция задач - тут в каждой команде применяют свою привычную схему. Можем о них рассказать, если интересно. Один из наших бывших коллег когда-то рассказывал о своем подходе - https://habr.com/ru/companies/maxilect/articles/489604/.
Договоренности - про некоторые внутренние правила у нас была статья о коммуникациях (https://habr.com/ru/companies/maxilect/articles/479518/)
Или интересует инструмент для решения какой-то конкретной задачи?
Да, естественно. В последней части специально указали, что все это - исключительно добровольно.
По поводу управления... Если имеется в виду — сильнее жмёшь быстрее едет, то да. Как я уже писал для этого делал ограничитель скорости до 50%.
По поводу итоговой цели - это философский вопрос. Наверное, да. Персональный челлендж.
Кастор подразумевает подвеску. Как я уже писал у этой версии нет подвески.
Пробовал разные сочетания, но как уже писал, идеальное сочетание - PLA-SBS
Да, именно NRF24L01+ -- 2.4GHz radio module
Отслеживание на несколько другом уровне. Иногда спрашиваем снаружи: "Читали ли вы о нас?".
Могу ответить лично от себя (как я это вижу).
ППА не окупает усилий, особенно по созданию каких-то узкоспециализированных текстов (когда теме без шансов набрать даже 10 тыс. просмотров, просто потому что интересующихся этой сферой мало). Если начинаются колебания "знаю и могу в эту тему, но написание для себя конфликтует с работой", то ППА точно не станет аргументом в пользу варианта "отложить работу и все-таки написать статью". Если только случайно прилетит за статью, созданную в порыве самореализации.
Статьи в портфолио тоже работают плохо, потому что у каждой компании свои задачи. Проще договариваться с текущим заказчиком о том, чтобы показывать работы в качестве примеров для будущих заказчиков (и всегда сопровождать их описанием задачи, которая была поставлена... потому что без описания внешних условий это бизнесу не очень интересно).
Но спрос на качественный контент есть. И аудитория большая. А раз есть аудитория, значит будут и те, кто заплатит за создание этого контента.
Мне кажется из-за этого "заказных" статей должно со временем становиться больше. Может их уже стало больше, просто их публикуют из под личных аккаунтов и грамотно "прячут" там нативную рекламу - так что это не расценивается модераторами как коммерческое использование. И не вижу в этом ничего плохого.
Так что где-то в пределе (мне кажется) Хабр будет подборкой блогов, внутри каждого из которых есть свой "заказчик" статей, который за них и платит. Типа подборка журналов с некими общими элементами подачи.
Спасибо за пояснения. Снаружи детали не разглядеть:) Интересно, можно ли цифрами как-то подтвердить или опровергнуть мою гипотезу о том, что статьи - хорошая площадка для обсуждений вместо очных конференций? Понятно, что сложные перетекания аудитории не отследить... но со временем комментариев к лонгридам технической направленности (в каких-то определенных хабах, допустим) становится больше?
Рассматривали. Согласен с вами, что наверное на Ардуино можно добиться большего времени автономной работы и более компактных размеров. Однако для этого похоже придётся переписать весь OpenAPS... Для нас проще использовать готовое решение, хоть оно и не идеально.
За два года использования к нему нет никаких нареканий (за исключением того, что я описал в статье). Свою основную задачу выполняет стабильно. Главное держать его где-нибудь неподалёку от себя и не забывать ставить на ночь на зарядку. В целом здесь работает принцип "Настроил и забыл".