Клієнт не завжди правий (JMeter)

Привіт друзі! Як ви могли помітити, мене дуже цікавить тема тестування продуктивності (performance testing). Дуже цікавить тема порівняння тулів для тестування навантаження за різних умов (про що вже готую пости). Поміж іншим, вже деякий час не дає покою питання, наскільки реалізація клієнта впливає на тестування (як тільки прочитав, що в черговій версії Locust буде реалізовано fastHttp клієнт). Тому вирішив провести низку тестів одного продукту одним тулом, але з різними налаштуваннями.

І почати хочу з JMeter – я вибрав для нього 4 тести. Перші 2 – за замовчанням http sampler може використовувати HttpClient4 (має бути по замовчанню) чи Java.

http sampler client implementation

Ще одне питання – якщо ми навантажуємо статичну сторінку, наскільки кешування впливає на результати тесту? В налаштуваннях Thred Group можна відключити опцію за замовчанням – Same user on each iteration:

Тому я розробив простий тест: 1 запит головної сторінки, 3000 користувачів, 150 сек, ніяких затримок між запитами.

Test PCTarget server (NAS)Network
CPU AMD Ryzen 7 4800H 2.9 Ghz
RAM 16 Gb
Windows 10 2004 Pro x64
Java 8
CPU Intel Celeron J1900 2 Ghz
RAM 8 Gb
Nginx official docker image
100 Mbps
Конфігурація середовища

Результати тесту наступні:

TestThroughput, rpsresponse time, msErrors, %
HttpClient4 + Same user on613911410
HttpClient4 + Same user off113060826
Java+ Same user on47475060.46
Java+ Same user of35771373.32

Які висновки я роблю з тестів?

  1. Кешування сесії значно впливає на результат. Якщо у вас є необхідність нагенерячити якомога-більше унікальних запитів, а ресурсів на велику кількість користувачів чи розподілене тестування немає, то кешування варто вимкнути, але це призведе до зменшення продуктивності
  2. Жоден з проведених тестів не дає відповіді на головне питання – яка ж продуктивність сервісу, що тестувався. Тобто, незважаючи на можливості JMeter з навантаження з одного комп’ютера, результати нерепрезентативні. Щоб дійсно дізнатись продуктивність, треба провести розподілений тест з 2-3 машин.
  3. Java клієнт за одних і тих самих умов може видати менше навантаження, але при цьому в тесті буде менше помилок типу тих, що отримав я: NoHttpResponseException – failed to respond, SocketException – Connection reset, HttpHostConnectException – Connection timed out, BindException – Address already in use

Ще один висновок не слідує напряму з вказаних вище тестів, але пов’язаний з попередньою статтею, що я писав. В ній я тестував продуктивність Flask веб сервісу і він виявився в 10 разів менший за тестування статичної сторінки. Тобто ресурси JMeter фізично дозволяють робити велике навантаження навіть з одного комп’ютера. І воно буде тим більшим, чим продуктивніше працює веб сервіс. В зв’язку з чим в мене тепер є питання до читачів:

  • якщо ви проводите тестування навантаження, ви частіше тестуєте веб сервіси чи статику?
  • якщо не секрет, який зазвичай продуктивність веб сервісів/систем, що ви тестуєте? З мого досвіду тестування мікросервісів, зазвичай throughput в діапазоні від 1 до 1000 на DEV середовищі

Невеличкий спойлер – нарешті поставив собі другою системою Ubuntu – планую провести ті самі тести там, бо люди кажуть, що там трава зеленіша все працює краще. Вам цікаво?

Позначки:,
8 Вересня 2020
Автор: 
  • Summer Data Science School – Free
  • Різдвяне привітання
  • CTFL 3. Static testing
  • Regression Obsession

Залишити коментар

Залишити вiдгук