#http #tcp #jmeter #client-server #performance-testing
Вопрос:
У меня есть простой сценарий стресс-теста, который выполняется в течение 2 часов. Я настроил 3000 потоков для увеличения на протяжении всего теста. Это всего лишь один запрос POST HTTPS, повторяемый несколько раз с изменением данных тела json для каждого запроса. Клиент находится в одной системе, а сервер — в другой системе. Я просто вызываю API с некоторыми входными данными, и этот API ищет данные в файле и отвечает тем, что жестко запрограммировано для ответа.
Как возможно, что, хотя я продолжаю увеличивать количество потоков с течением времени, нагрузка на систему пропорционально не увеличивается?
Я спрашиваю об этом, потому что несколько дней назад при выполнении этого теста среднее время отклика увеличивалось пропорционально моему увеличению потоков (виртуальных пользователей). Теперь при выполнении того же теста это увеличение больше не происходит — вот почему сейчас я предполагаю, что разработчики установили некоторое максимальное ограничение TPS.
Это результат времени отклика с течением времени: 
Это общий TPS: 
Активные потоки со временем приводят: 
Пропускная способность в байтах с течением времени: 
Может кто-нибудь, пожалуйста, помочь мне понять, как это возможно? Кодов ошибок нет.
Кажется, что сервер каким-то образом ограничивает клиента, но я не понимаю, с помощью какого механизма, и я не знаю, какой график результатов jmeter показал бы мне более четкое доказательство этого. Я был бы признателен, если бы кто-нибудь мог помочь мне понять.
Комментарии:
1. Мне неясно, как выглядит ваша тестовая настройка (клиент и сервер в одной системе, разные системы, что сервер вообще делает при каждом запросе …), Но я бы предположил, что сервер — это не то, что ограничивает производительность. Вместо этого существуют более или менее постоянные задержки для каждого запроса, которые вызваны не сервером, а настройкой и видом тестов. Например, HTTP-запросы требуют нескольких обходов от начала до конца, тем более, если каждый запрос выполняется в новом TCP-соединении и даже больше с TLS. Такие задержки ограничивают производительность, независимо от того, насколько быстр сервер.
2. @SteffenUllrich Это всего лишь один запрос POST HTTPS, повторяемый несколько раз с изменением данных тела json для каждого запроса. Клиент находится в одной системе, а сервер — в другой системе. Несмотря на это, я просто вызываю API. Причина, по которой я спрашиваю об этом, заключается в том, что несколько дней назад при выполнении этого теста среднее время отклика увеличивалось пропорционально моему увеличению потоков (виртуальных пользователей). Теперь при выполнении того же теста это увеличение больше не происходит, поэтому теперь я предполагаю, что разработчики установили некоторое максимальное ограничение TPS…
3. Такой контекст (что он делает, как он выполнялся в прошлый раз — но, пожалуйста, с фактическими цифрами) должен быть частью вопроса, а не скрываться в комментарии. Кроме того, «вызов API» может означать просто повторное воспроизведение данных, дорогостоящее резервное копирование базы данных, обращение к другим системам для сбора данных… — все это по-разному влияет на производительность. Без этой важной информации можно было бы только дико гадать, какой здесь может быть предел.
4. Спасибо. Я обновил вопрос в соответствии с вашим предложением. Вы можете видеть цифры на картинках. У меня нет данных из предыдущих запусков. Дайте мне знать, если вы считаете, что я могу предоставить любую другую информацию. Я думаю, мне также могут помочь некоторые предположения.
Ответ №1:
Вы показываете результаты разных выполнений тестов, поэтому мы не можем их правильно сопоставить, т.Е. Время отклика начинается с 23:15 , а 2 других графика заканчиваются 23:01 .
В целом пропускная способность исправной системы должна увеличиваться пропорционально увеличению нагрузки. Если этого не происходит — этому должно быть объяснение, т.е.
- Время отклика увеличивается, попробуйте посмотреть время отклика на время между
22:23и23:01 - JMeter не может отправлять запросы достаточно быстро, обязательно следуйте рекомендациям JMeter и контролируйте ресурсы ваших генераторов нагрузки, такие как CPU, RAM и т.д., Используя, например, плагин JMeter PerfMon
- Приложение не может отвечать достаточно быстро из-за ограничений конфигурации или реализации, проверьте, что происходит под капотом вашего вызова API, используя APM или инструмент профилировщика
- Тот факт, что JMeter не сообщает об ошибках, не обязательно означает, что ошибок нет, ваше приложение может отвечать кодом состояния HTTP 200, но в теле содержатся сведения об ошибках, поэтому имеет смысл посмотреть, например, на график пропускной способности во времени, чтобы увидеть, растет ли объем передаваемых данных по мере прибытия пользователей. Вы также можете рассмотреть возможность добавления утверждений к вашим запросам, чтобы убедиться, что ваш тест выполняет то, что он должен делать
Комментарии:
1. Спасибо, Дмитрий. Что касается графиков, это была ошибка с моей стороны, извините. Теперь я обновил содержимое вопроса результатами того же выполнения. Теперь все графики начинаются с 23:15. Я обязательно проверю предоставленные вами ссылки. Как всегда, ваши наблюдения и ответы потрясающие!
Ответ №2:
Проблема может быть вызвана тем, что клиент ограничивает фактическое количество выполненных потоков. Другими словами, потоки могут стоять в очереди у генератора нагрузки. Подробное объяснение см. В разделе Dr. Gunter Как получить невероятные результаты нагрузочных тестов, в частности в разделе 4.4 Threads That Throttle . В документе показан метод, использующий закон Литтла для оценки фактического количества выполненных потоков.