Comments 72
Участник может использовать любые серверные технологии, языки, фреймворки по своему усмотрению (C++, Java + Tomcat, Python + Django, Ruby + RoR, JavaScript + NodeJs, Haskell или что-то еще). Также и для хранения данных: MySQL, Redis, MongoDB, Memcached — всё, что получится запихнуть в docker.То есть, нужно все зависимости вложить в один контейнер? Это, хотя бы, не красиво. Допустимо, конечно. Почему не композ, например?
Еще вариант — написать all-in-one решение, те отнестить к вашему капу как к олимпиадной задаче, а не похожей на реальнй хайлоад
В Location (Достопримечательность) записаны следующие данные:
id — уникальный внешний id достопримечательности. Устанавливается тестирующей системой. 32-разрядное целое число.
place — описание достопримечательности. Текстовое поле неограниченной длины.
country — название страны расположения. unicode-строка длиной до 50 символов.
city — название города расположения. unicode-строка длиной до 50 символов.
distance — расстояние от города по прямой в километрах. 32-разрядное целое число.
из location_1.json
«distance»: 6, «city»: «Москва», «place»: «Набережная», «id»: 1, «country»: «Аргентина»
distance — расстояние от города по прямой в километрах, расстояние к чему?
если
country — название страны расположения. unicode-строка длиной до 50 символов.
и
city — название города расположения. unicode-строка длиной до 50 символов.
то почему «city»: «Москва» и «country»: «Аргентина» а не «Россия»?
с толку сбивает, или я что-то не понимаю?
Да, именно так. У нас там есть Москва внутри Аргентины, Кремль в 100 км от Москвы, 130-летние люди, все это посещающие… Это все прелести генеренных тестовых данных, отнеситесь к ним с юмором :)
Если есть конечный пункт (достопримечательность), должен быть начальный (город). И согласитесь, странно в голове поместить, когда начальный пункт заканчивается к конечном (от города до достопримечательности, но достопримечательность находиться в городе).
Город как некая единица A к которой может относится достопримечательность B?
Город как некая единица Z с множеством достопримечательностей [A`,B`,..,Z`]? тогда от города, скорее всего, понимать как от некоторой начальной точки с чего город начинается, ну не знаю, нулевой километр, например.
Вообще, читая описание задания и методов, мое недопонимание самоисчерпывающее из контекста задачи, тупо лупим от города до достопр., и все, алгоритм работает, но както при привычке и работе охота понимать контекст, а не лепить догадки))
Не хочу показаться придирчивым =)
Задача интересная, не то что «посчитать комбинации проколов трамвайного талона NxK компостером IxJ» и всякое такое, было както у нас )
Некоторые участники пишут кастомные плюсовые велосипеды :)
Так что возможно нас всех ждет сюрприз. В любом случае, очень интересно какой стек попадет в топ
--net=host
будет запускаться?А можно стрелять в ответ?
Опять же, важно чтобы когда у вас вместо 5000 RPS стало 50000 RPS вы просто добавили серверов. А когда надо добавить фичу — просто ее добавили. А здесь победит C/C++-шный велосипед, с libevent, hashmap и btree в памяти и конечным автоматом вместо полноценного парсера JSON. Как это относится к highload — сложно сказать.
Я даже думал написать такой на Scala (на плюсах 10 лет не писал), но объективно понимаю что код который хочется писать (production-ready) даже близко к топу не окажется.
Может стоило скажем запускать 2-5-10 слабых контейнеров чтобы частью задачи было распределение нагрузки и синхронизация хранилища? Тут уже встал бы вопрос делать одно выделенное хранилище или распределять запросы, скажем по id. И как тогда считать запросы на аггрегацию. Желательно чтобы еще посреди теста рандомные контейнеры дохли и новые поднимались.
И объем данных увеличить чтобы не влезал в оперативную память, а в идеале и на винт одной единственной машины. В принципе тоже понятно как решать такую задачу, но уже скорее использовали бы какие-то СУБД чтобы не изобретать кластеризацию на коленке.
Но упороться очень хочется! Если первый чемпионат пройдет хорошо, обязательно обмеряем и durability, и распределенные игрища, и контейнеры будет рандомно шатдаунить, чтобы посмотреть на балансировку…
Короче, у нас много веселых идей, но все они не для первого запуска, поэтому и делаем пока что вот такой странный хайлоад, который больше просто про нормальный backend :)
Первый раунд — это первый чемпионат? Или в этом чемпионате будет много раундов?
Перед обстрелом запланировано 180 секунд ожидания для того чтобы решение участника могло проанализировать переданные тестовые данные и подготовиться к обстрелу.
180 секунд длится первая фаза с линейным профилем от 1 до 200 RPS.
120 секунд длится вторая фаза с постоянным профилем в 100 RPS
120 секунд длится третья фаза с линейным профилем от 200 до 2000 RPS.
Но на самом деле еще проще, на самом деле одновременных запросов на запись и чтение вроде не намечается. Вся запись в фазе 2
Как обычно. Модификация должна быть атомарная, что б данные не бились.
собрать его в docker-контейнер и залить в хранилище
Эм… докер уже сам по себе большое бутылочное горлышко.
Ок
- Overlay / macvlan / OVS драйвер докера уже имеет довольно высокие накладные расходы и не подходит для чего-то серьёзного.
- Есть очень много настроек уровня ядра: шедуллер iommu vfio большие страницы афинность
- Если речь идёт о 10/40Gbit трафика и 1М+ RPS с poll-mode драйверами на DPDK ?
При проектировании решения участник не ограничен ничем
Вы уже поставили довольно много палок в колёса участникам используя посредственное окружение и очень субъективную оценку.
\o/
Прикольно когда организаторы чемпионата по highload'у не знают какой нынче highload бывает.
У меня малость пригорает.
Это не "мой привычный подход", просто есть user-space решения которые позволяют обрабатывать больше одного миллиона запросов в секунду. Существующие kernel-space решения имеют довольно много ограничений: лишних копирований буферов с kernel-space в user-space, смен контекстов выполнения, избыточного менеджмента памяти etc
Меня кумарит немного факт что highload рассматривается только в рамках общепринятых прикладных решений которые не работают с железом напрямую — там уже задача ставится как "давайте обработаем запрос клиента за 800 процессорных тактов с когерентностью кэша и использованием cache streaming подходов".
Всем не угодишь, к сожалению. Мы рассматривали вариант дать прям живых тачек, отказались от него по понятным причинам
Прочитал эту статью днем, пока ехал с работы, подумал. И решил спросить — а можно ли от одного участника несколько образов выставить? Интересно было бы посмотреть распределение в итоговых результатах различных подходов.
cd /tmp/data && ls -la && unzip data.zip && rm data.zip
Не выполняется на проде т.к. /tmp подмонтирован почему-то как read.
Передаю привет docker-compose
Тарантул с нжинксом интересно выложит кто-то?
А вообще бредовый конечно квест. 2000 rps выдержит что угодно, а мерять latency… Осипов сказал, например, что в тарантуле пожертвовали latency ради throughput.
Есть lock-free и есть wait-free подходы, а в системах реального времени используется временное разделение…
По CAP теореме можем пожертвовать либо консистентностью либо доступностью, а в случае с высоконагрузом это значит задержка vs пропускная способность.
На DPDK, к примеру, решения работают напрямую с железом — там нет распространённых накладных расходов на коммуникацию и трансляцию вызовов, высоконагрузы уже начинаются с 1М RPS.
В приложениях на golang'e с использованием fasthttp тот же nginx или haproxy уже является бутылочным горлышком при RPS 80K+. Сторонние кэши типа redis/memcached тоже не вписываются из-за больших накладных расходов на коммуникацию. C fasthttp и тюнингом настроек ядра можно выжать 300К rps… опять же, тут никто не даст поправить sysctl или ядро пересобрать с rt патчами.
Было бы лучше смотреть на flame-graph'ы под нагрузкой и метрики сложности CFG, чем проводить эстимации в RPS'e — это была бы более точная эстимация при совместном использовании распространённых производительных решений.
В результатах только пишется что Code не совпадает, посмотреть тело запроса нельзя.
«Фаза обстрела # 2 (POST)», Locations — «Ответов с неверным http-кодом 3», и непонятно как это исправлять.
Уже все перебрал, и id <= 0, и добавление location уже существующего, и какие-то органичения, следующие из описания сущностей, кстати, там непонятна формулировка: «unicode-строка длиной до 50 символов.», часто сталкивался что люди по-разному такую формулировку понимают, "<" или "<=".
Плюс к этому непонятно, какие поля надо проверять на обязательность заполнения, какие нет, какие поля на что проверять (существование связанных сущностей и т.п.), а каким можно доверять.
В общем хотелось бы более четкого описания на что отвечать 400.
2. Еще по user.birth_day, в описании «Ограничено снизу 01.01.1930 и сверху 01.01.1999-ым.». В тестовом data.zip, первый же user имеет "-1720915200", это 1915 год. Что делать с таким юзером?
3. В фазе 1 остался один неверный ответ из 125 — 1. /locations/353/avg?toAge=34&fromAge=24. Тоже непонятно как исправлять с черным ящиком. Сильно сомнительно, что где-то ошибка в алгоритме, или в округлениях, которая вылазит только в одном случае.
В одном посылке максимальное количество instance 3, в другой 378 — это как понимать? В гарантируете что текущий рейтинг у каждого пользователь построен по одному профилю. Вы гарантируете, что у всех пользователей в каждый такт времени делаете одинаковое количество запросов?
Яндекс-танк добавляет инстансов, если видит, что с текущим concurrency Вы не влезаете в заявленный рпс. Мы гарантируем, что условия у всех одинаковые, включая профили обстрела и мощности серверов. В финале каждое решение будет обстреливаться несколько раз, а итоговый рейт — усредняться.
Тогда давайте начинать сразу слать сразу в 400 потоков (одновременно), смотреть что latencety выросло и добавлять ещё…
Вам уже писали, что используете не правильный подход замера, так же писали что колебания доходят до 40% на одном и той же посылке.
По мне правильный подход для оценки решения следующий:
Вы даете постоянную нагрузку на систему в k потоков(синхронные запросы) в заданный промежуток времени и получаете количество успешных и валидных ответов. К этому можно замерять 95 перцентиль. И из полученных показателей обработанных сообщений и времени строить рейтинг.
Дальше по задаче: затраты ресурсов на логику должны больше. Перед стартом обстрелом делаю свой тест железа.
String idString = request.getRequestURI().replace("/tests/","");
writer.write(idString);
И получаю
client_8513_1 |TestGet:=0.10689574209999998 ms Amount := 10000
client_8513_1 |TestRealGet:=2.2555675474 ms Amount := 10000
0.1 мс на работу внутри пустого севлета, и 2.25 мс снаружи.
А теперь задача. Средняя время работы логики
client_8513_1 |UserNew:=0.16407041119402985 ms Amount := 1340
0.16 мс на запрос
Из этого следует. Можно нафиг выкинуть всю логику (сделать только вывод id из request path), которую надо реализовать, а просто меряться языком на котором участник пишет и на сколько легок его http сервер…
По мне в соревнованиях хочется мериться в скорости в том, что ты пишешь, а не в том какой язык + framework, хотя может действительно смысл контеста писать сам сервер, а не логику.
Но скажу что дают подобные события лично для меня.
В первую очередь — как возможность использовать новые технологии, разобраться с новыми стеками, экспериментировать одним словом.
Конкретно сабжа — привлекло задание своим контекстом, конечно технически осуществление проверки результата понятно лишь с слов и графической схемы, что там на самом деле под капотом — лишь авторам известно.
Вот и этот чемпионат для меня стал некой площадкой эксперимента… Давно игрался с Go, но в компании использовать — не было подходящего времени… а тут — какраз некое задание создать простой сервис, сервис создал, провел AB-тест, Apache JMeter обстрелял, результаты впечатлили, но начал возится с докерами, скрестил mysql+golang, и так как время до завершение еще было — начал делать микросервисы на Го в компании в которой работаю (какраз время пришло изменять старые части системы)…
В результате, небольшая работа, которая была проделана в рамках чемпионата размещенной не была, но за это время удалось создать три стабильных микросервиса которые успешно внедрены в нашей компании )
Начали за здравие — кончили за упокой. Увлечение одним заданием привело к нахождения хороших решения для других бизнес-задач.
Новый чемпионат для backend-разработчиков: HighLoad Cup