Comments 72
Участник может использовать любые серверные технологии, языки, фреймворки по своему усмотрению (C++, Java + Tomcat, Python + Django, Ruby + RoR, JavaScript + NodeJs, Haskell или что-то еще). Также и для хранения данных: MySQL, Redis, MongoDB, Memcached — всё, что получится запихнуть в docker.То есть, нужно все зависимости вложить в один контейнер? Это, хотя бы, не красиво. Допустимо, конечно. Почему не композ, например?
Честно говоря, с докером и так много повоевали, на compose просто сил не хватило. А с compose мы получили бы какое-то убер-преимущество?
Участники бы получили: сейчас нужно все собрать в одном докере и решить проблемы зависимостей, если вдруг случатся, ну и потратить на это врем гарантированно. Либо засунуть докер в докер, чтобы не воевать с зависимостями.
Еще вариант — написать all-in-one решение, те отнестить к вашему капу как к олимпиадной задаче, а не похожей на реальнй хайлоад
Еще вариант — написать all-in-one решение, те отнестить к вашему капу как к олимпиадной задаче, а не похожей на реальнй хайлоад
Я нигде не нашёл информации про допустимый размер JSON. Он умещается в память?
Недопонимание
из location_1.json
distance — расстояние от города по прямой в километрах, расстояние к чему?
если
и
то почему «city»: «Москва» и «country»: «Аргентина» а не «Россия»?
с толку сбивает, или я что-то не понимаю?
В 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»: «Аргентина» а не «Россия»?
с толку сбивает, или я что-то не понимаю?
Да по моему просто рандомно сгенерированные данные, за действительность брать не нужно. А distance — от города до достопримечательности.
Да, именно так. У нас там есть Москва внутри Аргентины, Кремль в 100 км от Москвы, 130-летние люди, все это посещающие… Это все прелести генеренных тестовых данных, отнеситесь к ним с юмором :)
Как воспринимать от «города до достопримечательности»?
Если есть конечный пункт (достопримечательность), должен быть начальный (город). И согласитесь, странно в голове поместить, когда начальный пункт заканчивается к конечном (от города до достопримечательности, но достопримечательность находиться в городе).
Город как некая единица A к которой может относится достопримечательность B?
Город как некая единица Z с множеством достопримечательностей [A`,B`,..,Z`]? тогда от города, скорее всего, понимать как от некоторой начальной точки с чего город начинается, ну не знаю, нулевой километр, например.
Вообще, читая описание задания и методов, мое недопонимание самоисчерпывающее из контекста задачи, тупо лупим от города до достопр., и все, алгоритм работает, но както при привычке и работе охота понимать контекст, а не лепить догадки))
Не хочу показаться придирчивым =)
Задача интересная, не то что «посчитать комбинации проколов трамвайного талона NxK компостером IxJ» и всякое такое, было както у нас )
Если есть конечный пункт (достопримечательность), должен быть начальный (город). И согласитесь, странно в голове поместить, когда начальный пункт заканчивается к конечном (от города до достопримечательности, но достопримечательность находиться в городе).
Город как некая единица A к которой может относится достопримечательность B?
Город как некая единица Z с множеством достопримечательностей [A`,B`,..,Z`]? тогда от города, скорее всего, понимать как от некоторой начальной точки с чего город начинается, ну не знаю, нулевой километр, например.
Вообще, читая описание задания и методов, мое недопонимание самоисчерпывающее из контекста задачи, тупо лупим от города до достопр., и все, алгоритм работает, но както при привычке и работе охота понимать контекст, а не лепить догадки))
Не хочу показаться придирчивым =)
Задача интересная, не то что «посчитать комбинации проколов трамвайного талона NxK компостером IxJ» и всякое такое, было както у нас )
UFO just landed and posted this here
UFO just landed and posted this here
Оно хоть с
--net=host будет запускаться?
А можно стрелять в ответ?
Вобщем-то задача не совсем про highload получилась. В реальном highload нужен большой RPS, и возможность легко масштабироваться, а latency не так критична. А 2000 RPS выдаст вообще что угодно не сильно скриптовое.
Опять же, важно чтобы когда у вас вместо 5000 RPS стало 50000 RPS вы просто добавили серверов. А когда надо добавить фичу — просто ее добавили. А здесь победит C/C++-шный велосипед, с libevent, hashmap и btree в памяти и конечным автоматом вместо полноценного парсера JSON. Как это относится к highload — сложно сказать.
Я даже думал написать такой на Scala (на плюсах 10 лет не писал), но объективно понимаю что код который хочется писать (production-ready) даже близко к топу не окажется.
Может стоило скажем запускать 2-5-10 слабых контейнеров чтобы частью задачи было распределение нагрузки и синхронизация хранилища? Тут уже встал бы вопрос делать одно выделенное хранилище или распределять запросы, скажем по id. И как тогда считать запросы на аггрегацию. Желательно чтобы еще посреди теста рандомные контейнеры дохли и новые поднимались.
И объем данных увеличить чтобы не влезал в оперативную память, а в идеале и на винт одной единственной машины. В принципе тоже понятно как решать такую задачу, но уже скорее использовали бы какие-то СУБД чтобы не изобретать кластеризацию на коленке.
Опять же, важно чтобы когда у вас вместо 5000 RPS стало 50000 RPS вы просто добавили серверов. А когда надо добавить фичу — просто ее добавили. А здесь победит C/C++-шный велосипед, с libevent, hashmap и btree в памяти и конечным автоматом вместо полноценного парсера JSON. Как это относится к highload — сложно сказать.
Я даже думал написать такой на Scala (на плюсах 10 лет не писал), но объективно понимаю что код который хочется писать (production-ready) даже близко к топу не окажется.
Может стоило скажем запускать 2-5-10 слабых контейнеров чтобы частью задачи было распределение нагрузки и синхронизация хранилища? Тут уже встал бы вопрос делать одно выделенное хранилище или распределять запросы, скажем по id. И как тогда считать запросы на аггрегацию. Желательно чтобы еще посреди теста рандомные контейнеры дохли и новые поднимались.
И объем данных увеличить чтобы не влезал в оперативную память, а в идеале и на винт одной единственной машины. В принципе тоже понятно как решать такую задачу, но уже скорее использовали бы какие-то СУБД чтобы не изобретать кластеризацию на коленке.
Дааа! Всё это у нас в планах :) Просто в первом, тестовом чемпионате мы не стали так упарываться. Чтобы, во-первых, порог входа, а во-вторых, сложность отладки для нас самих. Сами знаете, как это бывает :)
Но упороться очень хочется! Если первый чемпионат пройдет хорошо, обязательно обмеряем и durability, и распределенные игрища, и контейнеры будет рандомно шатдаунить, чтобы посмотреть на балансировку…
Короче, у нас много веселых идей, но все они не для первого запуска, поэтому и делаем пока что вот такой странный хайлоад, который больше просто про нормальный backend :)
Но упороться очень хочется! Если первый чемпионат пройдет хорошо, обязательно обмеряем и durability, и распределенные игрища, и контейнеры будет рандомно шатдаунить, чтобы посмотреть на балансировку…
Короче, у нас много веселых идей, но все они не для первого запуска, поэтому и делаем пока что вот такой странный хайлоад, который больше просто про нормальный backend :)
Я что-то не понял из интерфейса и описания: сколько будет раундов?
Первый раунд — это первый чемпионат? Или в этом чемпионате будет много раундов?
Первый раунд — это первый чемпионат? Или в этом чемпионате будет много раундов?
А запросы идут один за другим или несколько параллельно?
Несколько. Процитирую с сайта:
Перед обстрелом запланировано 180 секунд ожидания для того чтобы решение участника могло проанализировать переданные тестовые данные и подготовиться к обстрелу.
180 секунд длится первая фаза с линейным профилем от 1 до 200 RPS.
120 секунд длится вторая фаза с постоянным профилем в 100 RPS
120 секунд длится третья фаза с линейным профилем от 200 до 2000 RPS.
Перед обстрелом запланировано 180 секунд ожидания для того чтобы решение участника могло проанализировать переданные тестовые данные и подготовиться к обстрелу.
180 секунд длится первая фаза с линейным профилем от 1 до 200 RPS.
120 секунд длится вторая фаза с постоянным профилем в 100 RPS
120 секунд длится третья фаза с линейным профилем от 200 до 2000 RPS.
А как тогда обрабатывать запросы на модификацию одновременно с запросами на чтение?
А в чем проблема-то? Так же как вы и вы жизни обрабатываете. Либо БД сама разрулит, либо, если все в памяти — использовать конкурентные структуры данных.
Но на самом деле еще проще, на самом деле одновременных запросов на запись и чтение вроде не намечается. Вся запись в фазе 2
Но на самом деле еще проще, на самом деле одновременных запросов на запись и чтение вроде не намечается. Вся запись в фазе 2
Как обычно. Модификация должна быть атомарная, что б данные не бились.
В первом чемпионате мы решили эту проблему за вас — первая фаза это readonly-запросы, вторая — post с редактированием/добавлением данные, третья — снова get-запросы
собрать его в 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 подходов".
Видим, что пригорает :)
Всем не угодишь, к сожалению. Мы рассматривали вариант дать прям живых тачек, отказались от него по понятным причинам
Всем не угодишь, к сожалению. Мы рассматривали вариант дать прям живых тачек, отказались от него по понятным причинам
Не нашел. В качестве id в json используется беззнаковое 32-битное число или знаковое?
У нас был один сервер, 5 дисков, 20 пакетиков с растворимым кофе и 48 часов до начала чемпионата. Не то чтобы это много, но раз уж решил быть организатором, то надо провести его до конца. Единственное, что беспокоило — это докер. В мире нет никого более беспомощного, безответственного и безнравственного, чем человек запускающий все в одном контейнере. И я знал, что довольно скоро мы в это окунёмся…
Не работает кнопка войти на https://highloadcup.ru, ничего не происходит после нажатия (Chrome 59.0.3071.115)
Прочитал эту статью днем, пока ехал с работы, подумал. И решил спросить — а можно ли от одного участника несколько образов выставить? Интересно было бы посмотреть распределение в итоговых результатах различных подходов.
Вот такая команда
cd /tmp/data && ls -la && unzip data.zip && rm data.zip
Не выполняется на проде т.к. /tmp подмонтирован почему-то как read.
Передаю привет docker-compose
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 — это была бы более точная эстимация при совместном использовании распространённых производительных решений.
Там тесты на 70k+ RPS
1. А можно как-нибудь получить более детальное описание, на какие запросы 400 надо отвечать?
В результатах только пишется что 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. Тоже непонятно как исправлять с черным ящиком. Сильно сомнительно, что где-то ошибка в алгоритме, или в округлениях, которая вылазит только в одном случае.
В результатах только пишется что 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. Тоже непонятно как исправлять с черным ящиком. Сильно сомнительно, что где-то ошибка в алгоритме, или в округлениях, которая вылазит только в одном случае.
Оч. прошу пушнуть https://github.com/sat2707/hlcupdocs/issues/26, три дня убил на чемпионат.
Что за жесть, почему у вас не совпадают профили на двух рейтинговых посылках.
В одном посылке максимальное количество instance 3, в другой 378 — это как понимать? В гарантируете что текущий рейтинг у каждого пользователь построен по одному профилю. Вы гарантируете, что у всех пользователей в каждый такт времени делаете одинаковое количество запросов?
В одном посылке максимальное количество instance 3, в другой 378 — это как понимать? В гарантируете что текущий рейтинг у каждого пользователь построен по одному профилю. Вы гарантируете, что у всех пользователей в каждый такт времени делаете одинаковое количество запросов?
Яндекс-танк добавляет инстансов, если видит, что с текущим concurrency Вы не влезаете в заявленный рпс. Мы гарантируем, что условия у всех одинаковые, включая профили обстрела и мощности серверов. В финале каждое решение будет обстреливаться несколько раз, а итоговый рейт — усредняться.
Яндекс-танк добавляет инстансов — этим и противоречите себе — новый instance = другой профиль.
Тогда давайте начинать сразу слать сразу в 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, хотя может действительно смысл контеста писать сам сервер, а не логику.
Тогда давайте начинать сразу слать сразу в 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, хотя может действительно смысл контеста писать сам сервер, а не логику.
Не очень понял, где мы сами себе противоречим. В финале, кстати, будем брать лучший score из нескольких обстрелов одного и того же решения, надеюсь, что это снизит влияние разброса. Да, есть к чему прислушаться с точки зрения бекенда и метрики. Но, в чемпионате уже есть 600 участников, которые нашли, как и чем померяться, внезапно менять ТЗ будет некрасиво. В следующем конкурсе обязательно учтем, спасибо за советы :)
UFO just landed and posted this here
Согласен. Вот лично никогда не участвовал в олимпиадах и соревнованиях, не находил это занятие привлекательным и всегда находил более интересные вещи чем мериться сами знаете чем.
Но скажу что дают подобные события лично для меня.
В первую очередь — как возможность использовать новые технологии, разобраться с новыми стеками, экспериментировать одним словом.
Конкретно сабжа — привлекло задание своим контекстом, конечно технически осуществление проверки результата понятно лишь с слов и графической схемы, что там на самом деле под капотом — лишь авторам известно.
Вот и этот чемпионат для меня стал некой площадкой эксперимента… Давно игрался с Go, но в компании использовать — не было подходящего времени… а тут — какраз некое задание создать простой сервис, сервис создал, провел AB-тест, Apache JMeter обстрелял, результаты впечатлили, но начал возится с докерами, скрестил mysql+golang, и так как время до завершение еще было — начал делать микросервисы на Го в компании в которой работаю (какраз время пришло изменять старые части системы)…
В результате, небольшая работа, которая была проделана в рамках чемпионата размещенной не была, но за это время удалось создать три стабильных микросервиса которые успешно внедрены в нашей компании )
Начали за здравие — кончили за упокой. Увлечение одним заданием привело к нахождения хороших решения для других бизнес-задач.
Но скажу что дают подобные события лично для меня.
В первую очередь — как возможность использовать новые технологии, разобраться с новыми стеками, экспериментировать одним словом.
Конкретно сабжа — привлекло задание своим контекстом, конечно технически осуществление проверки результата понятно лишь с слов и графической схемы, что там на самом деле под капотом — лишь авторам известно.
Вот и этот чемпионат для меня стал некой площадкой эксперимента… Давно игрался с Go, но в компании использовать — не было подходящего времени… а тут — какраз некое задание создать простой сервис, сервис создал, провел AB-тест, Apache JMeter обстрелял, результаты впечатлили, но начал возится с докерами, скрестил mysql+golang, и так как время до завершение еще было — начал делать микросервисы на Го в компании в которой работаю (какраз время пришло изменять старые части системы)…
В результате, небольшая работа, которая была проделана в рамках чемпионата размещенной не была, но за это время удалось создать три стабильных микросервиса которые успешно внедрены в нашей компании )
Начали за здравие — кончили за упокой. Увлечение одним заданием привело к нахождения хороших решения для других бизнес-задач.
Вы говорите о каком-то другом соревновании. Наше длилось три недели, и от скорости написания кода успех не зависел.
UFO just landed and posted this here
Sign up to leave a comment.
Новый чемпионат для backend-разработчиков: HighLoad Cup