Подбором.
И касательно облаков - с ними не всё так просто.
Например, пусть в облаке на выбранном тарифе есть квота на длительность высокой доступности диска. И в первый час работы диск работает быстро, а во второй час и последующие - работает вдруг медленно.
Единственное в чем можно быть уверенным, так это в оперативной памяти. Она в облаке не плавает.
А рассчитать необходимое количество ОЗУ надо от количества потоков, которые будут выполняться во время теста.
Нужно провести пробные тесты, замониторить, сколько оперативной памяти необходимо для выбранного профиля нагрузки. Метод оценки такой - если приложение не упало в java.lang.OutOfMemoryError: Java heap space и время отклика в JMeter и по логам сервера пости совпадают (JMeter не тормозит), то памяти ему достаточно.
А если будет что-то такое:
$ ./run.sh ./script.01.Thread_Group.jmx --nongui
Creating summariser <summary>
Created the tree successfully using ./script.01.Thread_Group.jmx
Starting the test @ Mon Oct 01 17:21:27 MSK 2018 (1538403687382)
Waiting for possible Shutdown/StopTestNow/Heapdump message on port 4445
summary + 19 in 00:00:02 = 7.7/s Avg: 0 Min: 0 Max: 2 Err: 0 (0.00%) Active: 1 Started: 10 Finished: 9
summary + 256 in 00:00:30 = 8.6/s Avg: 0 Min: 0 Max: 12 Err: 0 (0.00%) Active: 2 Started: 139 Finished: 137
summary = 275 in 00:00:32 = 8.5/s Avg: 0 Min: 0 Max: 12 Err: 0 (0.00%)
summary + 498 in 00:00:30 = 16.6/s Avg: 0 Min: 0 Max: 2 Err: 0 (0.00%) Active: 3 Started: 389 Finished: 386
summary = 773 in 00:01:02 = 12.4/s Avg: 0 Min: 0 Max: 12 Err: 0 (0.00%)
summary + 738 in 00:00:30 = 24.6/s Avg: 0 Min: 0 Max: 19 Err: 0 (0.00%) Active: 2 Started: 757 Finished: 755
summary = 1511 in 00:01:32 = 16.4/s Avg: 0 Min: 0 Max: 19 Err: 0 (0.00%)
summary + 976 in 00:00:30 = 32.6/s Avg: 0 Min: 0 Max: 17 Err: 0 (0.00%) Active: 2 Started: 1245 Finished: 1243
summary = 2487 in 00:02:02 = 20.3/s Avg: 0 Min: 0 Max: 19 Err: 0 (0.00%)
summary + 1214 in 00:00:30 = 40.4/s Avg: 0 Min: 0 Max: 1 Err: 0 (0.00%) Active: 4 Started: 1854 Finished: 1850
summary = 3701 in 00:02:32 = 24.3/s Avg: 0 Min: 0 Max: 19 Err: 0 (0.00%)
summary + 1454 in 00:00:30 = 48.5/s Avg: 0 Min: 0 Max: 2 Err: 0 (0.00%) Active: 3 Started: 2580 Finished: 2577
summary = 5155 in 00:03:02 = 28.3/s Avg: 0 Min: 0 Max: 19 Err: 0 (0.00%)
summary + 1684 in 00:00:30 = 56.1/s Avg: 0 Min: 0 Max: 2 Err: 0 (0.00%) Active: 8 Started: 3427 Finished: 3419
summary = 6839 in 00:03:32 = 32.2/s Avg: 0 Min: 0 Max: 19 Err: 0 (0.00%)
summary + 488 in 00:00:30 = 16.1/s Avg: 2 Min: 0 Max: 361 Err: 0 (0.00%) Active: 155 Started: 3818 Finished: 3663
summary = 7327 in 00:04:03 = 30.2/s Avg: 0 Min: 0 Max: 361 Err: 0 (0.00%)
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid21386.hprof ...
Heap dump file created [2723488978 bytes in 41,828 secs]
Killed
То видно, что приложение жило до отметки Active: 155. Возможно, при 200-ти потоках JMeter тоже будут чувствовать себя хорошо. И тут надо подобрать.
Если настраиваете профиль через шаг нагрузки, как в HP LoadRunner, используя Constant Throughput Timer или Precise Throughput Timer, то можно как поступить:
1. Рассчитать полный профиль и все параметры для достижения нужной интенсивности, например, по руководству
https://loadtestweb.wordpress.com/2017/08/23/pacing/ - пусть получилось 600 потоков нужно
2. Опытным путём определить, что станция с 4 ГБайт памяти под Heap Apache.JMeter вытягивает 200 потоков.
3. Рассчитываем количество станций, как 600 / 200 = 3