mailruchamps / hlcupdocs Goto Github PK

При POST запросах Content-Length не совпадает с длиной Body из-за дополнительного символа переноса строки. Из-за этого сервер не может нормально работать.

Сейчас выбирается подмножество всех сбойных, и не всегда в него попадают примеры обоих вариантов.

Как минимум мне нужно чтобы разобраться где ошибка в chrono/у меня в коде.

Вместо этого показывать 👍 и подпись, что все ответы верны :)

В патронах установлено значение Close, первая буква - заглавная. По стандарту* значение этого заголовка должно обрабатываться как case-insensitive, но некоторые реализации http-серверов (например, fasthttp на go) реагируют только на значение равное close, где все буквы маленькие.

Эта ситуация приводит к неочевидным различиям в поведении реализаций сервиса при тестировании. Например, если сервис игнорирует значение этого заголовка на фазах с GET запросами, то он получает преимущество за счет расхождения его поведения со спецификацией HTTP/1.1, так как yandex-tank не проверяет значение заголовка Connection в отправляемых запросах, и не контроллирует закрытие соединения сервером. А на фазах POST из за особенностей yandex-tank соединение необходимо закрывать после каждого запроса, в противном случае он не корректно обрабатывает ответ сервиса, и участники соревнования видят в результатах обстрела ошибку "Response is empty".

Возможно, во второй фазе стоит заменить Close на close, а в первой и третьей - заголовок Connection убрать.

[*] https://tools.ietf.org/html/rfc7230#section-6.1

Прямо сейчас мой тестинговый обстрел висит в очереди уже полчаса, хотя мне тестовый не особо-то и нужен, а нужен рейтинговый.

Хочется в графиках кроме max/min видеть ещё avg и 95/90/75/50 перцентили.

Ещё было бы классно иметь возможность видеть что происходит на машине в момент стрельбы (процессор, память, переключения контекста).

Вообще, как вариант, можно дать пользователю возможность установить токен и отправлять результаты его стрельб в overload.yandex.net (или другой сервис). Правильно понимаю, что в онлайне стрельбу мониторить стандартным plugin_uploader=yandextank.plugins.DataUploader overload архитектура сети не позволит?

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

CPU usage
mem usage
load average
с секундной разверткой

Хотя бы для личного дебага, а лучше чтобы видели все.

В #33 я просил предоставить приложению время старта для осуществления прогрева, но в тикете добавили время генерации тестов, которое абсолютно не соответствует задаче: оно меняется раз в сутки насколько я понимаю.
Приложению нужно знать до какого момента времени можно прогревать себя.

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

"Лучшее" решение ИМХО должен определять сам автор. Ибо, например, в моем случае "Лучшее" решение показывает хуже perf в очках, но я подозреваю изменение условий на проде.

Которое предупреждает пользователя, что следующий обстрел будет сильно нескоро. Он точно уверен? Точно не misclick.
ИМХО будет полезно для начинающих.

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

Я понял так;

Алгоритм преобразования возраста в timestamp:

1. Взять current unix timestamp
2. Преобразовать его в дату в UTC
3. Сделать seconds = minute = hours = 0
4. Сделать years = years - age
5. Преобразовать в unix timestamp

Если нам пришел запрос с fromAge=AAA&toAge=BBB, то получаем по описанному выше алгоритму
fromAgeTimestamp и toAgeTimestamp

Для включения пользователя в выборку проверяем:

if (fromAgeTimestamp <= userBirthdayTimestamp && userBirthdayTimestamp <= toAgeTimestamp) {
...
}

Я все правильно описал?

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

Интересно где работают или учатся участники

Нужно разобраться в причинах сильного (более 300%) разброса в результатах рейтингового прогона одного и того же решения в разное время суток.
Решение id=8462 (827.985893)
Решение id=9026 (237.529905)
Tarantool/Lua

Пожалуй было бы неплохо на будущее (особенно когда и если добавят rps) иметь возможность короткого тестового прогона, но с нагрузкой, близкой к той, которая будет в рейтинговом тестировании.

