Как проверить производительность вашего потока аутентификации пользователя
software-testing api api-testing

Как проверить производительность вашего потока аутентификации пользователя

3 февраля 2023 г.

Начнем с интересного варианта использования. Вы реализовали свою большую идею и создали увлекательный веб-сайт или мобильное приложение и готовы рассказать миру о том, какое у вас крутое приложение. Все прошло хорошо, все хотят использовать ваше приложение. Затем внезапно ваш сервер начинает отклонять новые регистры, потому что он получает больше запросов, чем может обработать. Прежде всего, хорошо для вас, похоже, вы создали продукт, который люди хотят использовать. Во-вторых, позор вам, потому что вы не протестировали максимальную производительность параллельных запросов серверной части.

Это крайний вариант использования для демонстрации важности нагрузочного тестирования перед запуском в производство. Ваши требования будут другими, возможно, ваша компания начнет маркетинговую кампанию в определенную дату, и вы хотите быть уверены, что система способна обрабатывать X количество одновременных новых регистров. В этой статье показано, как имитировать поток аутентификации пользователей при заданном параллелизме, и в конечном итоге вы сможете найти верхний предел вашего серверного API.

Сценарий тестирования

Сценарий пользователя состоит из 3 последовательных действий,

  1. Пользователь регистрируется в системе со своим адресом электронной почты, именем пользователя и паролем.
  2. Пользователь входит в систему со своим именем пользователя и паролем
  3. Пользователь отправляет запрос GET, чтобы получить информацию о своей личной учетной записи.

Первые два действия являются общими для всех приложений в мире. Мы добавили третье действие для демонстрации поведения аутентифицированного пользователя. В нашем случае пользователь получает информацию об учетной записи после входа в систему.

Окружающая среда​

Мы будем использовать тестовый API Ddosify в качестве внутренней службы. У него есть все конечные точки, которые нам нужны.

* Конечная точка POST /account/register ожидает сообщения электронной почты, имени пользователя и пароля и возвращает HTTP 201 Created. * Конечная точка POST /account/login принимает имя пользователя и пароль и проверяет, есть ли пользователь с этими учетными данными, а затем отправляет HTTP 200 OK вместе с токеном JWT. * Конечная точка GET /account/user ожидает, что ключ заголовка авторизации с допустимым значением токена доступа будет отвечать на информацию о личной учетной записи пользователя.

Мы будем использовать Ddosify Open Source Load Engine, чтобы создать и запустить этот тестовый сценарий с высокой частотой кадров (количество итераций в секунду). Ddosify можно установить практически на любую операционную систему, в том числе через Docker. Ознакомьтесь с разделом установки, чтобы найти правильный метод установки для вашего хост-компьютера. Мы выберем brew, так как мы проводим эти тесты на macOS.

Установите Ddosify с помощью brew

brew install ddosify/tap/ddosify

Протестируйте установку, передав флаг -version

.
$ ddosify -version
Version:        v0.13.0
Git commit:     5fca361
Built           2023-01-26T12:49:12Z
Go version:     go1.18.10
OS/Arch:        darwin/arm64

Если вы видите номер версии и другие сведения о версии, значит, вы свободны. Если у вас возникнут какие-либо проблемы, вы можете использовать Ddosify Discord Channel, это самый быстрый способ решить любую проблему, связанную с Ddosify.

Проверка конечных точек​

Перед написанием сложного тестового сценария рекомендуется разбить его на более мелкие части. У нас есть 3 конечных точки, которые мы хотели бы достичь последовательно. Давайте отправим один запрос на эти конечные точки и проверим, что мы получим. Мы будем использовать флаг --debug для проверки заголовков запроса, тела запроса, заголовков ответа и тела ответа. Поскольку Ddosify отправляет только 1 запрос в режиме отладки, нам не нужно сейчас беспокоиться о параметрах iteration_count и duration.

Проверка конечной точки регистрации

