Comments 37
Про фильтрацию и группировку вопросов нет, а как вы будете оценивать корректность ответа на запросы /recomnend и /suggest?
На сайте описаны запросы подробнее, /suggest
там определён однозначно. А вот про recommend
совсем непонятно — то ли нужно отсортировать лексикографически по 4м параметрам, то ли возможен более творческий подход.
И ко всем запросам, включая фильтраци и сортировку — как оцениваются возможные различия из-за конфликтов GET-POST, ведь как там написано — танк посылает запросы в нескольких TCP сессиях параллельно?
понадобилось время чтобы найти правила https://highloadcup.ru/media/condition/accounts_rules.html
Оууу, ты прав. Добавим соглашение об обработке сегодня же. Оно у нас стандартное для всех проектов чемпионатов. Ознакомиться можно здесь 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.
А почему не хотите контейнеры?
Рейтинг решения рассчитывается так: берем время всех верных ответов, которые успел дать API во время обстрела, прибавляем штрафное время за каждый неправильный ответ или запрос, ответ на который мы не смогли получить (штрафное время всегда равно общему таймауту запроса).
Тоесть не важно ответил ты правильно или нет — всёравно рейтинг посчитается как сумма ответов? Только в случае верного ответа это назовётся «временем ответа», а в случае ошибочного — «штрафом»
Можно на каждый запрос отвечать сразу return 200 c задержкой в 20ns
Никак не могу найти, каким образом получать JSON-файл. Я уже сделал контейнер, который при запуске разворачивает http сервер. В него что-то надо добавить?
После запуска контейнера в папке /tmp/data будет доступен файл data.zip с архивированными «боевыми» данными (примерно 10 MB данных для предварительного и 1 GB для полного обстрела). Обратите внимание, что каталог /tmp/data доступен только для чтения, поэтому решение должно загружать архив в ОЗУ для обработки. В самом архиве будут лежать файлы с названиями вида «accounts_<номер файла>.json». Внутри таких файлов — валидные данные в формате JSON.
Пример такого файла можно взять тут highloadcup.ru/ru/round/3 (раздел «Тестовые данные»)
Будет в 2019?
HighLoad Cup #2. Чемпионат для backend-разработчиков снова в строю