Космические скорости: оптимизируем производительность
Расписание конференции HighLoad++ Foundation 2022 уже опубликовано. Залы проектируются, более 100 спикеров работают над докладами вместе с Программным комитетом.
До конца января повышения стоимости билетов не будет. А значит, сейчас самое время всё согласовать и оформить.
Забронировать билет на HighLoad++ Foundation
Работа над другой высоконагруженной конференцией — Saint HighLoad++ 2022 — только началась. Петербургский HighLoad++ пройдёт 27 и 28 июня. Call for Papers открыт до 27 января. Хотите стать спикером? Присылайте заявку! Подробности — по ссылке. Для вдохновения советуем почитать тезисы докладов HighLoad++ Foundation 2022.
Доклады об оптимизации производительности
Что нужно сделать уже сейчас, чтобы завтра ваши сервисы работали на космических скоростях? Об этом узнаем из доклада Дениса Исаева — руководителя продуктового бэкенд-отдела в Яндекс Go.
В своём выступлении Денис сфокусируется на ускорени в backend и технологиях на стыке backend/mobile для крупного и уже оптимизированного продукта. Он не будет говорить о базовых вещах.
Обсудим вот что:
- deadline propagation и hedged requests;
- может ли префетч в приложении замедлять;
- какой RTT на 2G и в Африке;
- цена фонового запроса и паттерн API Gateway;
- как продать бизнесу ускорение.
Дмитрий Самиров руководит пилотными проектами в Tarantool (Mail.ru Group). На конференции Дмитрий расскажет, как его команда за 2 месяца создала систему хранения товаров и остатков для магазинов «Магнит».
Внезапно пилотный проект превратился в хайлоад-сервис, который должен держать нагрузку 200 тысяч запросов в секунду.
На HighLoad++ Foundation 2022 узнаем:
- какие ошибки были допущены при проектировании сервиса и как их исправляли;
- с какими проблемами разработчики столкнулись при масштабировании системы.
И раз уж мы заговорили об архитектуре и масштабировании, предлагаем почитать статью о микросервисах.
Service Mesh на стероидах: как построить управляемое взаимодействие между сотнями микросервисов
Была ли у вас задача построить Enterprise-grade-приложение из десятков приложений поменьше? Которые не только слабо связаны друг с другом, но и разрабатываются разными командами с разными моделями релиза?
В Netcracker такую задачу решили. Как — читайте в статье на Хабре. Узнаете, как им помогла концепция Service Mesh и идея применить «микросервисную модель» к структуре Service Mesh. В результате у них получился Non Uniform Service Mesh (NUM), который представляет собой продукт и набор паттернов его применения.