$ ddosify -t https://testserver.ddosify.com/account/register/ -m POST --debug

⚙️  Initializing...
🐛 Running in debug mode, 1 iteration will be played...
🔥 Engine fired.

🛑 CTRL+C to gracefully stop.


STEP (1)
-------------------------------------
- Environment Variables

- Request
    Target:     https://testserver.ddosify.com/account/register/
    Method:     POST
    Headers:
    Body:

- Response
    StatusCode:    400
    Headers:
        Content-Type:                  application/json
        Connection:                    keep-alive
        Cross-Origin-Opener-Policy:    same-origin
        X-Frame-Options:               DENY
        X-Content-Type-Options:        nosniff
        Server:                        nginx/1.23.3
        Referrer-Policy:               same-origin
        Date:                          Thu, 12 Jan 2023 19:26:45 GMT
        Strict-Transport-Security:     max-age=31536000
        Content-Length:                115
        Vary:                          Accept
        Allow:                         POST, OPTIONS
    Body:
        {
            "email": [
                "This field is required."
            ],
            "password": [
                "This field is required."
            ],
            "username": [
                "This field is required."
            ]
        }

При отправке запроса мы передали флаг -m со значением POST, чтобы передать правильный метод HTTP для этого запроса. Как показано в результате отладки, сервер вернул код состояния HTTP 400 и подробное сообщение в теле. Очевидно, нам нужно отправить необходимую информацию о пользователе (имя пользователя, адрес электронной почты, пароль) в теле запроса, чтобы успешно создать новую запись. Но это хороший способ показать, как работает режим отладки в Ddosify. Мы можем легко передать полезную нагрузку запроса с помощью флага -b, но есть и другой способ добиться этого. Ddosify поддерживает файлы конфигурации в качестве входных данных, что позволяет создавать и проходить сложные тестовые сценарии. Так как у нас будут последовательно работать 3 действия, рекомендуется приступить к созданию конфигурационного файла нашего тестового сценария.

register.json

{
  "debug": true,
  "steps": [
    {
      "id": 1,
      "name": "Register",
      "url": "https://testserver.ddosify.com/account/register/",
      "method": "POST",
      "headers": {
        "Content-Type": "application/json"
      },
      "payload_file": "./register_payload.json"
    }
  ]
}

register_payload.json

{
  "username": "test_user_name",
  "email": "test@dummy.com",
  "password": "testpassword"
}

Мы создали два файла register.json и register_payload.json. Первый файл — это файл конфигурации, который содержит логику нашего тестового сценария. Второй файл содержит полезные данные JSON запроса Register. Мы привязали этот файл полезной нагрузки к запросу Register с помощью ключа payload_file в register.json. Мы также добавили в запрос заголовок Content-Type: application/json, так как мы отправляем полезную нагрузку JSON. Давайте запустим наш сценарий и посмотрим, что произойдет.

$ ddosify -config register.json

<.. truncated ..>

- Request
    Target:     https://testserver.ddosify.com/account/register/
    Method:     POST
    Headers:
        Content-Type:    application/json
    Body:
        {
            "email": "test@dummy.com",
            "name": "Test User",
            "password": "testpassword",
            "username": "test_user_name"
        }

- Response
    StatusCode:    201
    Headers:
        X-Content-Type-Options:        nosniff
        <.. truncated ..>
    Body:

Вот и все! Как показано в результате отладки, мы успешно создали нового пользователя. Часть Регистрация нашего тестового сценария наполовину готова. Чтобы сделать его полностью готовым, мы должны отправлять разные адреса электронной почты, имя пользователя и пароль для каждой итерации. Мы вернемся к этому позже, а пока давайте создадим другие действия пользователя.

:::предупреждение Если вы используете версию Ddosify для докеров, вам необходимо привязать файлы конфигурации к контейнеру докеров. Предположим, что register.json находится в текущем каталоге ($PWD). Мы должны связать текущий путь к каталогу ($PWD) с путем /ddosify_config контейнера Docker.

