highload проект что такое
Highload и High avalability: сервисы с высокой нагрузкой
В 2018 году highload-проектами уже никого не удивишь. Тому способствует как и новомодная микросервисная архитектура, так и ставшая уже классикой SOA (Service-oriented Architecture), пришедшие на смену монолитным приложениям. Удобство разработки, мониторинга, администрирования и масштабирования современного ПО создают многократные оверхеды на все типы ресурсов: процессор, оперативную память, дисковую подсистему и сеть, что многократно увеличивает требования к аппаратным ресурсам.
При расточительном использовании ресурсов стоимость инфраструктуры проекта может вырасти в десятки раз и продолжать расти в геометрической прогрессии, особенно при использовании не оптимальных алгоритмов. Однако, существуют подходы, которые позволят сильно ускорить обработку запроса приложением и увеличить количество запросов обрабатываемых одной единицей железа — это и называется искусством highload-разбработки.
Что такое highload сервис?
Например, рассмотрим сервис для авторизации пользователей и проверки прав доступа.
В монолитном приложении задачу проверки существования пользователя и его прав доступа обычно выделяют в отдельный модуль или компонент системы, который выполняет прямые запросы к базе данных или к кэширующему серверу. Однако, создание под задачи авторизации отдельного микро-сервиса сразу увеличивает нагрузку за счёт появления дополнительного оверхеда на передачу данных по сети и конвертирования данных из одного формата в другой.
Но зачем тогда выносить всё это в отдельный сервис, если это снижает производительность системы? Однозначно стоит, такой подход сильно упрощает задачи масштабирования системы. Разработчикам нужно будет масштабировать только конкретные сервисы испытывающие большую нагрузку, а не всё приложение целиком.
Когда проект считается высоконагруженным?
Вопрос который волнует многих разработчиков и администраторов —когда заканчивается «обычный» проект и начинается highload? Как только сайт или сервис перестаёт справляться с возрастающей нагрузкой — то перед разработчиками проекта встают задачи по выдерживанию высокой нагрузки.
Это может быть как небольшой сайт на самом бюджетном виртуальном сервере с 256 Мб оперативной памяти и 10 запросами в минуту, так и жирный сервис крутящийся на полноценном сервере с 256 Гб оперативки и обрабатывающий сотни тысяч запросов в минуту. И в том и другом случае нужно начинать предпринимать действия по ускорению своего программного продукта. Медленные сайты и сервисы никому уже не нужны!
Будут отличаться лишь методы оптимизации и масштабирования. Если в случае самого слабого тарифа хостинга проблема решится переходом на следующий тарифный план, то в случае топового выделенного сервера придётся покупать ещё одну дорогущую железку, либо заниматься низкоуровневым тюнингом и оптимизациями либо вообще переписыванием проекта на более быстром языке программирования.
Ещё один критерий, по которому можно отличить highload-проекты — это стоимость минуты простоя системы. Например, цена минуты простоя крупного федерального интернет-магазина может составлять сотни тысяч рублей, т.к. покупатели вряд ли будут ждать, пока магазин снова заработает, гораздо проще сделать заказ в другом магазине. А если при этом покупатель перешёл с платной рекламы, а сайт недоступен — то потраченные впустую рекламные бюджеты становятся прямым убытком.
Итак, какой же сайт считается высоконагруженным? Например тот, в котором внедрение нового не оптимизированного функционала потребует удвоить количество серверов для работы сайта, тем самым увеличив издержки. Либо обратная ситуация, когда оптимизация какого-либо компонента системы позволит в разы сократить нагрузку на железо, что позволит снизить количество серверов, тем самым сэкономить бюджет.
С другой стороны какой-нибудь сервис прогноза погоды имеет гораздо меньшую стоимость простоя. Вряд ли из-за недоступности погодного виджета или показа не самых актуальных данных из кэша какая-либо компания понесёт какие-то значительные убытки. Даже если такой сервис имеет десятки и сотни тысяч обращений в секунду. Будет ли такой сервис считаться высоконагруженным а его разработчик получать highload-зарплату?
Стоит ли заранее готовиться к high load?
Под определение хайлоад могут подпадать совершенно разные проекты с нагрузкой различающейся на порядки. Даже схожие сервисы в рамках различных компаний в одном случае будут высоконагруженным, а в другом — нет. Угадать заранее попадёт тот или иной проект в зал славы highload невозможно, как бы того не хотели заказчики, инвесторы и разработчики.
Многие работодатели, а точнее технические директора, архитекторы и тимлиды хотят набрать в свои команды самых лучших специалистов за минимальные деньги. И зачастую одним из важных требований в своих вакансиях указывают опыт работы с высокими нагрузками от 10 000 запросов в минуту. Но будет ли такому специалисту интересно работать над таким проектом, особенно если его судьба ещё не ясна, а высокие нагрузки ещё далеко впереди?
Плох тот руководитель, который не верит в успех своего проекта и не грезит высокой посещаемостью с не менее высокой прибылью. Однако, заниматься всевозможными оптимизациями и написанием идеального и в то же время максимально быстрого кода может быть пустой тратой времени. Ведь не известно как отреагируют потребители на ваш проект. История знает много случаев, когда самые навороченные и оптимизированные проекты не вызывали никакого интереса у сообщества и закрывались с миллионными убытками.
Сколько программистов работает над высоконагруженным проектом?
Как это ни странно, но существует множество высоконагруженных сервисов над которыми работает один единственный highload- разработчик. Например, какое-либо API может быть весьма простым по функционалу и не требовать большого количества времени на разработку и поддержку. Также какой-нибудь погодный виджет или счётчик посещаемости установленный на десятки тысяч сайтов весьма прост в реализации и мог быть разработан за пару дней. Что не мешает ему получать сотни тысяч запросов в секунду на несколько десятков серверов.
Highload-проект это не обязательно большая и сложная система с сотней разработчиков, а скорее даже наоборот.
Примеры хайлоад-проектов
Примеры сервисов и приложений которые могут испытывать высокие нагрузки:
Сколько получают highload разработчики?
Гораздо большие зарплаты в высоконагруженных проектах у системных администраторов и DevOps, технических директоров и архитекторов, а также у всевозможных менеджеров. Средний highload-разработчик имеет зарплату на 30-40% ниже, чем у средних fullstack, frontend и blockchain разработчиков. На 2018 год диапазон на который может рассчитывать разработчик высоконагруженных систем составляет от 120 до 180 тысяч белых рублей в месяц после вычета всех налогов. В сером сегменте дела чуть получше и особо удачливые разработчики могут получать до 260 000 рублей ежемесячно.
Как правило, чем крупнее компания, тем хуже у них условия работы. А за недополученные 30 000 рублей ежемесячно, а это 360 000 рублей в год компания вам предложит бесплатные фрукты или что-то подобное, что никак того не стоит.
Что нужно знать хайлоад-разработчику?
Как правило, разработчики высоко нагруженных систем занимаются разработкой серверной части, т.е. backend и сильно реже занимаются fullstack-разработкой. При это далеко не каждый серверный backend-разработчик занимается проектами с высокой нагрузкой. В разных компаниях требования к highload-разработчикам могут различаться кардинально. Однако, есть некоторые вещи, которые пригодятся почти в каждом высоконагруженном проекте.
В каких компаниях есть highload вакансии?
Среди московских компаний это конечно же: Badoo, Mamba, Avito, 8bit group, Yandex и Mail.Ru Group. А жители Санкт-Петербурга или желающие туда переехать могут обратить внимание на: Vkontakte, IQ Option и Embria. Конечно же существует огромное количество более мелких и менее известных компаний, но вакансии у них открыты не всегда.
Стек технологий в highload разработке
В высоконагруженных проектах применяется широкий стек технологий. В принципе он ничем не ограничен, но чаще всего это сервера на базе Linux, а в качестве фронт-веб-сервера используется nginx. Далее идут приложения на языках PHP, Python или Go. Системы хранения данных в памяти типа Redis, Riak, Tarantool или Memcache. Ну и СУБД по типу MySQL (MariaDB) или Postgres. Отдельно стоить сказать о приложениях на Java, в которых веб-сервер и другие компоненты могут быть частью самого приложения.
Бывают ли высоконагруженные проекты на PHP и MySQL?
Бывают и их тысячи по всему миру! Из самых известных это социальные сети Facebook и VK. Также среди них Badoo, Mamba, Avito, ICQ. Однако, это не означает, что в проектах этих компаний используется только PHP. Правильнее будет сказать, что на PHP приходится не самая сильная нагрузка, а благодаря продуманной архитектуре и балансировки нагрузки пользователю комфортно работать с системой.
Ultralow latency highload — как новый тренд
Бывают ли системы, где борьба идёт за каждую микросекунду? Бывают, подробнее можно посмотреть видео про ультрахайлоад и сверхоперативную память.
Что такое highload и как его изучать
Давайте разберемся, с чего можно начать знакомство с высоконагруженными системами или highload applications человеку, который с этим никогда не сталкивался.
Для начала условимся, что по большому счету, разработка высоконагруженной системы не так сильно отличается от просто грамотной разработки веб-приложения. Ключевым элементом в такой разработке является правильное проектирование архитектуры приложения.
Из чего складывается грамотная архитектура
Все крупные сайты строятся по одному принципу – разделение структуры проекта на части. Еще одно важное решение при разработке архитектуры – использовать проверенные решения.
Для решения двух этих главных проблем подходит любой современный фреймворк. Сегодня для каждого популярного языка программирования, будь то PHP, Python, Ruby или Java существует проверенный сообществом и множеством проектов фреймворк.
А выбор фреймворка должен основываться, в первую очередь, на языке программирования, с которым вы хорошо знакомы. Если же вы никогда не работали с фреймворками – первым пунктом в изучении проектирования highload-приложений должно стоять изучение конкретного фреймворка.
Кроме правильного выбора программной основы, есть еще множество вещей, которые нужно изучить. Принципы масштабирования, выбор инструментов, базы данных и грамотная работа с ней, шардинг и денормализация – все эти понятия не должны вызывать у вас сложностей. Чтобы глубже разобраться с построением высоконагруженной архитектуры, предлагаем изучить следующую подборку курсов и ресурсов по highload.
Курс по проектированию высоконагруженных систем от Технопарка Mail.Ru
Цель курса — получение студентами навыков проектирования высокоэффективных программных систем. В восьми лекциях преподаватели Технопарка рассказывают все о высоконагруженных проектах. Начиная с того, что считается highload-системой и заканчивая примерами типовых архитектурных решений.
Канал Ontico Team
YouTube канал посвященный веб-разработке. В видео канала рассматриваются типовые проблемы и решения для высоконагруженных проектов, масштабирование систем, базы данных, а также не напрямую связанные с highload вопросы, такие как средства разработки и отладка кода.
Доклад Олега Бунина об алгоритме проектирования highload-систем
Олег Бунин – основатель Ontico и человек, который принимал участие в создании многих крупных проектов рунета. В этой лекции Олег рассказывает об инструментах и конкретных шагах, которые нужно пройти при построении высоконагруженной архитектуры проекта.
Плейлист конференции Highload++ Junior 2015
Серия видео с лекций конференции Highload++ Junior 2015, посвященной обучению разработчиков высоконагруженных систем. В качестве лекторов на конференции выступают работники крупных российских компаний, таких как 2ГИС, Badoo и техотдела Сбербанка. В лекциях речь пойдет о применении инструментов масштабирования, кэширующих системах и базах данных.
Ruhighload
Русскоязычный ресурс, посвященный высоконагруженным системам. На нем можно найти множество справочных материалов по highload, примеров, обзоров инструментов и интересных статей.
Безопасность в масштабе HighLoad — магия или realtime?
Миллионы запросов в секунду. Сотни серверов с десятками ядер и терабайтами оперативной памяти. Много пользователей и данных. И их становится всё больше. Да, это всё HighLoad. Но HighLoad — не только это.
В основе хороших высоконагруженных систем лежит тщательно спроектированная архитектура. Благодаря этому, системы постоянно масштабируются, а их ресурсов хватает для работы с текущими нагрузками. И тогда HighLoad-конференции не превращаются в дискуссии «Как сэкономить на ресурсах при штатно выросшей нагрузке» или «Куда девать все имеющиеся у нас мощности».
Но что насчет безопасности и защиты данных при высоких нагрузках? Что думают разработчики и эксперты о внешних угрозах, которые тоже могут вывести систему из строя? О сохранении данных, их правильной передаче и использовании? Артём Гавриченков в Программном комитете отвечает за эту область на конференции HighLoad++. Сегодня он расскажет, чем наша долгожданная офлайн-встреча Highload++ Весна 2021 будет интересна и полезна любому разработчику. Доклады на конференции будут и о безопасности, и о шифровании, и о биометрии, и, конечно, о многих других смежных с безопасностью темах.
— Артем, чем ты сейчас занимаешься и какое отношение имеешь именно к высоким нагрузкам?
— На протяжении 10 лет я строил продукт Qrator по защите DDoS-атак. Тут, наверное, сразу понятно, где высокие нагрузки. Последние 5 лет был техническим директором этого продукта, даже больше пяти. В данный момент я директор по продукту в Servers.com — это компания, которая занимается предоставлением инфраструктурных решений (bare metal cloud, облачное хранение данных, фаерволы, Managed Kubernetes), то есть опять же решения для больших нагруженных проектов.
— Как давно ты в Программном комитете и как ты в него пришел?
— Я выступал несколько раз на Highload, начиная с 2011 года. А в 2018-м мы пообщались с Олегом Буниным, и он пригласил меня в ПК как эксперта по защите информации, по высоким нагрузкам в плане DDoS-атак и по масштабируемым системам по сети и инфраструктуре.
— Чем тебе нравится быть в ПК? Что это для тебя?
— Это возможность пообщаться с очень интересными людьми, высокими профессионалами своего дела, как с членами ПК, так и докладчиками. Вы можете увидеть прямо весь bleeding edge технологий — самые модные, и при этом уже немного проверенные в деле. То есть можно узнать, какие направления есть в индустрии, куда это все идет, что появляется каждый год, а на что не стоит тратить время. Программа HighLoad++ сама по себе дает такое понимание людям, поэтому и стоит на него ходить.
А в программном комитете я могу дополнительно пообщаться со всеми докладчиками. Конференция идет всего 2 дня, хоть и в несколько потоков — при всем желании вы не успеете со всеми пообщаться. А у членов ПК есть возможность общаться с интересными докладчиками на протяжении полугода, пока мы отбираем доклады, а потом помогаем спикерам готовиться к выступлению. То есть здесь я снова получаю полный обзор всех актуальных технологий, которые существуют и появляются. Это, в том числе, и инструмент поддержания собственной компетентности и уровня awareness по технологиям.
— Какие темы нас ждут в разделе безопасности в этом году на конференции?
— В первую очередь, мы говорим про крупные системы, которые выдерживают серьезные нагрузки, то есть хорошо спроектированные системы. В рамках проектирования, создания архитектуры системы, написания кода необходимо решать и вопросы безопасности.
Безопасность — это, как правило, дополнительные проверки и дополнительная нагрузка, в частности, криптография, проверка вводимых данных, проверка аутентификации хостов и т.д. Поэтому надо учитывать эти вопросы еще на этапе проектирования системы. Добавить безопасность потом в систему, которая уже работает, может быть очень сложно.
Также будет тема защиты систем управления базами данных (СУБД), отвечающая на не совсем тривиальные вопросы. Как усиление безопасности БД влияет на производительность? Что, если мы хотим применять защищенные соединения? Что, если у нас данные нужно хранить в зашифрованном виде? Как организовать аудит?
Еще будет близкая к этому тема шифрования соединений. Сейчас практически все соединения в интернете — от браузера или мобильного приложения до сервера — надежно шифруются, но криптография всегда повышает нагрузку. У нас будет Александр Крижановский (Tempesta Technologies) с рассказом о том, как написать быстрый TLS-хендшейк в ядре Linux. Это такой хендшейк, который эффективней на десятки процентов, чем стандартное решение — он дает меньшее время задержки, то есть готов работать под большой нагрузкой.
Будет доклад от РТЛабс про единую биометрическую систему. Это мультивендорная система, которая обеспечивает возможность работы с любыми модальностями биометрии (лицо, голос и т.д.). Биометрия в последнее время в России — это очень активный хайп, развертывание биометрической аутентификации в приоритете у правительства. И конечно, у людей есть опасения, как это может работать и что может пойти не так — вопрос на самом деле серьезный. Поэтому мы включили в программу этот доклад, чтобы люди, кому важно и/или интересно устройство единой биометрической системы, могли узнать, как она работает.
Система РТЛабс рассчитана на 150 млн человек, и этого должно хватить для 136 миллионов россиян. Хотя в реальности, конечно, будет меньше. Но, с другой стороны, может быть, ее удастся расширить и на таможенный союз, например, на Беларусь.
— Будут ли какие-нибудь новинки в решении известных задач безопасности?
— На эту тему будет доклад от Касперского про быстрое детектирование спам-писем. Проблеме спама столько же лет, сколько электронной почте. Она никуда не уходит, с годами становится сложнее, потому что, например, Gmail или Яндекс собирают почту в большом объеме — и более-менее умеют детектировать спам с минимальным количеством ошибок первого и второго рода. Но в финале это приводит к ситуации как с Ковидом. Иммунитет летучих мышей совершенно адский — он выжигает вирусы каленым железом! Это очень стойкое животное. Но по каким-то эволюционным причинам эта иммунная система выборочно оставляет некие вирусы, которые летучей мыши уже вреда не причиняют, но там живут.
Так вот мы в спаме получаем ровно такую же ситуацию. Google, Яндекс и прочие гиганты «выпалывают» спам, который легко детектировать, но самый адский и хардкорный остается. Например, в той же корпоративной почте у нас нет доступа ко всему тому объему данных, и поэтому у нас не получается спам фильтровать так же просто. Никакие простые методы давно не работают, поскольку спам, который умеет обходить Google, он и нас обходит очень легко.
Хочу заметить, что проблема спама никогда никуда не уйдет. Есть даже категория шуток в IT-сообществе про Final Ultimate Solution to the Spam Problem. Примерно раз в год в каких-нибудь списках рассылки появляется человек, который утверждает, что он нашел уникальное полное решение проблемы спама — и чего на практике никогда не случается.
Поэтому на рынке есть продукты для решения этой задачи до определенного уровня качества — это лучше, чем есть сейчас. И одно из них от Касперского — докладчик расскажет, как оно устроено внутри, какие были сложности, как они подошли к этой задаче и какие результаты получились.
Слушателям конференции это может быть интересно еще и потому, что это система, которая действительно работает под нагрузкой. И под этой нагрузкой умудряется на каждом миллионе спам-писем отрабатывать развесистые алгоритмы, интересные подходы.
— Какие доклады, не связанные с безопасностью, тебе интересны самому?
— По смежной теме будет доклад Василия Сошникова про API Gateway. Эта технология — реально популярный хайп последних лет. Она очень часто встречается, в том числе, в over-engineering проектах. Поэтому в докладе будет обзор концепции и того, какие плюшки это нам дает и какие сложности возникают в эксплуатации. Что поможет найти ответ на вопрос: для нашего проекта API Gateway — это полезный момент или просто хайп, на который не нужно тратить время?
— Это действительно интересно. А ты сам на HighLoad++ собираешься посетить только то, что описал, или тебя интересуют еще какие-то доклады и мероприятия?
Уже принято 75 докладов, и есть, конечно, интересные и не только про безопасность. Например, доклад Сбербанка про борьбу с TCP Incast. Это как раз инфраструктурная часть — как устроены центры обработки данных и как устроена сеть на большом проекте. Там возникают разные проблемы.
Очень интересная тема про маршрутизацию Яндекса — каким образом Яндекс маршрутизирует машины, и как он это делает таким образом, чтобы экономить своим клиентам деньги, в том числе коммерческим компаниям (доставка документов, товаров и пр.). Правильным образом выстроенная простая оптимизация алгоритма начинает экономить клиентам по 100 000 рублей в месяц.
— Ты часто бываешь на конференциях?
— С 2017 года я не пропускал ни одного HighLoad++, в том числе ни одного питерского, и ни одного РИТа, правда, в Сибирь я не ездил ни разу.
— Ты сам предпочитаешь онлайн или офлайн?
— Офлайн, конечно, потому что нам за год никому так и не удалось достойно заменить офлайн конференции. Онлайн — это хорошо как дополнение, но очень многие офлайн-плюшки просто невозможны в онлайн-режиме: нетворкинг, например, или возможность реально познакомиться с интересными людьми вплотную, то есть выйти на какой-то уровень доверия.
— Когда ты сам выступал в качестве спикера, что самое важное в построении докладов? Какие-то фишки есть, чтобы выступление было запоминающимся и интересным?
— Структура — это должно быть выстроено обязательно, над ней нужно очень плотно работать. Обязательно делать прогоны с таймингом и пониманием того, сколько времени будет потрачено и какие вещи нужно сказать обязательно. И крайне желательно иметь примеры из жизни, потому что примером можно показать намного больше. Один пример стоит десятка слайдов.
— Что такое Highload лично для тебя? Как бы ты описал его человеку, который не член ПК, а просто приходит туда по собственному желанию?
— Это уникальное сообщество профессионалов, специалистов в своем деле, работающих над уникальными по мировым меркам онлайн-проектами. Плюс возможность обменяться опытом с этими профессионалами. Большинство из них открыты для общения.
Конференция HighLoad++ 2021 пройдет уже 17 и 18 мая в Москве, в Крокус-экспо. Сейчас открыт дополнительный прием докладов по новым темам. Если вы хотите поделиться тем важным и интересным, что вы нашли, разработали и открыли во время онлайна в пандемию — мы вас ждем!
Билеты можно купить здесь. И да, цена с 30 апреля вырастет, для решения осталось 2 недели.
Подписывайтесь на наши новости о конференции, чтобы быть в курсе всех изменений, новинок и интересностей!
История платформы Highload.Fun для соревнований в оптимизации кода
Версия 1
В качестве первой задачи участникам было предложено оптимизировать парсинг чисел. Генератор выглядел примерно так:
Только более эффективно. Участники справились с оптимизацией довольно быстро, но, к сожалению, не так как задумывалось, были скомпрометированы генератор псевдослучайных чисел и алгоритм повтора данных. На самом деле в таком подходе была ещё одна уязвимость, ответ на решение находился в том же адресном пространстве, что и код его считающий. Можно было просто найти адрес переменной и вывести результат не считая.
Версия 2
Стало очевидно, что генератор и решение должны быть разными приложениями. Схему взаимодействия было решено сделать такой:
Checker создавал pipe и запускал оба приложения, соединяя STDOUT генератора и STDIN решения. Затем получал ответы, сравнивал их и в случае совпадения вынимал из статистики cgroup ‘ы информацию об использованных ресурсах и считал баллы.
Казалось, что теперь всё должно работать идеально. Часть участников начали использовать *_unlocked() версии STDIO функций (man), что позволило им вырваться вперёд. Всё было хорошо, но тут стали появляться жалобы, что запуск одного и того же решения выдавал разные значения по потреблённым ресурсам, причём расхождения были значительными. Чтобы усреднить значения было принято решение запускать параллельно 3 обсчёта брать медианный в качестве решения. Не могу сказать, что это сильно прибавило стабильности в цифрах, а потом, через несколько дней все запуски стали выдавать результаты хуже чем в первые дни.
Борьба за стабильность
Система проверки жила на VDS и другие проекты, запущенные на этом же железе могли влиять на обсчёт задач. Поэтому нужно было переезжать на настоящее железо. Недорогой сервер на базе Intel(R) Xeon(R) CPU E3-1271 v3 @ 3.60GHz за 40 евро в месяц был найден на популярном немецком хостинге. После наливки OS и запуска Checker’а ожидалось, что теперь всё будет ровно, но, как говорится, забыли про «овраги».
Результаты стали стабильнее, но всё равно оставались странными:
Всё было хорошо, появлялись новые задачи, одна из которых была про форматирование чисел. Суть в том, что на вход подаётся 250 000 000 uint32 чисел, а на выходе нужно посчитать CRC от их строкового представления. Генератор выглядел так:
На самом деле разработка генераторов для задач оказалась непростым делом. Нужно сделать так, чтобы данные действительно были случайными, но и при этом время выполнения должно быть примерно одинаковым. Участники регулярно находят дыры в данных, например в задаче про поиск медианы пришлось миксовать несколько нормальных распределений, т.к. равномерное распределение давало примерно одинаковое значение медианы и некоторые участники этим пользовались.
Медленный транспорт и снова стабильность результатов
Так как обсчёт запускался параллельно, а данные лежали в памяти, то узким местом стал контроллер памяти. Учитывая что для подсчёта очков в большинстве задач используется время CPU, а не время выполнения (wall time), то если отправить решения в сон на разные интервалы времени, то контроллер памяти будет использоваться последовательно, что даёт хороший буст в очках. Чтобы это исправить, пришлось отказаться от параллельного запуска решений. Это увеличило время тестирования, но улучшило стабильность очков.
Текущая версия
Сейчас на платформе есть встроенный редактор, который позволяет работать с несколькими файлами. Так же есть возможность выбрать любую версию компилятора Go или Rust, для C++ пока выбор только из clang 10.0 и gcc 9.3. Ещё можно передавать любые флаги компиляции. А самое главное, можно создавать свои задачи, для этого есть специальная форма:
Для каждой задачи задаётся максимальное время на выполнение, ограничения по памяти, место расположения файлов с данными (работа с диском может быть частью задачи):
Компаратор сравнивает ожидаемый результат с полученным. В зависимости от данных можно выбрать любой из:
При желании можно сделать свой компаратор, для этого нужно прислать Pull Request в репозиторий.
Дальше нужно написать генератор и хотя бы 1 бойлерплейт на любом из доступных языков.
Если есть желание просто прийти и порешать одну из 12 существующих на текущий момент задач, добро пожаловать. Для пополнения знаний у нас есть Wiki с подборкой ссылок.