Всем привет!
Одним из спикеров Highload++ Foundation будет Алексей Салмин - руководитель службы разработки realtime-технологий поиска в Яндекс.Поиск.
📋 https://clck.ru/awTbz
В своем докладе он расскажет краткую историю развития ядра веб-поиска Яндекса за последние несколько лет. Основной задачей команды, которая разрабатывает движок, можно назвать экономию ресурсов. Экономия не является самостоятельной целью, но при этом имеет огромное значение: она позволяет на том же железе наращивать поисковую базу, внедрять новые фичи и модели в ранжирование, принимать растущий пользовательский трафик.
Из доклада вы узнаете, как снизить потребление CPU с помощью:
* сжатия (sic!);
* микросервисов (sic!);
* асинхронного IO (???);
* заменой горизонтального шардирования на вертикальное и наоборот.
И другие интересные технологические решения: erasure-recovery в реальном времени, key-value storage на десятки миллионов RPS, e2e-сжатие со словарем, батчевание применения нейросетей и деревьев.
Доклад строится вокруг практического опыта, в нем мало теории. С другой стороны, многие из описанных приемов принесут пользу только в больших рантаймах (грубо говоря, от 10к ядер CPU), и не у всех слушателей будет возможность сразу применить эти идеи на практике. Но в любом случае будет интересно.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/awTzE
Одним из спикеров Highload++ Foundation будет Алексей Салмин - руководитель службы разработки realtime-технологий поиска в Яндекс.Поиск.
📋 https://clck.ru/awTbz
В своем докладе он расскажет краткую историю развития ядра веб-поиска Яндекса за последние несколько лет. Основной задачей команды, которая разрабатывает движок, можно назвать экономию ресурсов. Экономия не является самостоятельной целью, но при этом имеет огромное значение: она позволяет на том же железе наращивать поисковую базу, внедрять новые фичи и модели в ранжирование, принимать растущий пользовательский трафик.
Из доклада вы узнаете, как снизить потребление CPU с помощью:
* сжатия (sic!);
* микросервисов (sic!);
* асинхронного IO (???);
* заменой горизонтального шардирования на вертикальное и наоборот.
И другие интересные технологические решения: erasure-recovery в реальном времени, key-value storage на десятки миллионов RPS, e2e-сжатие со словарем, батчевание применения нейросетей и деревьев.
Доклад строится вокруг практического опыта, в нем мало теории. С другой стороны, многие из описанных приемов принесут пользу только в больших рантаймах (грубо говоря, от 10к ядер CPU), и не у всех слушателей будет возможность сразу применить эти идеи на практике. Но в любом случае будет интересно.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/awTzE
Как мы создавали Data Management Platform: архитектура, проблемы, выводы.
Для таргетинга в OZON используют сегменты, в которые группируют пользователей по различным правилам. На основе сегментов пользователи получают нотификации и письма. Видят рекомендации, баннеры и страницы с товарами и цены на товары, участвующие в маркетинговых акциях. В принципе на сегменты можно завязать любую механику, даже А/В тесты можно проводить.
Но проблема в том, что изначально сегменты создавались вручную, и в какой-то момент их стало слишком много. Чтобы автоматизировать этот процесс, разработчики создали DMP — Data Management Platform. Это относительно молодой проект, ему чуть больше двух лет, но он полностью уже себя оправдал.
В сегодняшней статье руководитель команды DMP & CDP Евгений Чмель рассказал, что получилось в результате.
Читать 📍https://habr.com/ru/company/oleg-bunin/blog/650473/
Для таргетинга в OZON используют сегменты, в которые группируют пользователей по различным правилам. На основе сегментов пользователи получают нотификации и письма. Видят рекомендации, баннеры и страницы с товарами и цены на товары, участвующие в маркетинговых акциях. В принципе на сегменты можно завязать любую механику, даже А/В тесты можно проводить.
Но проблема в том, что изначально сегменты создавались вручную, и в какой-то момент их стало слишком много. Чтобы автоматизировать этот процесс, разработчики создали DMP — Data Management Platform. Это относительно молодой проект, ему чуть больше двух лет, но он полностью уже себя оправдал.
В сегодняшней статье руководитель команды DMP & CDP Евгений Чмель рассказал, что получилось в результате.
Читать 📍https://habr.com/ru/company/oleg-bunin/blog/650473/
Хабр
Как мы создавали Data Management Platform: архитектура, проблемы, выводы
Для таргетинга мы в Ozon используем сегменты, в которые группируем пользователей по интересам, а они могут быть определены через систему трекинга событий. Последние в свою очередь формируются в...
Media is too big
VIEW IN TELEGRAM
Всем привет!
AWS задаёт стандарты на рынке облачных технологий. Но и в России облака развиваются, а курс доллара и законодательство делает их ещё более востребованными. Однако многие архитектурные решения и DevOps-практики слишком сильно различаются на российском и американском рынках cloud-провайдеров.
Возможно ли в России реализовать архитектурные решения, устоявшиеся в западной DevOps-культуре?
👉 Узнаем на выступлении Сергея Спорышева из ITSumma.
https://clck.ru/b2zfs
Основываясь на своем богатом опыте по разработке и DevOps-сопровождению для российских клиентов и практике, полученной в работе в качестве DevOps-саппорта для американских клиентов, Сергей сравнит возможности разных провайдеров.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты -
https://clck.ru/b2zgU
AWS задаёт стандарты на рынке облачных технологий. Но и в России облака развиваются, а курс доллара и законодательство делает их ещё более востребованными. Однако многие архитектурные решения и DevOps-практики слишком сильно различаются на российском и американском рынках cloud-провайдеров.
Возможно ли в России реализовать архитектурные решения, устоявшиеся в западной DevOps-культуре?
👉 Узнаем на выступлении Сергея Спорышева из ITSumma.
https://clck.ru/b2zfs
Основываясь на своем богатом опыте по разработке и DevOps-сопровождению для российских клиентов и практике, полученной в работе в качестве DevOps-саппорта для американских клиентов, Сергей сравнит возможности разных провайдеров.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты -
https://clck.ru/b2zgU
👍2
Всем привет!
О том, как эволюционировала архитектура Яндекс.Афиши – узнаем у руководителей разработки Александра Полякова и Михаила Сурина.
📋 https://clck.ru/bF7Cm
Они расскажут, как переезжали с REST на GraphQL. Пояснят, почему они выбрали технологию GraphQL, какие проблемы и задачи решали с ее помощью.
Прослушав их доклад, вы поймёте, подходит ли GraphQL вашему проекту и как сделать переход безболезненным. Узнаете про подходы и принципы, которых следует придерживаться, чтобы не выстрелить себе в ногу. Затронут вопросы типизации данных, безопасности, скорости работы API, расскажут про концепт даталоадеров.
✅ Встречаемся 17 и 18 марта в Москве, в Крокус Экспо!
⚡️Купить билет уже сейчас можно на сайте - https://clck.ru/bF7FG
О том, как эволюционировала архитектура Яндекс.Афиши – узнаем у руководителей разработки Александра Полякова и Михаила Сурина.
📋 https://clck.ru/bF7Cm
Они расскажут, как переезжали с REST на GraphQL. Пояснят, почему они выбрали технологию GraphQL, какие проблемы и задачи решали с ее помощью.
Прослушав их доклад, вы поймёте, подходит ли GraphQL вашему проекту и как сделать переход безболезненным. Узнаете про подходы и принципы, которых следует придерживаться, чтобы не выстрелить себе в ногу. Затронут вопросы типизации данных, безопасности, скорости работы API, расскажут про концепт даталоадеров.
✅ Встречаемся 17 и 18 марта в Москве, в Крокус Экспо!
⚡️Купить билет уже сейчас можно на сайте - https://clck.ru/bF7FG
Привет, друзья!
О том, как работает С++-движок рекламного сервера и с какими проблемами прошлось столкнуться разработчикам – поговорим с Дмитрием Корчагиным. Он является руководителем группы разработки сервиса, отвечающего за подбор и ранжирование рекламных объявлений — рекламного сервера myTarget.
📋 https://clck.ru/bGdD7
На своем выступлении Дмитрий расскажет об архитектуре сервиса, отвечающего за подбор рекламных объявлений. Поделится о том, как они боролись с фродом рекламодателей. Научились без потерь переживать несколько часов без синхронизации данных. А также как они выдерживают лимиты откруток кампаний в распределенной системе из нескольких сотен серверов.
План доклада:
* общая схема работы myTarget;
* очереди задач;
* синхронизация индекса;
* работа с метриками и статистикой;
* как решалась проблема с бесплатным для рекламодателя показом баннеров.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bGdZ3
О том, как работает С++-движок рекламного сервера и с какими проблемами прошлось столкнуться разработчикам – поговорим с Дмитрием Корчагиным. Он является руководителем группы разработки сервиса, отвечающего за подбор и ранжирование рекламных объявлений — рекламного сервера myTarget.
📋 https://clck.ru/bGdD7
На своем выступлении Дмитрий расскажет об архитектуре сервиса, отвечающего за подбор рекламных объявлений. Поделится о том, как они боролись с фродом рекламодателей. Научились без потерь переживать несколько часов без синхронизации данных. А также как они выдерживают лимиты откруток кампаний в распределенной системе из нескольких сотен серверов.
План доклада:
* общая схема работы myTarget;
* очереди задач;
* синхронизация индекса;
* работа с метриками и статистикой;
* как решалась проблема с бесплатным для рекламодателя показом баннеров.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bGdZ3
Привет, друзья!
Эволюцию акторной системы обсудим на выступлении Алексея Станкевичуса (Яндекс).
Он руководит группой разработки распределенного хранилища и распределенной платформы YDB.
📋 https://clck.ru/bHZAW
Существует несколько подходов к созданию эффективных многопоточных приложений на С++. В Yandex Database (YDB) выбрали модель акторов и с нуля создали свою акторную систему. С тех пор прошло более 7 лет, и сегодня акторная система исполняется на десятках тысяч серверов. Чтобы пройти путь к созданию сложных модульных распределенных систем с помощью модели акторов разработчикам пришлось решить множество проблем.
Из доклада узнаем о некоторых из них:
* как совместить интерактивную нагрузку и фоновые задачи в одном приложении;
* как обеспечить гарантии latency и высокую утилизацию;
* как изолировать подсистемы и обойтись без резервирования CPU.
И, конечно, расскажет, почему выбрали именно модель акторов.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве –
https://clck.ru/bHYn3
Эволюцию акторной системы обсудим на выступлении Алексея Станкевичуса (Яндекс).
Он руководит группой разработки распределенного хранилища и распределенной платформы YDB.
📋 https://clck.ru/bHZAW
Существует несколько подходов к созданию эффективных многопоточных приложений на С++. В Yandex Database (YDB) выбрали модель акторов и с нуля создали свою акторную систему. С тех пор прошло более 7 лет, и сегодня акторная система исполняется на десятках тысяч серверов. Чтобы пройти путь к созданию сложных модульных распределенных систем с помощью модели акторов разработчикам пришлось решить множество проблем.
Из доклада узнаем о некоторых из них:
* как совместить интерактивную нагрузку и фоновые задачи в одном приложении;
* как обеспечить гарантии latency и высокую утилизацию;
* как изолировать подсистемы и обойтись без резервирования CPU.
И, конечно, расскажет, почему выбрали именно модель акторов.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве –
https://clck.ru/bHYn3
Всем привет!
О том, как готовили поиск в Delivery Club – узнаем у Евгения Исупова и Ивана Максимова.
📋 https://clck.ru/bQ9ms
На конференции Highload++ Foundation они расскажут почему поиск — это не просто совпадения по полям данных. Как на запрос "Маргарита" появляется пицца, а на запрос "Пьяная бабушка" — бургер из известной сети? Каким образом на запрос "Макдональдс" вернуть не только сам ресторан, но и другие бургерные?
В докладе они поделятся об архитектуре поиска в Delivery Club, а также о повышении его релевантности с помощью ML-инструментов без потери в скорости ответа сервиса.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bQA7W
О том, как готовили поиск в Delivery Club – узнаем у Евгения Исупова и Ивана Максимова.
📋 https://clck.ru/bQ9ms
На конференции Highload++ Foundation они расскажут почему поиск — это не просто совпадения по полям данных. Как на запрос "Маргарита" появляется пицца, а на запрос "Пьяная бабушка" — бургер из известной сети? Каким образом на запрос "Макдональдс" вернуть не только сам ресторан, но и другие бургерные?
В докладе они поделятся об архитектуре поиска в Delivery Club, а также о повышении его релевантности с помощью ML-инструментов без потери в скорости ответа сервиса.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bQA7W
This media is not supported in your browser
VIEW IN TELEGRAM
Всем привет!
Поговорим с Владимиром Витковским о лучших практиках, на которых основан очень быстрый сборщик логов, используемый в Ozon.
📋 https://clck.ru/bR3ap
Владимир расскажет, как с помощью этого инструмента они сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.
Вы узнаете:
* как организована общая архитектура сборщика логов;
* как написать быстрый плагин для чтения логов из файлов;
* как оптимизировать внутреннюю обработку потока логов;
* как правильно распараллелить обработку;
* как гарантировать доставку.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bR42b
Поговорим с Владимиром Витковским о лучших практиках, на которых основан очень быстрый сборщик логов, используемый в Ozon.
📋 https://clck.ru/bR3ap
Владимир расскажет, как с помощью этого инструмента они сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.
Вы узнаете:
* как организована общая архитектура сборщика логов;
* как написать быстрый плагин для чтения логов из файлов;
* как оптимизировать внутреннюю обработку потока логов;
* как правильно распараллелить обработку;
* как гарантировать доставку.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bR42b
🔥3
Привет, друзья!
Тернистый путь цифровой трансформации классического телеком-оператора большой тройки в современную IT-компанию. Как обеспечить интеграцию множества сервисов, разрабатываемых множеством команд, между собой и не допустить хаоса во взаимодействии – расскажет Алексей Коновкин (Nexign).
📋 https://clck.ru/bVYkk
Аутентификация и авторизация "всех со всеми", если у вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.
"Купить или не купить — вот в чем вопрос". Вопрос выбора API Gateway, и почему они решили пойти своим путем.
🔹Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bVYmu
Тернистый путь цифровой трансформации классического телеком-оператора большой тройки в современную IT-компанию. Как обеспечить интеграцию множества сервисов, разрабатываемых множеством команд, между собой и не допустить хаоса во взаимодействии – расскажет Алексей Коновкин (Nexign).
📋 https://clck.ru/bVYkk
Аутентификация и авторизация "всех со всеми", если у вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.
"Купить или не купить — вот в чем вопрос". Вопрос выбора API Gateway, и почему они решили пойти своим путем.
🔹Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bVYmu
Всем привет!
На конференции HighLoad++ выступит Юрий Печатнов из Яндекса.
📋 https://clck.ru/bVm8P
Его доклад будет о том, как они научились более эффективно передавать данные между своими сервисами.
С сохранением exactly once и отказоустойчивости они уменьшили материализацию потока промежуточных данных на дисках на 90% и примерно на столько же снизили latency.
Подробнее на простом примере:
Пусть у них есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И они хотят в реальном времени считать агрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.
Для эффективной работы такой схемы обновления стейтов в хранилище нужна какая-то локальность по ключам, поэтому входные данные нужно сначала пошардировать примерно так же, как шардированы данные в хранилище.
Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардировано (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).
Что плохо в этой схеме? То, что весь поток событий необходимо писать через промежуточную очередь, а это большой поток на записи на диски и, соответственно, много железа! А ведь еще есть небольшая задержка.
То есть они решают проблему: как передать данные от resharder'а aggregator'у с наименьшей материализацией на дисках, с наименьшими задержками и при этом отказоустойчиво и с exactly once.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bVmRZ
На конференции HighLoad++ выступит Юрий Печатнов из Яндекса.
📋 https://clck.ru/bVm8P
Его доклад будет о том, как они научились более эффективно передавать данные между своими сервисами.
С сохранением exactly once и отказоустойчивости они уменьшили материализацию потока промежуточных данных на дисках на 90% и примерно на столько же снизили latency.
Подробнее на простом примере:
Пусть у них есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И они хотят в реальном времени считать агрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.
Для эффективной работы такой схемы обновления стейтов в хранилище нужна какая-то локальность по ключам, поэтому входные данные нужно сначала пошардировать примерно так же, как шардированы данные в хранилище.
Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардировано (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).
Что плохо в этой схеме? То, что весь поток событий необходимо писать через промежуточную очередь, а это большой поток на записи на диски и, соответственно, много железа! А ведь еще есть небольшая задержка.
То есть они решают проблему: как передать данные от resharder'а aggregator'у с наименьшей материализацией на дисках, с наименьшими задержками и при этом отказоустойчиво и с exactly once.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bVmRZ
Всем привет!
Как наладить CI-процесс в монорепозитории и сохранить спокойствие разработчиков – расскажет Алина Власова. Она работает в “Лаборатории Касперского” c 2015 года. В данный момент является руководителем группы, занимающейся разработкой инфраструктуры для непрерывной интеграции.
📋 https://clck.ru/bd3C5
Несколько лет тому назад в Лаборатории Касперского приняли решение переехать в монорепозиторий с собственной инфраструктурой. В докладе Алина расскажет о том, как это решение повлияло на жизнь разработчиков и на скорость доставки изменений в код.
Вы узнаете о том, как у них устроен CI-процесс, какие преимущества они получили и с какими проблемами столкнулись. Какие инструменты и мониторинги используют для того, чтобы повышать работоспособность данного процесса и создавать комфортные условия для разработчиков, вносящих изменения в код.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bd3CV
Как наладить CI-процесс в монорепозитории и сохранить спокойствие разработчиков – расскажет Алина Власова. Она работает в “Лаборатории Касперского” c 2015 года. В данный момент является руководителем группы, занимающейся разработкой инфраструктуры для непрерывной интеграции.
📋 https://clck.ru/bd3C5
Несколько лет тому назад в Лаборатории Касперского приняли решение переехать в монорепозиторий с собственной инфраструктурой. В докладе Алина расскажет о том, как это решение повлияло на жизнь разработчиков и на скорость доставки изменений в код.
Вы узнаете о том, как у них устроен CI-процесс, какие преимущества они получили и с какими проблемами столкнулись. Какие инструменты и мониторинги используют для того, чтобы повышать работоспособность данного процесса и создавать комфортные условия для разработчиков, вносящих изменения в код.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bd3CV
💥 Кто получит премию HighLoad++ Award 2022? Решать вам!
Ранее мы объявляли о наборе номинантов на премию HighLoad++, в котором мог принять участие каждый, кто оказал положительное влияние в развитие экосистемы интернет-разработки.
Экспертный совет произвел первичный отбор поданных заявок. И теперь все номинанты, прошедшие фильтр – попали в закрытое голосование.
В голосовании могут принять участие абсолютно все, необходимо зайти на сайт голосования, авторизироваться через соцсеть и отдать свой голос в одной номинации или нескольких.
✅ Голосование будет проходить до 20 февраля.
Переходите по ссылке 👉 https://clck.ru/auCAr и оставляйте свой голос за лучшего!
Ранее мы объявляли о наборе номинантов на премию HighLoad++, в котором мог принять участие каждый, кто оказал положительное влияние в развитие экосистемы интернет-разработки.
Экспертный совет произвел первичный отбор поданных заявок. И теперь все номинанты, прошедшие фильтр – попали в закрытое голосование.
В голосовании могут принять участие абсолютно все, необходимо зайти на сайт голосования, авторизироваться через соцсеть и отдать свой голос в одной номинации или нескольких.
✅ Голосование будет проходить до 20 февраля.
Переходите по ссылке 👉 https://clck.ru/auCAr и оставляйте свой голос за лучшего!
Привет, друзья!
В своем докладе Андрей Аксенов (Авито, Sphinx) поделится, как они в порядке эксперимента выжимали 1 миллион запросов в секунду из 1 физического сервера и СУБД, никогда при этом НЕ рассчитанной на именно такой workload (спойлер: СУБД всё ещё Сфинкс).
📋 https://clck.ru/bfrRy
На выступлении узнаем:
- Почему выжимали именно ~1 миллион (а не ~0.1 или ~10м).
- В каких местах обнаружились тормоза (спойлер: в разных и поначалу несколько удивительных).
- Как получилось подлечить 3+ места с разумной трудоемкостью и немедленно закатить эти успехи в бой (тизеры: не обошлось без пары строчек ассемблера, причем, что удивительно, сервер Intel, а ассемблер понадобился ARM; не обошлось без легких лок-фри-фокусов; не обошлось без переписывания простеньких системных вызовов вручную и прочей легкой наркомании).
- Чего в итоге получилось.
- Где ещё есть известные диоды, которые уже так просто не залечить.
- Ну и совсем вкратце — как теоретически атаковать следующие вершины (10+ миллионов RPS).
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bfrn5
В своем докладе Андрей Аксенов (Авито, Sphinx) поделится, как они в порядке эксперимента выжимали 1 миллион запросов в секунду из 1 физического сервера и СУБД, никогда при этом НЕ рассчитанной на именно такой workload (спойлер: СУБД всё ещё Сфинкс).
📋 https://clck.ru/bfrRy
На выступлении узнаем:
- Почему выжимали именно ~1 миллион (а не ~0.1 или ~10м).
- В каких местах обнаружились тормоза (спойлер: в разных и поначалу несколько удивительных).
- Как получилось подлечить 3+ места с разумной трудоемкостью и немедленно закатить эти успехи в бой (тизеры: не обошлось без пары строчек ассемблера, причем, что удивительно, сервер Intel, а ассемблер понадобился ARM; не обошлось без легких лок-фри-фокусов; не обошлось без переписывания простеньких системных вызовов вручную и прочей легкой наркомании).
- Чего в итоге получилось.
- Где ещё есть известные диоды, которые уже так просто не залечить.
- Ну и совсем вкратце — как теоретически атаковать следующие вершины (10+ миллионов RPS).
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bfrn5
👍1
Привет, друзья!
В докладе Тимура Давыдова (Московская Биржа) рассмотрим архитектуру современной торгово-клиринговой системы (ТКС) и более подробно познакомимся с in-memory-базой данных, оптимизированной для работы с низкими и предсказуемыми задержками, предназначенными для хранения информации во время работы ТКС.
📋 https://clck.ru/bggxi
В связи с изменением поведения рынков со временем и требованием хранения большего количества информации, были сделаны оптимизации как в самом представлении данных, так и в организации базы данных. Но одна проблема все еще оставалась нерешенной — это выделение оптимального объема памяти для каждой таблицы БД с расчетом на худший случай.
Поэтому в докладе также будут рассмотрены способы увеличения объема непрерывной области данных в памяти и предложена оптимальная реализация технологии динамического увеличения непрерывной области данных в памяти за константное время. Также будет рассмотрен опыт внедрения и применения данной технологии в реальных условиях. Отдельное внимание будет уделено решению проблем, возникших в процессе реализации и тестирования.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bghNU
В докладе Тимура Давыдова (Московская Биржа) рассмотрим архитектуру современной торгово-клиринговой системы (ТКС) и более подробно познакомимся с in-memory-базой данных, оптимизированной для работы с низкими и предсказуемыми задержками, предназначенными для хранения информации во время работы ТКС.
📋 https://clck.ru/bggxi
В связи с изменением поведения рынков со временем и требованием хранения большего количества информации, были сделаны оптимизации как в самом представлении данных, так и в организации базы данных. Но одна проблема все еще оставалась нерешенной — это выделение оптимального объема памяти для каждой таблицы БД с расчетом на худший случай.
Поэтому в докладе также будут рассмотрены способы увеличения объема непрерывной области данных в памяти и предложена оптимальная реализация технологии динамического увеличения непрерывной области данных в памяти за константное время. Также будет рассмотрен опыт внедрения и применения данной технологии в реальных условиях. Отдельное внимание будет уделено решению проблем, возникших в процессе реализации и тестирования.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bghNU
Всем привет!
Что могут C и C++, и когда нужен ассемблер – узнаем у Александра Крижановского. Он является основателем и системным архитектором Tempesta Technologies, экспертом в области высокопроизводительных вычислений в Linux/x86-64.
📋 https://clck.ru/bkrkK
C и C++ известны скоростью сгенерированного кода. Однако, код генерируется конкретным компилятором под конкретную ОС на конкретное железо. Расширения компиляторов позволяют генерировать еще более быстрый код, чем для "чистых" C и C++. Микропроцессоры тоже предоставляют свои расширения, которые недоступны даже для расширений компилятора и для использования которых нужен ассемблер.
В этом докладе Александр посмотрит, какой код генерируют GCC и Clang для некоторых C и C++ конструкций и как сделать этот код быстрее. Также он копнет в специфичные для x86-64 оптимизации. Обсудит микробенчмарки.
А еще узнаем:
- Как x86-64 исполняет код и как работает с памятью.
- Некоторые полезные расширения и оптимизации GCC и Clang для C и C++.
- Когда ассемблер x86-64 не только быстрее, но и проще C.
- Скользкие места программирования для многоядерных архитектур.
- Защита от Spectre в компиляторах.
- Profiler guided optimization (PGO) и когда она бесполезна.
📍До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bkrkm
Что могут C и C++, и когда нужен ассемблер – узнаем у Александра Крижановского. Он является основателем и системным архитектором Tempesta Technologies, экспертом в области высокопроизводительных вычислений в Linux/x86-64.
📋 https://clck.ru/bkrkK
C и C++ известны скоростью сгенерированного кода. Однако, код генерируется конкретным компилятором под конкретную ОС на конкретное железо. Расширения компиляторов позволяют генерировать еще более быстрый код, чем для "чистых" C и C++. Микропроцессоры тоже предоставляют свои расширения, которые недоступны даже для расширений компилятора и для использования которых нужен ассемблер.
В этом докладе Александр посмотрит, какой код генерируют GCC и Clang для некоторых C и C++ конструкций и как сделать этот код быстрее. Также он копнет в специфичные для x86-64 оптимизации. Обсудит микробенчмарки.
А еще узнаем:
- Как x86-64 исполняет код и как работает с памятью.
- Некоторые полезные расширения и оптимизации GCC и Clang для C и C++.
- Когда ассемблер x86-64 не только быстрее, но и проще C.
- Скользкие места программирования для многоядерных архитектур.
- Защита от Spectre в компиляторах.
- Profiler guided optimization (PGO) и когда она бесполезна.
📍До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bkrkm