Тест 1.
Длительность 180 с.
Количество потоков 30.
Вариант 1. Cap-osgi и soapui на одной машине. (1.1.0.158)
Результат: tps ~ 95
Вариант 2. Сap-osgi на 1.1.0.158, soapui на 1.1.0.158
Результат: tps ~ 60
Тест 2.
Длительность 180 с.
Количество потоков 300.
Вариант 1.
Результат: tps ~ 85
Вариант 2.
Результат: tps ~ 75
При проведении тестов с этими и другими значениями количества потоков было обнаружено, что
1) Время выполнения функции process(), которая занимается пересылает сообщение к серверу и возвращает ответ, при первом запуске порядка 200+ мс, затем за 5-10 транзакций падает до 40 мс, и после этого стабилизируется на 8-18 мс.
При этом 95+% времени уходит на jdbcCall.execute(spParams) -- где идёт вызов хранимой процедуры в БД.
2) В PL/SQL Developer было обнаружено, что выбранная хранимая процедура, выполняется в среднем за 3мс.
3) Пинг (4КБ) 2-4 мс на первых 5-10 пакетах, и 1 мс на последующих.
4) Длина приходящего и исходящего сообщения меньше 512Б, поэтому для запроса и ответа формируется по одному TCP/IP пакету.
С учётом всего этого исполнение должно занимать 1+1 + 3 + 1+1 = 7 мс в лучшем случае, что близко к нижней полученной оценке времени обращения к бд.
ACCL-запрос в PL/SQL Developer отрабатывает за 42 мс ( в профилировщике), а аналогичный в SOAPUI выдаёт 32 tps (со временем снижается), что соответствует 32мс на запрос.
При проверке на FINA запросе с невалидными данными удерживалось время 7-9 мс, что давало 110+ tps.
Не учтено время, которое тратится на демаршаллинг входного запроса в объект CapReq, но оно пренебрежимо мало ( << 1 мс)
Было обнаружено, что одновременно в функции process могут находиться сколько-угодно потоков, причём со временем это количество растёт. Начиная от 1 потока вначале до 60-70 после 150 секунд. Причины не выявлены.
Проанализировав лог было обнаружено, что на роутинг сообщений уходит < 0.001 мс, так что учётом его можно пренебречь.
В итоге между TPS из SOAPUI и расчётными на основании полученного времени выполнения функции process существует погрешность в пределах 5% ( в SOAPUI было около 78, получил 13 мс в среднем => 1000/13 ~ 77 tps)
При большом времени нагрузочного тестирования результаты приближаются к теоретическому максимуму (7мс), но не достигают его.
Не учтено время, которое тратится на демаршаллинг входного запроса в объект CapReq, но оно пренебрежимо мало ( << 1 мс)
Было обнаружено, что одновременно в функции process могут находиться сколько-угодно потоков, причём со временем это количество растёт. Начиная от 1 потока вначале до 60-70 после 150 секунд. Причины не выявлены.
Проанализировав лог было обнаружено, что на роутинг сообщений уходит < 0.001 мс, так что учётом его можно пренебречь.
В итоге между TPS из SOAPUI и расчётными на основании полученного времени выполнения функции process существует погрешность в пределах 5% ( в SOAPUI было около 78, получил 13 мс в среднем => 1000/13 ~ 77 tps)
При большом времени нагрузочного тестирования результаты приближаются к теоретическому максимуму (7мс), но не достигают его.
Комментариев нет:
Отправить комментарий