Что такое нагрузочное тестирование и кто такой инженер-нагрузочник в ЮMoney

Не могли бы вы поделиться соображениями по следующему вопросу? Я не специалист в нагрузочном тестирование, поэтому заранее прошу простить мне мой обывательский взгляд на проблематику. Работаю в компании, где разработчик и швец, и жнец, и на дуде игрец... Учусь, перенимаю опыт.
Предположим у вас есть некое REST API, оно состоит из N методов. За вызовом каждого метода с вашей стороны стоит различное множество микросервисных взаимодействий (в т.ч. с источниками данных, интеграциями с внешними системами и т.п.) - соответственно средняя скорость и сложность выполнения у методов разная.
Каким образом вы моделируете нагрузку, чтобы построить гипотезы на тему "какое количество пользователей выдержит текущая реализация вашего REST API"?
Вижу такие варианты:
1. Использовать статистику частоты вызовов методов с production и скалировать пропорционально, сравнивать относительный прирост-падение производительности.
2. Принять частоту вызовов методов равномерной, далее по п.1
3. Выбрать самый медленный метод и принять его за бутылочное горлышко (не принимая в расчет частоту его вызовов), нагружать его и найти возможность улучшения до "средних по больнице" величин.
4. Сформировать пользовательские сценарии   - очередность вызова методов. Как быть с многоообразием таковых сценариев? Или этот пункт по факту сводится к пункту 1?

Было тут у меня давеча "нагрузочное тестирование" (ГА-ГА-ГА) и вот что получилось.
А знаете что было?
Да, было 10 (десять, прописью) загрузок платежного поручения из списка операций за 10 (десять!) минут. Одна платёжка в минуту (быстрее я не умею сохранять, т.к. надо правильно обозвать и правильно расположить).
И юMoney не справился. Совсем.