Привяжите текущий каталог и запустите контейнер Ddosify:

$ docker run -it --rm -v  $PWD:/ddosify_config ddosify/ddosify:v0.11.0

Запустите Ddosify внутри контейнера

$ cd /ddosify_config/$ ddosify -config register.json

:::

Проверка конечной точки входа

логин.json

{
  "debug": true,
  "steps": [
    {
      "id": 1,
      "name": "Login",
      "url": "https://testserver.ddosify.com/account/login/",
      "method": "POST",
      "headers": {
        "Content-Type": "application/json"
      },
      "payload_file": "./login_payload.json"
    }
  ]
}

login_payload.json

{
  "username": "test_user_name",
  "password": "testpassword"
}


$ ddosify -config login.json

<.. truncated ..>

- Request
    Target:     https://testserver.ddosify.com/account/login/
    Method:     POST
    Headers:
        Content-Type:    application/json
    Body:
        {
            "password": "testpassword",
            "username": "test_user_name"
        }

- Response
    StatusCode:    200
    Headers:
        X-Frame-Options:               DENY
        <.. truncated ..>
    Body:
        {
            "tokens": {
                "access": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjczNTgyNzgyLCJpYXQiOjE2NzMzODIwODIsImp0aSI6IjhiNjFmNjgyZDcxZjRiYmViMjBlZDc3NmQ5N2IwZjM2IiwidXNlcl9pZCI6ImI5ZjI0MjNhLWYyYTgtNGMwZC1iZjZmLWY0ODFlMGUyYmJlZSJ9.9lN55gfCAUka37gGOK-IygDgCccavRl_db77LPOvqaQ",
                "refresh": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoicmVmcmVzaCIsImV4cCI6MTY3NDI0NjA4MiwiaWF0IjoxNjczMzgyMDgyLCJqdGkiOiIyNjk3NjAxZDNmNDU0NzdjYjBjZTcwOGNjZjk5OTBhZSIsInVzZXJfaWQiOiJiOWYyNDIzYS1mMmE4LTRjMGQtYmY2Zi1mNDgxZTBlMmJiZWUifQ.IqZUEamOPzEqDZC_6-KdRxR4oOk8v5NM-DA4dTuCu94"
            },
        }

Мы создали новый файл конфигурации Ddosify с именем login.json, который включает конфигурацию запроса действия входа вместе со ссылкой на файл полезной нагрузки входа. Мы отправили учетные данные пользователя (имя пользователя и пароль), которые мы создали ранее при действии регистрации. Как показано в результате отладки, сервер ответил кодом состояния HTTP 200 OK, а текст ответа содержит токен доступа, который мы можем использовать для отправки запросов на конечные точки, требующие аутентификации.

Проверка конечной точки сведений о пользователе​

account.json

{
  "debug": true,
  "steps": [
    {
      "id": 1,
      "name": "User Detail",
      "url": "https://testserver.ddosify.com/account/user/",
      "method": "GET",
      "headers": {
        "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjczNTgzMDg2LCJpYXQiOjE2NzMzODIzODYsImp0aSI6IjFmYWFlMzM5YTYyMjQ2ZGRhNTk1MTZlN2NkYzMyMWU4IiwidXNlcl9pZCI6ImI5ZjI0MjNhLWYyYTgtNGMwZC1iZjZmLWY0ODFlMGUyYmJlZSJ9.X_x63UOFSbz7s8jiR44YUZjPVXRAcpKSLfO8skLCmG0"
      }
    }
  ]
}


$ ddosify -config account.json

<.. truncated ..>

- Request
    Target:     https://testserver.ddosify.com/account/user/
    Method:     GET
    Headers:
        Authorization:    Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjczNTgzMDg2LCJpYXQiOjE2NzMzODIzODYsImp0aSI6IjFmYWFlMzM5YTYyMjQ2ZGRhNTk1MTZlN2NkYzMyMWU4IiwidXNlcl9pZCI6ImI5ZjI0MjNhLWYyYTgtNGMwZC1iZjZmLWY0ODFlMGUyYmJlZSJ9.X_x63UOFSbz7s8jiR44YUZjPVXRAcpKSLfO8skLCmG0
    Body:

- Response
    StatusCode:    200
    Headers:
        X-Content-Type-Options:        nosniff
        <.. truncated ..>
    Body:
        {
            "email": "test@dummy.com",
            "id": "b9f2423a-f2a8-4c0d-bf6f-f481e0e2bbee",
            "username": "test_user_name"
        }

Как и в предыдущих шагах, мы создали новый файл конфигурации (account.json), который вставляет токен доступа (полученный на этапе входа) в заголовок авторизации. Результат отладки показывает, что мы успешно получили личные данные пользователя из конечной точки, для которой требуется аутентификация.

Создание файла сценария аутентификации​

В предыдущих разделах мы успешно достигли конечных точек с помощью разных файлов конфигурации Ddosify. Теперь мы объединим все эти конфигурации в один файл конфигурации Ddosify, чтобы создать реалистичный пользовательский поток. Для этого мы должны рассмотреть следующие требования:

  1. При каждой итерации (новый пользователь) мы должны передавать другой адрес электронной почты, имя пользователя и пароль
  2. Электронная почта, имя пользователя и пароль пользователя должны быть одинаковыми на всех этапах итерации.
  3. Мы должны перехватить токен проверки подлинности, возвращенный в запросе на вход. Затем нам нужно использовать этот токен в следующем запросе, который является получением пользовательских данных.
  4. Между запросами должно быть время ожидания, чтобы имитировать реальное поведение пользователя.

Для первого требования мы можем использовать динамические переменные для создания случайных данных. Чтобы использовать одни и те же случайно сгенерированные данные на всех этапах, мы можем назначить их переменным среды. Поскольку переменная среды создается в начале итерации, случайные переменные будут создаваться сразу для каждой итерации и могут быть доступны по шагам сценария.

Наша начальная среда выглядит следующим образом:

"env": {
    "username": "{{_randomUserName}}",
    "email": "{{_randomEmail}}",
    "password": "{{_randomPassword}}"
}

Чтобы захватить токен доступа при входе в систему, мы можем использовать функцию корреляции Ddosify. Эта функция позволяет нам извлекать значения из тела ответа или заголовка ответа. Мы можем присвоить извлеченное значение новой переменной, а затем использовать эту переменную в качестве переменной среды на следующих шагах.

В нашем сценарии ответ конечной точки входа находится в формате JSON. Таким образом, мы можем использовать json_path для извлечения токена доступа из тела ответа.

"capture_env": {
    "access_token": {"from": "body", "json_path": "tokens.access"}
}

Единственное требование, которое мы должны выполнить, — это время на обдумывание между запросами для имитации реального поведения пользователя. Это самый простой способ, так как мы можем просто добавить свойство sleep для первых двух шагов, чтобы добавить время на обдумывание после завершения этого шага. Свойство сна может быть точной цифрой в миллисекундах или может быть диапазоном для добавления случайного времени ожидания между заданным диапазоном. В нашем примере мы хотели бы добавить время на обдумывание от 1 до 2,5 секунд.

Вот окончательный файл конфигурации и новые файлы полезной нагрузки, отвечающие всем требованиям.

auth_flow.json