У многих не стабильно проявляется проблема со значительно большим среднего временем ответа у первых запросов.
Для решений, не использующих "прогрев"/JIT, это очень странно.

Хорошо бы проверить, что дело не в самом тестировании и тестере.

Если это не так, то хорошо бы получить какие подробности поведения тестируемого решения в эти первые секунды.

Было бы интересно понимать, это скорость обработки запросов такая, или там были ошибки.

Пулемёт должен поддерживать ответы сервера с Transfer-Encoding: chunked. Асинхронная обработка запроса, особенно там, где ожидается ответ в виде коллекции, может сильно выигрывать от chunked запроса. Сейчас приходится результат запроса закачивать в память, сериализовать в массив байт и отправлять уже его, чтобы заранее узнать Content-Length

Не получается запустить танк на Windows 10.

docker run -v /$(pwd):/var/loadtest --net host -it --rm direvius/yandex-tank -c load/load_1.ini

08:21:44 [WARNING] /etc/yandex-tank is not accessible to get configs list
08:21:44 [INFO] Loading configs...
08:21:44 [INFO] Loading plugins...
08:21:44 [INFO] Performing test
08:21:44 [INFO] Configuring plugins...
08:21:44 [INFO] Resolved 127.0.0.1 into 127.0.0.1:80
08:21:44 [INFO] Configuring StepperWrapper...
08:21:44 [WARNING] Mandatory option config was not found in section telegraf
08:21:44 [WARNING] Mandatory option config was not found in section monitoring
08:21:44 [WARNING] Mandatory option default_target was not found in section telegraf
08:21:44 [WARNING] Mandatory option default_target was not found in section monitoring
08:21:44 [INFO] Preparing test...
08:21:44 [INFO] Exception: Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/yandextank/core/consoleworker.py", line 268, in perform_test
    self.core.plugins_prepare_test()
  File "/usr/local/lib/python2.7/dist-packages/yandextank/core/tankcore.py", line 274, in plugins_prepare_test
    plugin.prepare_test()
  File "/usr/local/lib/python2.7/dist-packages/yandextank/plugins/Phantom/plugin.py", line 101, in prepare_test
    self.config = self.phantom.compose_config()
  File "/usr/local/lib/python2.7/dist-packages/yandextank/plugins/Phantom/utils.py", line 111, in compose_config
    streams_config += stream.compose_config()
  File "/usr/local/lib/python2.7/dist-packages/yandextank/plugins/Phantom/utils.py", line 288, in compose_config
    self.stepper_wrapper.prepare_stepper()
  File "/usr/local/lib/python2.7/dist-packages/yandextank/stepper/main.py", line 204, in prepare_stepper
    self.stpd = self.__get_stpd_filename()
  File "/usr/local/lib/python2.7/dist-packages/yandextank/stepper/main.py", line 260, in __get_stpd_filename
    raise RuntimeError("Neither ammofile nor uris specified")
RuntimeError: Neither ammofile nor uris specified

08:21:44 [ERROR] Neither ammofile nor uris specified
08:21:44 [INFO] Trying to shutdown gracefully...
08:21:44 [INFO] Finishing test...
08:21:44 [INFO] Finishing monitoring
08:21:44 [ERROR] Failed finishing plugin <yandextank.plugins.Aggregator.plugin.Plugin object at 0x7fe5238d4090>: 'Plugin' object has no attribute 'drain'
08:21:44 [INFO] Post-processing test...
08:21:44 [INFO] Artifacts dir: /var/loadtest/logs/2017-08-21_08-21-44.h3_rZA
08:21:44 [INFO] Done graceful shutdown
08:21:44 [INFO] Close allocated resources...
08:21:44 [INFO] Done performing test with code 1

"до 200 RPS" (для начинающих в highload)
"до 2 kRPS"
"до 5 kRPS"
"до 10 kRPS"
Дальше +10 kRPS
"до 100 kRPS" (ИМХО дальше будут проблемы с адекватным тестированием, потому нет смысла)

