Performance of Performance Testing tools

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Минулого року я брав участь в конференції QA Fest 2019 та презентував свої дослідження з порівняння додатків для тестування навантаження. Моєю метою було підготувати середовище та виконати однакові набори тестів для Locust, Gatling та JMeter, порівняти, наскільки релевантні їх результати та скільки ресурсів їм треба для роботи. Хто хоче, може подивитись відео доповіді:

Чому я вибрав саме ці 3 тули проміж десятків інших? Мої основні критерії:

• Є безкоштовним
• Має велику спільноту і нормальну документацію
• Може генерувати навантаження в 10 000 користувачів
• Підтримує без болі та страждань транзакційність (дані з одного респонсу веб серверу можуть бути використані в наступному реквесті)

Тож я провів тести, записав результати і презентував їх. Але сам лишився не дуже задоволений проведеною роботою — JMeter згенерував безліч помилок в процесі роботи, результати тестів для всіх тулів відрізнялись і взагалі — майже за рік оновились версії ОС та фреймворків — чому б не провести роботу над помилками тести ще кілька разів?

Мета

Setup

Locust

pip install locust

Gatling

• Java 8+
• Scala 2.12 (саме така версія)
• Apache Maven (опціонально)
• Gatling binaries

JMeter

Що тестувати?

Весь код сервера:

from flask import Flask, escape, request, send_file

app = Flask(__name__)

@app.route('/')
def hello():
    name = request.args.get("name", "World")
    return f'Hello, {escape(name)}!'

@app.route('/access.log')
def access_log():
    return send_file('access.log', cache_timeout=-1)

Уважні читачі можуть помітити, що в коді 2 ендпоінта — другий я додав, щоб виводити access.log і перевіряти, чи справді всі мої запити досягли серверу.

Докер файл:

FROM python:3.7-alpine
COPY perf_target.py /app/perf_target.py
WORKDIR /app
RUN pip install --upgrade pip && pip install flask gunicorn
EXPOSE 8888
CMD gunicorn -w 4 -b 0.0.0.0:8888 --access-logfile access.log perf_target:app

Test Configuration

• CPU AMD Ryzen 7 4800H 2.9 Ghz
• RAM 16 Gb
• Windows 10 2004 Pro x64
• Java 8
• Scala 2.12
• Python 3.8

• CPU Intel Celeron J1900 2 Ghz
• RAM 8 Gb
• Flask WS in Docker python:3.7-alpine 4 Gb RAM

• 100 Mbps (за найповільнішою ланкою в моїй домашній мережі)

Додаткова передумова, до якої я прийшов пізніше, і яка змусила мене переробити тести — додати значення в реєстр Windows, що дозволяє ОС збільшити ліміт мережевих підключень. Без нього «важкі» тести ламаються через неможливість створити мережеве з’єднання:

Name: MaxUserPort
Type: DWORD 
Value: 65534 decimal
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Тестові сценарії

Код тестів

from locust import HttpUser, task, between


class WebsiteUser(HttpUser):
   host = 'http://192.168.2.136:8888/'
   wait_time = between(1, 2)

   @task
   def posts(self):
       self.client.get("/")

package Sample

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._


class MaxPerformance extends Simulation {

  val httpProtocol = http
    .baseUrl("http://nas:8888")

  val scn = scenario("max performance")
    .forever(exec(http("simple get")
      .get("/"))
      .pause(1 second, 2 seconds))

  setUp(scn.inject(rampUsers(10000) during (20 seconds), nothingFor(2 minutes)))
    .pauses(normalPausesWithStdDevDuration(2 seconds))
    .maxDuration(180 seconds).protocols(httpProtocol)
}

JMeter

І щоб уникнути непорозумінь — запускав тест я з консолі, як радить офіційна документація:

jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]

Test #1

• 10 000 users
• 1 GET request
• Expected result — HTTP 200 OK
• пауза між викликами 1-2 sec
• Ramp time — 20 sec — лінійне зростання навантаження
• Час тесту — 3 min

Тести проведено, метрики зібрано:

Які висновки та нотатки я зробив:

1. Без зміни в реєстрі Windows всі 3 тести мають невеликий Success rate — тобто багато запитів навіть не були створені і не змогли навантажити сервер
2. Заміри CPU клієнта більше плутають. Я вимірював їх за допомоги тулів perfmon та procexp. Перший показував завантаження 100%, другий — до 10%. В Інтернеті кажуть, що різниця може бути в методі підрахунку (враховуючи system idle чи ні) та кількості ядер. Якщо хтось знає, в чому причина — напишіть, думаю, багатьом цікаво!
3. Якщо ви шукаєте в таблиці метрики CPU та RAM сервера — їх там немає, оскільки моя мета була протестувати тули, а не сервер — я нехтую цими метриками
4. Locust повільніше за всіх створює 10 000 користувачів. Я встановив швидкість у 500 користувачів на секунду, але знадобилась приблизно хвилина, щоб створити всіх
5. При цьому Locust потребує найменше ресурсів та не має жодної помилки — на всі 114 з гаком тисяч запитів отримав HTTP 200 OK
6. В тестах JMeter та Gatling майже всі помилки — request timeout
7. JMeter має найпростішу реалізацію, у порівнянні з іншими (шо потребує значних ресурсів) — як бачите, 10 000 користувачів — 10 000 паралельних потоків
8. Чисто з цікавості запускав тест JMeter в графічному режимі — отримав ті самі результати, лише в процесі роботи він використовував на 1 ГБ оперативної пам’яті більше.
9. Результати тесту Gatling не корелюють з результатами інших тулів (по кількості запитів та RPS)
10. Результати тестів показали, що мій сервер має точку насичення у приблизно 500 запитів на секунду — при подальшому зростанні навантаження росте лише час відповіді

Test #2

• 500 users
• 1 GET request
• Expected result — HTTP 200 OK
• пауза між викликами 1-2 sec
• Ramp time — 10 sec — лінійне зростання навантаження
• Час тесту — 2 min

Нотатки:

1. Незважаючи на те, що за однаковий час всі тули зробили приблизно однакову кількість запитів, я отримав різні результати Throughput та response time. Припускаю, що результати залежать від методу підрахунку а також від швидкості роботи HTTP клієнтів тулів

Висновки і плани

Об’єктивно: під кожну задачу треба правильно обирати тул та схему навантаження. Не кожен може давати велику потужність з одного ПК — можна скористатись можливістю розподіленого навантаження (JMeter та Locust можуть). Під час написання статті знайшов дослідження JMeter з оптимальної кількості юзерів

Всім, кому цікаво, можуть взяти код і спробувати провести свої тести — проект на Github. Якщо маєте рекомендації чи побажання — пишіть в коментарях.

У мене ще є нереалізовані ідеї, про які я хочу написати пізніше, якщо вам цікаво:

1. Перевірити, як працюють мої тести в wsl2 — я вже намагався їх запускати в минулому і ОС просто зависала. Якщо результати будуть позитивними — провести тести з Yandex-tank (його дуже хвалили в коментах до моїх попередніх статей) та tsung
2. Розробники Locust додали в новій версії новий fast http клієнт. І мені дуже кортить дізнатись, наскільки він швидший за звичайний (python requests)

А ще ми з колегами ведемо телеграм канал про тестування t.me/qamania — заходьте, ми намагаємось щодня писати щось цікаве про нашу професію