{
  "iteration_count": 50,
  "duration": 10,
  "load_type": "linear",
  "debug": true,
  "env": {
    "baseUrl": "https://testserver.ddosify.com/account",
    "username": "{{_randomUserName}}",
    "email": "{{_randomEmail}}",
    "password": "{{_randomPassword}}"
  },
  "steps": [
    {
      "id": 1,
      "name": "Register",
      "url": "{{baseUrl}}/register/",
      "method": "POST",
      "headers": {
        "Content-Type": "application/json"
      },
      "payload_file": "./register_payload.json",
      "sleep": "1000-2500"
    },
    {
      "id": 2,
      "name": "Login",
      "url": "{{baseUrl}}/login/",
      "method": "POST",
      "headers": {
        "Content-Type": "application/json"
      },
      "payload_file": "./login_payload.json",
      "sleep": "1000-2500",
      "capture_env": {
        "access_token": { "from": "body", "json_path": "tokens.access" }
      }
    },
    {
      "id": 3,
      "name": "Account",
      "url": "{{baseUrl}}/user/",
      "method": "GET",
      "sleep": "1000-2500",
      "headers": {
        "Authorization": "Bearer {{access_token}}"
      }
    }
  ]
}

Как видно из приведенного выше файла конфигурации, мы создали случайные пользовательские данные с функцией динамических переменных и назначили эти переменные переменным среды, чтобы использовать те же сгенерированные данные на шагах сценария. Чтобы получить токен доступа, мы использовали функцию capture_env на этапе входа в систему, а затем использовали захваченную переменную в разделе заголовка на этапе учетной записи. Наконец, мы использовали время сна после шагов регистрации и входа в систему, чтобы создать более реалистичную симуляцию пользователя.

register_payload.json

{
  "username": "{{username}}",
  "email": "{{email}}",
  "password": "{{password}}"
}

login_payload.json

{
  "username": "{{username}}",
  "password": "{{password}}"
}

Вместо использования статических строковых значений для пользовательских данных мы изменили файлы полезной нагрузки, чтобы использовать данные, сгенерированные в разделе среды тестового файла конфигурации auth_flow.json.

Поскольку параметр debug все еще включен, давайте запустим весь сценарий в режиме отладки и протестируем наш окончательный файл конфигурации Ddosify.

$ ddosify -config auth_flow.json

<.. truncated ..>

STEP (1) Register
-------------------------------------
- Environment Variables
    password:    faqkebowz
    baseUrl:     https://testserver.ddosify.com/account
    username:    Connor.Kuhlman
    email:       sarah.thomas@hotmail.com

- Request
    Target:     https://testserver.ddosify.com/account/register/
    Method:     POST
    Headers:
        Content-Type:    application/json
    Body:
        {
            "email": "sarah.thomas@hotmail.com",
            "password": "faqkebowz",
            "username": "Connor.Kuhlman"
        }

- Response
    StatusCode:    201
    Headers:
        <.. truncated ..>
    Body:

STEP (2) Login
-------------------------------------
- Environment Variables
    email:       sarah.thomas@hotmail.com
    password:    faqkebowz
    baseUrl:     https://testserver.ddosify.com/account
    username:    Connor.Kuhlman

- Request
    Target:     https://testserver.ddosify.com/account/login/
    Method:     POST
    Headers:
        Content-Type:    application/json
    Body:
        {
            "password": "faqkebowz",
            "username": "Connor.Kuhlman"
        }

- Response
    StatusCode:    200
    Headers:
        <.. truncated ..>
    Body:
        {
            "tokens": {
                "access": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjczNzM1MzE0LCJpYXQiOjE2NzM1MzQ2MTQsImp0aSI6IjhkYjBlZDY2YzJhNzQ4ZWY4ZDk1ZjhiMzI3OGI3OTExIiwidXNlcl9pZCI6IjgyZWM5YmFiLWEzODUtNDQ3MS04YjRlLTViM2MwMGExOTU4ZiJ9.q4SOCIn8i-6JTP51h9Jm3VXtI4YCT_yOn9cHRXhtsHw",
                "refresh": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoicmVmcmVzaCIsImV4cCI6MTY3NDM5ODYxNCwiaWF0IjoxNjczNTM0NjE0LCJqdGkiOiJmYjIzYzY0YTc5NmY0NTQzYjU5YTA5NmU2ZGVlZTU0OCIsInVzZXJfaWQiOiI4MmVjOWJhYi1hMzg1LTQ0NzEtOGI0ZS01YjNjMDBhMTk1OGYifQ.XpT6wdI9D-wyAhyLGRGMtEhgtacKfB6U_2BfOuQF2dg"
            }
        }

