1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/icesky1stm-wrktcp

Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
README_EN.md

Поддержка протокола TCP без Lua

Вы можете ознакомиться с описанием на китайском языке: README_CN.md

[TOC]

Данная процедура в основном основана на WRK для удаления зависимости от SSL и Lua, используя конфигурацию TCPINI для достижения протокола TCP в условиях стресс-теста.

Обзор функций

  1. Общая структура основана на расширении WRK. Статистика, большинство команд и результаты вывода следуют WRK, но были внесены некоторые корректировки.
  2. Поддержка стресс-тестирования протокола TCP, включая различные протоколы и форматы связи.
  3. Поддержка определения информации об отправке сообщения, информации о сообщении ответа и конфигурации сравнения информации успешного ответа.
  4. Поддержка параметров переменных запроса сообщения. Параметры аналогичны loadRunner, с четырьмя типами:
    • COUNTER — итератор, такой как уникальный поток, может определять область действия и размер шага.
    • DATETIME — точно такой же формат, как Strtime.
    • CONNECTID — уникальный идентификатор соединения, обычно используется как номер терминала и т. д.
    • FILE — режим файла, поддерживает последовательное чтение содержимого из файлов для назначения содержимого.
  5. Поддержка динамического обновления TPS и задержки во время измерения давления. TODO
  6. Поддержка записи информации о процессе тестирования под давлением и создание HTML-страниц для отображения. TODO
  7. В принципе, также поддерживается HTTP, поскольку HTTP также является своего рода протоколом TCP.

Отличие от wrk

  1. Добавлена поддержка протокола TCP. Используйте профиль INI для настройки формата пакета TCP. Адрес подключения, соглашение о сообщениях, сообщение запроса и информация о сообщении ответа — всё это настраивается в этом файле.
  2. Убрана зависимость от Lua, настройка контента и суждение без изучения Lua, достаточно конфигурационного файла.
  3. Не полагайтесь на какие-либо сторонние библиотеки и deps SSL и Luajit. Таким образом, это чистый проект C.
  4. Статистика распределения для Thread Stat уменьшает максимальную поддержку TPS с 1000 Вт до 100 Вт и повышает точность TPS с 1 до 0,1.
  5. Вывод в основном следует за WRK, увеличивая классификацию успеха и неудачи. Поскольку оригинальный WRK не учитывал ошибки бизнес-уровня, была добавлена конфигурация.
  6. TODO: добавлены динамическое обновление TPS и задержка, чтобы можно было проводить наблюдение в реальном времени за измерением давления в течение длительного времени.
  7. TODO: генерация отчётов HTML и мониторинг процесса.

Установка

  • macOS

cd wrktcp && make

  • Linux

cd wrktcp && make

  • Windows

Необходимо загрузить компилятор или напрямую загрузить версию release.

Быстрый старт

  • Измените конфигурацию sample_tiny.ini
[common]
host = 127.0.0.1
port = 8000

[request]
req_body = this is a test
  • Запустите команду
wrktcp -t2 -c20 -d10s --latency sample_tiny.ini

Подобно WRK, эта команда представляет следующее: Используйте 2 потока (-T2), 20 одновременных подключений (-c20), продолжайте работать в течение 5 секунд (-d5s), работайте с конфигурацией sample_tiny.ini.

  • Вывод
Running 10s test @ 127.0.0.1:8000 using sample_tiny.ini
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    23.02ms   43.78ms 356.62ms   94.88%
    Req/Sec   354.37     74.31   454.50     90.62%
  Latency Distribution
     50%   12.99ms
     75%   14.02ms
     90%   15.74ms
     99%  274.89ms
  6862 requests in 10.11s, 140.72KB read
Requests/sec:    678.90
Requests/sec-Success:    678.90
Requests/sec-Failure:      0.00
Transfer/sec:     13.92KB
  • Подробное описание команды
-t, --threads:     Use the total number of threads, generally recommended to use 2 times the number of CPU cores -1
-c, --connections: Total number of connections, regardless of thread. The number of connections per thread is connections/ Threads
-d, --duration:    write 2S, 2m, 2h
    --latency:     distribution of printing delay
    --timeout:     Specify timeout, default is 5 minutes, longer takes up more statistical memory.       --realtime    refreshes TPS information in realtime and records TPS and delayed process data to generate HTML
