Как стать автором
Обновить

HighLoad Cup #2. Чемпионат для backend-разработчиков снова в строю

Время на прочтение 7 мин
Количество просмотров 16K
Всего голосов 56: ↑55 и ↓1 +54
Комментарии 37

Комментарии 37

3 приза на ~449 человек
невнимателен, прошу прощения.
топовые решения будут опубликованы/разобраны?
Мы очень попросим участников :)
Хотелось бы попробовать новый стек, но боюсь что размер данных будет небольшой, всё влезет в память как в прошлом году и в подходах особо ничего не изменится.
На данный момент в бете 810 мб, но с 21 числа будет совсем другая цифра.

Про фильтрацию и группировку вопросов нет, а как вы будете оценивать корректность ответа на запросы /recomnend и /suggest?

На сайте описаны запросы подробнее, /suggest там определён однозначно. А вот про recommend совсем непонятно — то ли нужно отсортировать лексикографически по 4м параметрам, то ли возможен более творческий подход.
И ко всем запросам, включая фильтраци и сортировку — как оцениваются возможные различия из-за конфликтов GET-POST, ведь как там написано — танк посылает запросы в нескольких TCP сессиях параллельно?

Сегодня правила найти будет очень просто

Ребят, и сразу вопрос — вы там фамилию запрашиваете при регистрации. Без условий и прайвеси полиси. Как там у вас с персональными данными, 152-ФЗ и вот этим вот всем? Входит ли в обязательные условия участия подписка на пожизненный персонализированный спам от партнёров мейл.ру?

Оууу, ты прав. Добавим соглашение об обработке сегодня же. Оно у нас стандартное для всех проектов чемпионатов. Ознакомиться можно здесь https://mlbootcamp.ru/static/core/files/agreement.pdf. Для HighLoad Cup тоже самое)

и персонализированного спама не ждите!!! :)

А можно без контейнеров, а то это совсем несерьёзный HighLoad получается ?

А расскажите про оверхед контейнеров.
А то нынче все эти docker'ы в моде.

Оверхед сейчас в основном в persistence/network layer'aх, OverlayFS до сих пор радует, надо менять на что-то DPDK/SPDK совместимое, иначе этот весь лощёный Highload не более чем масштабирование простоя процессора. В целом, наличие Control Group'ы и соответствующих namespace'ов тоже даёт overhead, он почти такой-же как и от KVM'a сейчас...


Вряд ли они используют sriov для выполнения DPDK драйверов… С SPDK ситуация сейчас посложнее и готового решения для blobfs нету, ContainerD пока не поддерживает pluggable storage.


Лучшим примером DPDK приложения сейчас можно назвать ScyllaDB, по сравнению с ней все местные поделки на golang'e по 200К RPS выглядят довольно блекло.

Да до DPDK в прикладных задачах вроде этой как до луны, там упрёшься в алгоритмы и структуры данных (диск/cpu/память) раньше чем в IO. В суровом продакшен энтерпрайзе до асинхронщины-то с epoll часто не доходит, хватает просто кучи preemptive тредов.

там упрёшься в алгоритмы и структуры данных (диск/cpu/память) раньше чем в IO

Я думаю мне не стоит это комментировать, но действительно, многих и масштабирование простоя железа устраивает, и сопутствующий ClusterFuck тоже вроде как норм… слишком много притворства и невежества, к жизнеспособности решений отношения особо не имеет. Это как шутка про профилирования питона в Uber'e...


В суровом продакшен энтерпрайзе до асинхронщины-то с epoll часто не доходит

Обычно уже решено на уровне каких-то netty/jetty/uvloop/libev etc.

А почему не хотите контейнеры?

На контейнерах 200-300К RPS потолок, на DPDK/SPDK 2-6M RPS потолок…
По этому подобные условия соревнований особо серьёзно не воспринимаю.

НЛО прилетело и опубликовало эту надпись здесь

Сегодня будет там все самое необходимое по новому чемпионату.

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

Тоесть не важно ответил ты правильно или нет — всёравно рейтинг посчитается как сумма ответов? Только в случае верного ответа это назовётся «временем ответа», а в случае ошибочного — «штрафом»
Можно на каждый запрос отвечать сразу return 200 c задержкой в 20ns
Логично, что нет. Штрафное время = таймауту, аля 30с, или что-то типа этого.
Из Украины не заходит на сайт (при том что сайт другого Вашего чемпионата — RAIC прекрасно работает). Хотелось бы поучаствовать, но для этого нужно заморачиваться с обходом блокировки. Будет ли эта проблема как-то решаться?
Ого… Обязательно проверим, но я думаю, что это нужно задать вопрос вашему провайдеру — почему оно так.
Елки палки, надеюсь кто — то сделает там решение на Rust. Сам я к сожалению, не обладаю пока что для этого должным уровнем навыков. Только опозорю технологию, почем зря. А вообще да, как выше уже говорили, тестировать производительность в докер контейнерах это такое себе.
" Перед началом обстрела у пользовательского решения есть несколько минут (точное количество зависит от задачи), чтобы обработать данные из полученного JSON-файла. "
Никак не могу найти, каким образом получать JSON-файл. Я уже сделал контейнер, который при запуске разворачивает http сервер. В него что-то надо добавить?
Отсюда highloadcup.ru/media/condition/accounts_rules.html
После запуска контейнера в папке /tmp/data будет доступен файл data.zip с архивированными «боевыми» данными (примерно 10 MB данных для предварительного и 1 GB для полного обстрела). Обратите внимание, что каталог /tmp/data доступен только для чтения, поэтому решение должно загружать архив в ОЗУ для обработки. В самом архиве будут лежать файлы с названиями вида «accounts_<номер файла>.json». Внутри таких файлов — валидные данные в формате JSON.


Пример такого файла можно взять тут highloadcup.ru/ru/round/3 (раздел «Тестовые данные»)

а что за файл options.txt в архиве data.zip?
Этот файл лежит в архиве рядом с *.json файлами. Из него (его первой строки) нужно получать время генерации датасета, чтобы запрос с today/now работали корректно.

Или уже был?
Хотелось поучаствовать

Будет в 2020? :)

Без DPDK/SPDK смысла участвовать особо то нет...

Зарегистрируйтесь на Хабре , чтобы оставить комментарий