Please enable --ipc="host" option when starting a container, otherwise shared memory is not working in my solution...
See https://docs.docker.com/engine/reference/run/#ipc-settings-ipc for reference.
Note: this feature shouldn't affect solutions not using IPC.
Thanks!

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

Запись "400 != 200" неочевидна, вопрос "где чьё" регулярно возникает в чате.

Благодаря этому фильтру можно соревноваться не только за общий топ, но и даже внутри одной компании. Например, можно просто доработать поисковое поле, чтобы оно также искало по стеку/стране/городу.

Вроде говорили, что во второй фазе не будет зависящих друг от друга запросов. В то же время в TRAIN-данных вижу следующее:

379 POST:/locations/new
<...>
{"id": 838, <...>}

<...>

207 POST:/visits/<entity_id>
<...>
{<...>, "location": 838}

Если сначала обработать первый запрос, второй вернёт 200; если сначала второй, то он должен вернуть 400.

Также конкретно сегодня на тестовом прогоне как минимум я и @atercattus получили во второй фазе сначала обновление юзера 1006, а потом уже создание (id моего решения 12984)

На этапе 9 получаю

Ошибка при выполнении docker-compose up...
Pulling client_8440 (stor.highloadcup.ru/travels/falcon_flyera:latest)...

Делал около 20 попыток запуска начиная со вчерашнего дня.
Примеры запусков 16880, 16780.

ЯП, БД, ОС.

По ней было бы удобно оценивать эффективность с примененным фильтром для конкретного API, а то сейчас это сделать невозможно, т.к. не известен профиль конкретного типа запроса, например, GET:/users/<entity_id>/visits.
Также была бы удобна колонка с медианой.

Отсутствие keep-alive и pipelining запросов приводит к тому, что системы заточенные на асинхронную обработку запросов проигрывают. Современный веб всё равно почти весь с keep-alive, а поддержать это корректно в "велосипедном" решении не просто. Более реалистичные условия выполнения тестов выровняют шансы. Туда же относится выставление content-type, accept и прочих headers, а так же проверка корректной обработки решением этих нюансов.

и если не лень - с разделителями разрядов

Хотелось бы получать Content-Length для всех POST запросов.
Сейчас пустые POST идут без Content-Length и Kestrel их отбрасывает с 411, а тестер ждет 400

Сначала линейно нарастает RPS, потом так же линейно падает.
Будет видно как система восстанавливается после нагрузки.

Решение id=5255 застряло на "Возвращение результатов из системы обстрела"

Следующие решения соответветственно в очереди застряли.

Колонки
кол-во timeout'ов
кол-во неправильных ответов
Суммарный штраф (выводится сейчас только эта колонка)

Это было бы полезно для вывода в лог агрегированной информации по производительности. После ответа на этот запрос завершать процесс.

На графиках где-то миллисекунды, где-то микросекунды. Необходимо привести всё к миллисекундам.

Танк/phantom открывает instances коннектов и равномерно распределяет нагрузку по ним (не параллельно), хотя для обстрела ему достаточно 1-2 коннектов (что и показывается в консоли с танком, см. скриншот).

Скрины в аттаче, дамп трафика - https://yadi.sk/d/4gEtJpYt3MDZ3R

Вопрос - это его штатное поведение или я что-то делаю не так? Очень похоже, что в бою ситуация точно такая же.
Например, у меня оптимизация под < 10 коннектов, что при выставлении instances=10 дает огромый прирост скорости (измерял танком), но вот при instances = 1000 моя оптимизация не работает и соотв. я получаю бОльшее время, хотя танк укладывается и там и там.

Запуск докера: docker run -v $(pwd):/var/loadtest --net host -it --rm direvius/yandex-tank -c load/load_3.ini

На 80 порту висит обычный nginx, с моим серверов ситуация точно такая же.

load_3.ini:

address=127.0.0.1
port=80
rps_schedule=line(200, 2000, 120s)

ammo_type=phantom
ammofile=data/FULL/ammo/phase_3_get.ammo
instances = 1000