STEP (3) Account
-------------------------------------
- Environment Variables
    baseUrl:         https://testserver.ddosify.com/account
    username:        Connor.Kuhlman
    email:           sarah.thomas@hotmail.com
    password:        faqkebowz
    access_token:    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjczNzM1MzE0LCJpYXQiOjE2NzM1MzQ2MTQsImp0aSI6IjhkYjBlZDY2YzJhNzQ4ZWY4ZDk1ZjhiMzI3OGI3OTExIiwidXNlcl9pZCI6IjgyZWM5YmFiLWEzODUtNDQ3MS04YjRlLTViM2MwMGExOTU4ZiJ9.q4SOCIn8i-6JTP51h9Jm3VXtI4YCT_yOn9cHRXhtsHw

- Request
    Target:     https://testserver.ddosify.com/account/user/
    Method:     GET
    Headers:
        Authorization:    Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNjczNzM1MzE0LCJpYXQiOjE2NzM1MzQ2MTQsImp0aSI6IjhkYjBlZDY2YzJhNzQ4ZWY4ZDk1ZjhiMzI3OGI3OTExIiwidXNlcl9pZCI6IjgyZWM5YmFiLWEzODUtNDQ3MS04YjRlLTViM2MwMGExOTU4ZiJ9.q4SOCIn8i-6JTP51h9Jm3VXtI4YCT_yOn9cHRXhtsHw
    Body:

- Response
    StatusCode:    200
    Headers:
        <.. truncated ..>
    Body:
        {
            "email": "sarah.thomas@hotmail.com",
            "id": "82ec9bab-a385-4471-8b4e-5b3c00a1958f",
            "username": "Connor.Kuhlman"
        }

Как показано в результате отладки, разделы Environment Variables заполнены данными, сгенерированными динамическими переменными. Кроме того, на этапе «Учетная запись» есть переменная access_token, которая фиксируется на этапе «Вход». Нам удалось создать файл конфигурации Ddosify для имитации потока аутентификации пользователя. Текущая конфигурация говорит, что движок Ddosify запускает сценарий только 1 раз. Чтобы начать нагрузочный тест, мы должны удалить поле debug: true в файле auth_flow.json. После его удаления Ddosify учитывает значения iteration_count и duration для отправки запросов в соответствии с заданным тип_загрузки. Для нашего файла этот сценарий будет повторяться 50 раз в течение 10 секунд. Поскольку load_type является «линейным», Ddosify будет выполнять 5 итераций в секунду. Это означает, что наш внутренний сервер получит 5 Register -> Войти -> Получение потока в секунду.

Вот результат нашего нагрузочного теста

$ ddosify -config auth_flow.json

⚙️  Initializing...
🔥 Engine fired.

🛑 CTRL+C to gracefully stop.
✔️  Successful Run: 0        0%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 0.00000s
✔️  Successful Run: 0        0%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 0.00000s
✔️  Successful Run: 0        0%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 0.00000s
✔️  Successful Run: 0        0%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 0.00000s
✔️  Successful Run: 0        0%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 0.00000s
✔️  Successful Run: 0        0%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 0.00000s
✔️  Successful Run: 1      100%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 5.28926s
✔️  Successful Run: 3      100%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 5.68370s
✔️  Successful Run: 6      100%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 6.57709s
✔️  Successful Run: 8      100%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 6.84142s
✔️  Successful Run: 12     100%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 7.58740s
✔️  Successful Run: 18     100%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 8.33634s
✔️  Successful Run: 18     100%       ❌ Failed Run: 0        0%       ⏱️  Avg. Duration: 8.33634s
✔️  Successful Run: 20      90%       ❌ Failed Run: 2       10%       ⏱️  Avg. Duration: 8.59492s
✔️  Successful Run: 28      68%       ❌ Failed Run: 13      32%       ⏱️  Avg. Duration: 8.92337s
✔️  Successful Run: 30      63%       ❌ Failed Run: 17      37%       ⏱️  Avg. Duration: 8.96106s
✔️  Successful Run: 30      60%       ❌ Failed Run: 20      40%       ⏱️  Avg. Duration: 8.96106s