-v  --version:     Print version information
  • Подробное описание вывода

Running 10s test @ 127.0.0.1:8000 using sample_tiny.ini

2 threads and 10 connections

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

Thread Stats Avg Stdev Max +/- Stdev Latency 23.02ms 43.78ms 356.62ms 94.88% Req/Sec 354.37 74.31 454.50 90.62%

Latency представляет время задержки, а Req/sec — количество успешных ответов в секунду (TPS). Следует отметить, что эта часть данных о задержке относится к данным одного потока.

Описание: статистика потоков, среднее значение (Avg), стандартное отклонение (Stdev), максимальное значение (Max), процент данных в пределах одного стандартного отклонения (+/- Stdev).

Если система измерения давления стабильна, то ожидается, что среднее и максимальное значения будут одинаковыми, ожидаемое стандартное отклонение будет равно 0, а ожидаемый процент данных в пределах стандартного отклонения — 100%.

Latency Distribution 50% 12.99ms 75% 14.02ms 90% 15.74ms 99% 274.89ms

Статистика распределения задержек от 50 % до 99 % отсортирована по соответствующему времени. Таким образом, 50 % — это 50-я задержка данных, а 99 % — 99-я.

6862 requests in 10.11s, 140.72KB read

Requests/sec: 678.90 Requests/sec-Success: 678.90 Requests/sec-Failure: 0.00 Transfer/sec: 13.92KB

Первая строка представляет: 6862 запроса за 10,11 секунды, всего прочитано 140,72 КБ.

Requests/sec: 678,90 — общий TPS запросов, содержащий общее количество успехов и неудач, такой же, как у WRK.

Requests/sec-success & Requests/sec-failure: чтобы определить, был ли ответ бизнеса успешным или нет, он мог быть правильно дан, но возвращённое сообщение является сообщением об ошибке.

Transfer/sec: размер передаваемых данных в секунду.

Описание конфигурации ini

[common]
host = 127.0.0.1
port = 8000

[request]
# Длина сообщения, по умолчанию 8
req_len_len = 8
# длина — всё или только рассчитанное тело, по умолчанию — необязательная конфигурация тела всего
req_len_type = body
# заголовок запроса, длина по умолчанию только
req_head = $(length)
# содержимое тела запроса
req_body = \
<root>\
    <date>$(DATE)</date>\
    <branch>$(BRANCH)</branch>\
    <traceno>20201222$(TRACENO)</branch>\
    <term>$(TERMNO)</term>\
    <bankno>313233000017</bankno>\
    <name>sam</name>\
</root>

[response]
# Затем длина заголовка 
rsp_headlen = 16
# Расположение длины в сообщении, по умолчанию 1
rsp_len_beg = 5
# Длина сообщения, по умолчанию 8
rsp_len_len = 8
# длина — всё или только рассчитанное тело, по умолчанию — необязательная конфигурация тела всего
rsp_len_type = body

# тип кода ответа, по умолчанию фиксированный, опционально xml, json и продолжение
rsp_code_type = xml
# расположение кода ответа, тело или заголовок
rsp_code_location = body
# тег кода ответа
rsp_code_localtion_tag = <retCode>
# код ответа успешно
rsp_code_success = 000000

[paramters]
DATE = DATETIME, "%H:%M:S"
BRANCH =  FILE, branch.txt
TRACENO = COUNTER, 100, 100000, 2, "%08ld"
TERMNO = CONNECTID

Почему не использовать WRK2

В статье WRK2 есть резкие контрасты в обсуждении координированного пропуска: https://blog.csdn.net/minxihou/article/details/97318121.

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

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

Благодарности

WRKTCP — расширенная разработка на основе...

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

Поддерживает нагрузочное тестирование по протоколу TCP с помощью инструмента wrk, все настройки не зависят от Lua. Развернуть Свернуть
Apache-2.0
Отмена

Обновления (2)

все

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/icesky1stm-wrktcp.git
git@api.gitlife.ru:oschina-mirror/icesky1stm-wrktcp.git
oschina-mirror
icesky1stm-wrktcp
icesky1stm-wrktcp
master