Comments 5
Полезная статья. Взяли пару моментов в работу.
Видно, что изначальная задумка статьи хорошая, но толи джуна посадили статью писать, толи опыта не хватает в этой области и как итог получилось куце, без внятной экспертизы, с ошибками и уходом "не в ту сторону".
Вот несколько пунктов, за которые можно придраться:
1) Составление профиля (взяли очень низкую цифру по оп\ч за 100% от профиля НТ). Как бы системы не работают в активной фазе все 30 дней месяца и 24 часа в сутки. Куда логичнее взять 20 рабочих дней (а лучше еще меньше) и 5-6 рабочих часов (или еще меньше).
2) Мониторинг нормальный где?
3) Без обширного мониторинга, покрывающего бизнес\аппаратные\программные и метрики БД с брокерами не будет нормальной аналитики и, как следствие, экспертизы.
4) А что творилось в логах приложения? То что на запросы приходило 200 ОК - еще не является показателем того, что с обработкой данной транзакции все было действительно хорошо.
5) "Максимальная производительность системы определяется как нагрузка, при которой утилизация ресурсов (CPU и RAM) начинает превышать допустимые границы, указанные в разделе "Требования по утилизации ресурсов"." Кому-то следует явно подучить теорию НТ.
Естественно, их тут сильно больше и все их описывать мне лень. Безусловно, эта статейка сильно лучше той, которую я читал в июле, где то ли разработчик, то ли AQA инженер проводил свой "нагрузочный тест", но расти Вам еще есть куда. Успехов! Ну, или обращайтесь к профильным специалистам))
lHumaNl статья сделана в образовательных целях и не претендует на истину в последней инстанции, мы постарались показать, что нагрузочное тестирование - это не нечто сложное и непонятное:
1) вы в праве для вашего приложения выбрать свой профиль
2) настройка мониторинга за рамками этой статьи, конечно же он необходим и в нашем случае это был prometheus + grafana
3) конечно!
4) логи приложения тоже отслеживались и фиксировались и также пошли в работу
5) для практического применения наш вариант нам показался более подходящим :)
Спасибо за комментарий по делу!
"нагрузочное тестирование - это не нечто сложное". Тут все зависит от того, как его проводить. Если оно проводится для профанации или инженер умеет только "тестики гонять", то да... Проблема в том, что НТ - это далеко не только подача нагрузки на сервис и "посмотреть" на графики CPU\RAM. Тут куда более комплексный порядок действий, который еще и сильно разнится в зависимости от проекта и стека. Не просто же так инженеры НТ получают ЗП, которая приближена к ЗП разработчиков и сидят fulltime на одном проекте (а зачастую и отдельной командой в несколько человек). Видимо, не так-то оно все и просто))
А теперь по вашим ответам:
1) Это так не работает. Профилей может быть действительно много (профиль выходного дня\ночной\джобы\закрытие года\промо акции и тд), но для каждого расчет его идет явно, а не "я вот так захотел". Вы рассчитали профиль так, будто бы на ваше приложение идет однородная активная нагрузка 24\7 (вы поделили 30 000 000 на 30 дней и 24 часа). Даже гугловые сервера не работают в таком режиме (в интернете есть их даши). Как минимум, надо понять для начала, примерный период активной фазы работы системы с наибольшей нагрузкой на нее, а дальше уже от этого "прыгать". Прогноз - это всегда очень каверзная вещь и занизить профиль может быть очень чревато после выхода сервиса в ПРОМ. Это внутренний сервис компании? Ну, скорее всего он будет работать только в рабочие дни (20 рабочих дней) и 8 рабочих часов (а в реальности и того меньше). Это сервис доставки? Пики нагрузки будут приходить на пятницу вечер, субботы и в будни в период обеда. Эту тему можно долго обсуждать, но я веду к тому, что это не делается по принципу "мне так захотелось". Должно быть обоснование и согласование с аналитиками, как минимум, чтобы потом, в случае ошибки прогноза к вам не пришли с вопросами. Даже в моем предложенном варианте, базовый профиль имеет интенсивность в более чем три раза относительно Вашего и он все еще занижен.
2) Я не говорил про ее настройку. Она может сильно разнится от стека на проекте. Могут быть только какие-то базовые советы, но я и не их имел ввиду. Я говорил про то, где сам мониторинг приложения и того, что за ним? У Вас даже аппаратных метрик почти нет. Утилизация CPU\RAM - это вообще не мониторинг. Если вы делаете статью в образовательных целях, то вот это было бы ооочень кстати. У вас же JVM приложение, а значит подцепив к нему micrometer, можно было бы отправлять в тот же prometheus уже не малое количество метрик. С JMeter также было бы неплохо отправлять метрики в Prometheus и визуализировать их в Grafana, а не в GUI (так никто не делает по огромному количеству причин). А БД есть в сервисе? А брокеры? Их также требуется мониторить. Приложение нативно установлено или же в k8s? Если контейнеризировано, то тут еще добавляются метрики оркестратора. И еще и еще много чего. (Одно это уже не просто в плане оценки и поиска текущих и потенциальных "узких мест", а также локализации проблем и дефектов)
3) Если Вы согласны с этим, то Вы также должны согласиться, что экспертизы и образовательного тут минимум.
4) Если статья образовательная, то такой важным момент также требуется описать, тк многие проблемы, не редко, можно проанализировать именно через логи и далеко не все проблемы можно увидеть на графиках.
5) Есть теория НТ и конкретные методики проведения нагрузочных испытаний. Есть четкое определение "максимальной" и "пиковой" производительности. На разных фин-тех проектах они могут чуть иначе называться или слегка отличаться в определениях, но сама суть нигде не меняется.
Я очень скептически отношусь к статьям на манер "Все НТ в одной статье", тк тема эта крайне обширна. Какие-то отдельные ее разделы\советы\best practice описывать - да. Или "вот у нас была проблема на ПРОМе и с помощью таких подходов в рамках НТ мы ее решили". Но не, вот вам гайд, как с нуля начать проводить в НТ внутри проекта бесплатно и без СМС.
Нагрузочное тестирование в разработке веб-приложений