RESULT
-------------------------------------

1. Register
---------------------------------
Success Count:    41    (82%)
Failed Count:     9     (18%)

Durations (Avg):
  DNS                  :0.0431s
  Connection           :0.0501s
  Request Write        :0.0001s
  Server Processing    :2.3935s
  Response Read        :0.0001s
  Total                :2.5485s

Status Code (Message) :Count
  201 (Created)        :29
  400 (Bad Request)    :12

Error Distribution (Count:Reason):
  9     :connection timeout


2. Login
---------------------------------
Success Count:    38    (76%)
Failed Count:     12    (24%)

Durations (Avg):
  DNS                  :0.0599s
  Connection           :0.0536s
  Request Write        :0.0001s
  Server Processing    :3.8256s
  Response Read        :0.0001s
  Total                :4.0416s

Status Code (Message) :Count
  200 (OK)             :28
  400 (Bad Request)    :10

Error Distribution (Count:Reason):
  12     :connection timeout


3. Account
---------------------------------
Success Count:    50    (100%)
Failed Count:     0     (0%)

Durations (Avg):
  DNS                  :0.0096s
  Connection           :0.0174s
  Request Write        :0.0001s
  Server Processing    :2.2237s
  Response Read        :0.0001s
  Total                :2.2734s

Status Code (Message) :Count
  200 (OK)              :28
  401 (Unauthorized)    :22

Мы можем легко проанализировать время отклика, коды состояния и критерии успеха/неудачи для каждого шага. Ddosify помечает запросы как неудачные, если не получает ответ или не может отправить запрос. Например, результат шага входа в систему указывает, что время ожидания 9 запросов истекло, поэтому Ddosify помечает 9 запросов как Failed. Возвращаемые коды состояния не влияют на логику успеха/неудачи. Кроме того, мы получили HTTP 400 (неверный запрос) для конечной точки регистрации в некоторых запросах, потому что мы отправили данные существующих пользователей для этих запросов, а сервер не позволяет нам создавать новых пользователей.

✔️  Successful Run: 30      60%       ❌ Failed Run: 20      40%       ⏱️  Avg. Duration: 8.96106s

В последней строке сообщений в реальном времени указывается результат нашего теста с точки зрения итерации. Ddosify помечает всю Итерацию (выполнение) как неудавшуюся, если какой-либо из шагов завершился неудачно. В противном случае (если все шаги выполнены успешно) Ddosify помечает итерацию как успешную. Средн. Duration показывает сумму всех средних длительностей шагов. В нашем примере среднее время отклика на шаг входа составляет 2,5 секунды, шаг регистрации — 4 секунды, а шаг аккаунта — 2,27 секунды. Общее значение равно Avg. Значение продолжительности. Также легко сказать, что шаг регистрации является самым трудоемким действием в этом пользовательском потоке.

Заключение​

Мы продемонстрировали, как создать тестовый файл конфигурации Ddosify для проверки производительности внутреннего сервера, включая частные конечные точки API, которые могут быть доступны через аутентификацию. В этой статье мы использовали различные функции механизма загрузки с открытым исходным кодом Ddosify, такие как корреляция, переменные среды, режим отладки и т. д. Существуют и другие концепции, которые помогут вам создавать более сложные сценарии. Ознакомьтесь с Ddosify Readme на Github, чтобы узнать о них подробнее.

Также опубликовано здесь

Оригинал

Recent Post

Categories

PREVIOUS ARTICLE
NEXT ARTICLE

COPYRIGHT 2020 COFFEE-WEB.RU