В 2020 году Saint HighLoad++ проводиться не будет.
В Санкт-Петербурге мы с вами встретимся в июне 2021

Заявки на доклады

Поиск по тегам:

Базы данных и системы хранения

Стандартно разработчик при поиске проблем в RDBMs подозревает медленные запросы. А что, если дело не в медленных запросах, и на самом деле виноваты совсем другие запросы?

Расскажу о том, какого типа запросы какую нагрузку дают на базу данных и при этом не дают вашему приложению работать так, как вы хотите. Как backend-разработчику определять такие запросы и каким инструментом для этого пользоваться? Особенно, когда необходимо найти проблемы здесь и сейчас на работающей системе, когда дорога каждая минута, а работа приложения с базой данных тормозит.

Думаете, это невозможно? Возможно, и я расскажу, как мы это делаем изо дня в день и какими инструментами для этого пользуемся.

Доклад принят в программу конференции

В своём докладе я расскажу про возможности ClickHouse, о которых обычно никто не подозревает. Некоторые из них были разработаны или найдены сообществом, и мы бы сами никогда не догадались, что систему можно использовать столь необычным образом. Рассмотрим, какие фичи нашли применение в продакшне, а о каких стоит ещё тщательно подумать.

Доклад принят в программу конференции

Системное администрирование

Наверное, вы легко перечислите 10 или более web-акселераторов, и список их постоянно растет. Кроме разных функциональных возможностей, web-акселераторы значительно отличаются архитектурно, тем, как они взаимодействуют с операционной системой и реализуют те или иные HTTP-стандарты.

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

В этом докладе мы обсудим следующие вопросы на примере Nginx, Varnish, Apache Traffic Server, HAProxy, H2O и Tempesta FW:
* Как прокси управляют соединениями с клиентом и к бэкенд-серверам;
* Очереди HTTP-сообщений и фейловеринг соединений с бэкендами в стандартах HTTP и реализациях прокси, и как это влияет на безопасность;
* Работа и взаимодействие декодеров и парсеров HTTP/1.x, HTTP/2 и HTTP/3 (QUIC);
* HPACK и QPACK компрессии в HTTP/2 и HTTP/3 (QUIC), соответственно, и как они влияют на производительность;
* Что, как и в каких случаях можно кэшировать;
* Различные архитектуры кэширования: mmap(), файловый кэш и база данных;
* Оптимизации на уровне сетевого I/O и TLS, доступные в некоторых web-акселераторах и современных Linux-ядрах.

Доклад принят в программу конференции

Бэкенд, теория программирования

Ежедневная проблема крупной службы доставки: как развести 5000 заказов с помощью 200 водителей. Чтобы начать решать такую задачу, нужно за 2 минуты посчитать 300 млн маршрутов. Затем за 10 минут нужно найти оптимальное размещение этих заказов по водителям. Хорошая новость в том, что у вас есть вычислительный кластер. Плохая новость в том, что даже с одним водителем вариантов объехать все заказы 5000! — это число с 16327 знаками. Хорошая новость в том, что самое оптимальное решение искать не нужно, достаточно решить эту задачу лучше человека (логиста). Логист находит решение этой задачи на 1 млн рублей логистических расходов. Если вы найдёте решение на 10% лучше, то сэкономите клиенту 100 тыс. рублей. И это за 12+ минут вы обработали только один запрос.

В докладе будут рассмотрены быстрые алгоритмы поиска оптимального пути на графе и дискретной оптимизации на вычислительном кластере в приложении к логистической задаче, используемые в Яндекс.Маршрутизации.

Доклад принят в программу конференции

Архитектуры, масштабируемость

Сбой даже, казалось бы, второстепенного компонента большой распределенной системы может потенциально привести к выходу из строя всего сервиса. На практике избежать сбоев нельзя, но можно сделать их максимально локальными. Другими словами, элементы архитектуры, которые мы проектируем, должны иметь минимально возможный бласт-радиус. Это задача архисложная, но выполнимая.

На примере EBS, базового продукта облака Amazon, я расскажу о том, как эволюционировала архитектура одного из ключевых компонентов этого сервиса. Основной фокус будет на деталях реализации микро-Ячеистой архитектуры. Вы прочитали правильно, не микро-Сервисы, но микро-Ячейки. Это подход, который позволяет принципиально уменьшить бласт-радиус, не жертвуя характеристиками целостности и доступности распределенных данных. Еще одна тайна архитектуры сервисов облака Amazon будет приоткрыта :)

Доклад принят в программу конференции