Comments 10
а мы на дотнете нечто подобное нагородили, внедряем потихоньку.
Насколько я понимаю, проблема с торможением сервиса вызвана тормозами БД-х и зависимых сетевых сервисов.
Соответственно, мы меняем логику работы нашего сервиса, чтобы уменьшить зависимость от замедления наших зависимостей. И соответственно нам нужны не JMH тесты, а юнит тесты, которые воспроизводят ситуации:
зависимые сервисы работают с соблюдением SLO, значит мы получаем данные из них, и наш SLA не нарушается
зависимые сервисы работают с нарушением SLO, значит мы включаем альтернативу, например, получаем данные из кешей, и опять же наш SLA не нарушается.
При этом использование нагрузочных тестов (пусть даже JMH, хотя и странно ;) тоже полезно, чтобы убедиться, что помимо правильной логики, сервис не падает под нагрузкой.
Про юнит тесты согласен, но вычислять среднее арифметическое времени вызовов - там нужно думать как это делать, чтобы не собрать велик)
По поводу нагрузочного тестирования - безусловно его нужно проводить, но на практике его проводят только в случае мажорных релизов или в экстренных ситуациях, после решения таких вот проблем, чтобы проверить фиксы разработчиков.
Так и не понял, зачем нам средне-арифметическое, если сервис зависит от прочих сетевых сервисов, и БД. Большая часть ожидания будет от сети. А если мерить работу всех компонент, то надо разворачивать максимально приближенно к проду. Т.е. стартуем приложение, а не внутри jmh гоняем маленький кусок кода.
По поводу теста целиком - указано в дисклеймере. Зачем нужно среднее арифметическое? Предположим, часть вызовов потом закешируют на рефакторинге, например. Тогда нужно гонять логику несколько раз, чтобы не попасть в кеш (фиче тогл, например, забыли прикрутить на отключение кеша). Плюс надо также учитывать факторы холодного старта и прочее. Конечно, можно попросить организовать Нагрузочное тестирование, но на каждый чих его делать затратно, а если проблем перфоманса вагонетка, то желательно их постепенно тестировать до Нагрузочного. Можно, конечно, попросить QA погонять рест десяток раз, но не лучше ли автоматизировать это тестом? Можно и юнит тестом, но это не так рационально, когда для этого есть соответствующие инструменты.
Использовать UUID в качестве индетификатора не лучшая идея, создание UUID операция медленная и блокирующая
Это вообще антипаттерн для хайлоад, никак не могу отучить разрабов от его использования.
Пишем тесты производительности под Webflux