РИТ++ 2017 завершён. Ждем вас на Highload++ Junior 2018! Подать заявку на доклад

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

Конференция Highload++ Junior проходит в рамках профессионального фестиваля "Российские интернет-технологии". Вам, как участнику конференции, доступны все доклады этой конференции.

Кроме этого, Вы cможете посетить все общие доклады фестиваля, интересные широкой публике, и специализированные доклады конференций блока серверных технологий: конференции "RootConf 2017", "Backend Conf 2017".

Также мы формируем Программу++ — это программа митапов и небольших встреч, которую организуют сами участники фестиваля и всех его конференций. Вы предлагаете тему митапа, а организаторы подбирают для него площадку и зал.

Участники конференции Highload++ Junior также имеют возможность бесплатного прохода на любой из докладов смежной конференции Backend Conf. Конференция будет проходить параллельно в соседнем зале. Такое решение принял Программный комитет, когда устал ломать голову над тем, куда отнести тот или иной доклад :)

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

Оптимизация баз данных

MySQL: чек-лист для новичка в highload

Анастасия Распопина
Света Смирнова

В рамках данного доклада в диалоговом формате будут рассмотрены наиболее распространённые вопросы по MySQL - от краткого обзора возможностей основных вариантов этой СУБД (актуальное состояние Oracle MySQL, Percona Server и MariaDB) до выбора наиболее оптимальных значений для конкретных параметров, чтобы справиться с ростом вашего проекта.

Подтемы доклада:
- обзор форков MySQL (для каких специфических задач подойдут форки вместо оригинального MySQL);
- что такое highload в современном мире (где ещё не highload, а где уже highload);
- что храним в памяти, что на диске;
- кэширование;
- кластеризация;
- репликация/шардинг базы данных;
- умеет ли СУБД кросс-датацентр репликацию;
- MySQL-индексы;
- настройка MySQL под нагрузку;
- лог медленных запросов в MySQL + анализ запросов;
- как понять, что "тупит" не MySQL.

MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

Профилирование

Погружение в виртуальную память и большие страницы

Константин Новаковский

Современные приложения часто используют большое количество памяти, ещё чаще разработчики не задумываются, как именно приложение работает с памятью, и откуда она берётся. Просим ядро дать кусок памяти и начинаем с ним что-то делать... Но что за память нам выделяет ядро операционной системы? Память на самом деле виртуальная и делится на единицы, называемые страницами. Страницы бывают маленькими, бывают большими и очень большими.

* Как ядро работает с этими страницами?
* Как аппаратная часть помогает ядру ОС работать с виртуальной памятью?
* Какова цена виртуальной памяти?
* Для чего нужны большие страницы и почему их "прозрачное" использование может сделать хуже?
* Сколько памяти на самом деле потребляет приложение?

В своём докладе я постараюсь ответить на эти вопросы, расскажу о способах использования больших страниц и попутно "зацеплю" инструменты для профилирования.

Оптимизация производительности
,
Профилирование
,
Аппаратное обеспечение
Доклад принят в программу конференции

Балансировка нагрузки

Балансировка HTTP-трафика

Антон Резников

С задачей балансировки трафика сталкивается любой растущий web-проект и почти
каждый сталкивается с проблемами и типичными ошибками в её решении. Цель доклада —
рассказать о распространённых ошибках и помочь слушателю выбрать подходящее
решение для своего проекта.

Мы рассмотрим три самые распространённые задачи: распределения запросов
динамического контента (HTML, API), раздачу статического контента и загрузку
данных от пользователя. На примере этих задач мы будем добиваться масштабируемости,
высокой доступности, затронем проблемы эксплуатации и гео-балансировку.

API
,
Отказоустойчивость
Доклад принят в программу конференции

Выбор технологий

Как сделать сложное простым. История создания Проект1917

Сергей Спорышев

В докладе я поделюсь нашим опытом разработки Project1917 - исторического проекта в реальном времени в формате социальной сети.

Каждый web-программист мечтает написать свой фреймворк, CMS или соцсеть, и современный стек технологий дает настолько широкий выбор инструментов, что очень легко построить переусложненное архитектурное решение.

В докладе я расскажу, как не распыляться на новые технологии. Как, пользуясь проверенной временем связкой Nginx+MySQL+Laravel+AngularJS, в кратчайшие сроки построить сложный проект, рассчитанный на большую нагрузку и при всем этом имеющий простую, легко поддерживаемую и расширяемую архитектуру.

В программе:
- Организация фронта, архитектурные решения, чтобы все работало очень быстро, и стоимость изменений была минимальна.
- Организация пользовательской части "социальной сети" минимальными средствами: организация фидов/ленты, организация системы комментариев, организация системы лайков.
- Сложная, функциональная админка с постоянно работающими 100 редакторами.
- Разработка системы пуш-уведомлений в ночь перед запуском.
- Точно в срок без канбан и прочих методологий.

Single page application, толстый клиент
,
Генераторы статики
,
Взаимодействие с серверной стороной (API)
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
Фреймворки
,
PHP
,
Организация системы кеширования
,
Оптимизация производительности
,
Критерии выбора технологий для проекта
Доклад принят в программу конференции

Принципы масштабирования

BigMemory - работа с сотнями миллионов бизнес-объектов в управляемых средах

Дмитрий Хмаладзе

Наш доклад описывает способ использования больших объемов памяти, которые стали доступны в последние годы. К сожалению, эта память обычно остается незадействованной в управляемых средах исполнения в связи с принудительной сборкой мусора. Разработчики прибегают к внешним хранилищам данных ( i.e Memcached), что несет дополнительные расходы.

Описываемый нами способ BigMemory Pile обкатан и применим для большинства современных приложений, связанных с социальными графами, обработкой потоков, IoT, stateful-алгоритмов/анализ, системами кэширования и отслеживания причинно-следственных связей.

BigMemory Pile основан на прозрачной сериализации нативных объектов среды исполнения с сохранением данных в пред-аллокированных массивах большого размера, тем самым достигается "невидимость" объектов предметной области для сборщика мусора.

Практичность подхода BigMemory заключается в том, что приложение обеспечивает надежную пропускную способность и время отработки, полностью устраняя паузы сборщика мусора, позволяя вести разработку на нативных объектах ООП (классы, полиморфизм, графы), при этом, несмотря на сериализацию, приложение обрабатывает больше запросов в секунду, чем хранение данных в виде объектов или во внешнем хранилище.

Прочие языки
,
Базы данных / другое
,
Организация системы кеширования
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
Доклад принят в программу конференции

Антипаттерны, ошибки проектирования

ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам

Андрей Половов
Андрей Колаштов

Наша специализация — запуск и обслуживание высоконагруженных сервисов. За все время у нас не было ни одного проекта, в котором бы при запуске или эксплуатации сервиса не проявились нагрузочные проблемы, заложенные программистами или архитекторами. Цель доклада — структурировать типовые проблемы нагруженных проектов и дать практические советы по их урегулированию.

Решив, что большинство проблем имеют общие корни, мы решили систематизировать их и поделиться с коллегами. В данном докладе представляем собственный рейтинг типовых highload-проблем и даём практические советы по их решению.

Доклад затронет следующие области:
* базы данных,
* код,
* архитектура,
* сеть,
* деплой,
* и самое неизбежное — человеческий фактор.

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

Ошибки проектирования высоконагруженных проектов

Максим Ехлаков

Наиболее типичные ошибки, которые совершаются при создании высоконагруженных продуктов: выбор используемых языков, фреймворков, СУБД и других инструментов. Каковы причины совершения этих ошибок, и как их избежать.

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

На примере нескольких реальных проектов мы поговорим об ошибках проектирования, разработки и управления, о том, почему они возникли, и о решениях, которые позволили (или не позволили) преодолеть их.

Фреймворки
,
PHP
,
Прочие языки
,
MongoDB
,
Микросервисы, SOA
,
Оптимизация производительности
,
Профилирование
,
Синхронизация данных, параллельная обработка, CDN
,
Проектирование информационных систем
Доклад принят в программу конференции

Database First! О распространённых ошибках использования РСУБД

Николай Самохвалов

Любой Full Stack Developer сегодня обязан иметь в своём арсенале опыт и умение работы хотя бы с одной популярной РСУБД. Но без понимания основ — того, какие задачи решают СУБД, как происходит работа с данными, какие есть базовые возможности для этой работы, — такие умения превращаются в воздушный замок, быстро разрушающийся при росте проекта.



Этот доклад — попытка разбудить интерес слушателей к тщательному изучению основ теории и практики реляционных баз данных и к применению всей мощи РСУБД по прямому назначению.

Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки:
- элементарная модификация данных;
- работа с датой, временем и временными зонами;

- проверка ограничений целостности;
- очередь заданий;
- пакетная работа с данными (например, удаление пачки записей в таблице);
- полнотекстовый поиск;
- относительно новые задачи (создание API, machine learning).

Для каждого кейса мы сравним плюсы и минусы реализаций «на стороне СУБД» и «снаружи / на стороне приложения», прежде всего с точки зрения производительности. Постараемся понять, почему современные разработчики часто боятся использовать мощь РСУБД. Откуда пошёл миф «хранимки — зло».

Ну и, наконец, представим чеклист знаний (с перечнем полезных ссылок!), которые, по мнению автора, необходимо иметь, чтобы чувствовать себя увереннее при работе с РСУБД.

Бэкенд / другое
,
PostgreSQL
,
Базы данных / другое
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Архитектуры / другое
,
Администрирование баз данных
Доклад принят в программу конференции

Прочие темы

Приключения проекта от компьютера разработчика до серьезных нагрузок

Андрей Минкин

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

Со временем проект становится популярнее и популярнее, нагрузка начинает расти и мы поговорим о том, что такое:
0. Нагрузка? Как ее анализировать? Как понять, где нагрузка? Как оптимизировать код? Когда внедрять кэширование и начинать масштабирование. Какие подводные камни вас ожидают?
1. Кэширование. Как внедрить, и какие есть подводные камни. Как оценить, что кэширование работает? Какие проблемы возникают, если кэширование работает плохо.
2. Путь масштабирования и борьба за ресурсы. Как жить, если все сервисы дерутся? Когда масштабировать, и какие есть варианты масштабирования
3. Проблемы балансировки.
4. Подводные камни в распределенных системах. Состояния гонки и проблемы конкурентного доступа. Целостность данных. Событийная целостность.

Миграции данных
,
Оптимизация производительности
,
Профилирование
Доклад принят в программу конференции

Как заранее соломки подстелить или путь к 99,99% uptime проекта

Игорь Мызгин

Каждый проект проходит несколько жизненных стадий, на каждой из которых есть развилка: умереть, замереть на данной стадии или перейти на качественно новый уровень. Первой стадией является чуть ли не виртуалка / мокап / скетч на ноутбуке фаундера/кофаундера. Вторая стадия - это одна/две/три виртуалки на каком-нибудь хостинге. И третий этап - активный рост, развитие инфраструктуры, публикации на ТехКранче и прочие символы успеха.

Между вторым этапом и третьим - пропасть, причем пропасть даже не одна, а несколько пропастей, целая "долина смерти" - бизнес-модель, правильное позиционирование, правильная команда, правильное ценообразование, правильная эксплуатация. Мой доклад посвящен именно вопросам правильной эксплуатации, так как по опыту общения - очень многие стартапы находятся в неком заблуждении, что если хостер имеет SLA и гарантирует некий uptime своей инфраструктуры и своих инфраструктурных сервисов, то этот uptime автоматически распространяется и на приложения стартаперов.

В своем докладе я буду говорить о том, о чем надо не забывать пока маленьким проектам, чтобы смочь вырасти большими и при этом не потратить все ресурсы на создание инфраструктуры проекта. Я детально проговорю то, о чем 99% клиентов хостинга задумываются по факту:
- о разграничении ответственности между клиентом и хостером,
- о том, что написано в SLA и как этот / эти документы читать,
- что должен сделать проект сам, и почему за проект это не будет делать хостер,
- как спланировать свой рост и не стать заложником изначальной инфраструктуры при активном росте,
- о чем надо спросить "на берегу" провайдера/провайдеров.

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

Отказоустойчивость
,
Распределенные системы
,
Разделение представления и бизнес-логики, шаблонизация
,
Архитектуры / другое
,
Управление конфигурацией
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Большие проекты/команды
,
Работа со внешним заказчиком/исполнителем
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Доклад принят в программу конференции

SOA: послать запрос на сервер? Что может быть проще?!

Иван Круглов

Микросервисы - это круто, модно и интересно. Переход на их использование принесет команде заметные преимущества. Но сервис-ориентированная архитектура (SOA) не лишена недостатков. Один их них - это то, что, заменяя простой вызов функции на RPC, мы в неявном виде вводим в уравнение, отвечающее за стабильность системы, целую плеяду новых неизвестных. Например, простейший HTTP-запрос за время своей жизни проходит через множество всевозможных буферов, очередей и алгоритмов на своем пути от клиента к серверу и обратно. Совокупное поведение этих составляющих трудно предсказать, понять и правильно интерпретировать. И особенно трудно это сделать в нестандартных ситуациях.

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

Микросервисы, SOA
,
Архитектурные паттерны
,
Отказоустойчивость
,
Методы и техника разработки ПО
Доклад принят в программу конференции

Проксирование HTTP-запросов web-акселератором

Александр Крижановский

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

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

- Как работает HTTP-проксирование без кэша;
- Что такое персистентные соединения и чем они отличаются от HTTP keep alive;
- Как, когда и сколько соединений может устанавливать HTTP-акселератор с апстримом;
- Что становится с запросами, которые ждут очереди на отправку в соединение с апстримом, но апстрим "из коробки" и сбрасывает соединения каждые 100 запросов;
- Что такое HTTP pipelining, и как им пользуются современные HTTP-акселераторы;
- Что такое неидемпотентные запросы, и почему нужно о них беспокоиться.

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

После подключения DDoS-защиты: как "положат" Ваши ресурсы

Рамиль Хантимиров

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

Защита информации
,
Бэкенд / другое
Доклад принят в программу конференции

Как устроены базы данных

Илья Космодемьянский

Хранить и обрабатывать данные нужно везде, неслучайно, как минимум последние полвека, интенсивно развивались специализированные для этой задачи фреймворки - сервера управления базами данных (СУБД). Как они выглядят сейчас и почему, несмотря на разницу в реализации, одни СУБД принципиально похожи на другие?

В этом докладе мы начнем с основ: транзакции, алгоритмы сериализации, контроля конкурентного доступа и восстановления. Как они реализованы в современных СУБД? Что нужно знать о них разработчику или администратору высоконагруженных систем? Как устроен WAL, и как это помогает обеспечивать резервное копирование и отказоустойчивость? Как СУБД работает с памятью и диском? Почему SQL до сих пор жив как технология, и как работает оптимизатор?

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

PostgreSQL
,
Базы данных / другое
,
MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

Чеклист по клиентской оптимизации

Николай Лавлинский

Когда проект растёт, возникает множество проблем с масштабируемостью сервиса: БД, сервера приложений, хранилище. Однако, не менее важной становится клиентская часть веб-приложения.

Во-первых, грамотная клиентская оптимизация позволяет повысить скорость работы сервиса для пользователей и, следовательно, увеличить их лояльность, которая конвертируется в деньги.

Во-вторых, применение методик клиентской оптимизации даёт экономию серверных ресурсов: трафик, каналы, место на диске, иногда даже CPU. Для растущих проектов это становится важным.

В докладе разберём пример ускорения реального сайта, по шагам замеряя эффект.

Вот примерный чеклист по клиентской оптимизации, покрывающий большинство проблем среднего веб-проекта:
1. Базовая конфигурация Nginx для эффективной раздачи статики.
2. Клиентское кэширование: заголовки, сброс кэша, особенности браузеров.
3. Сжатие текстового контента: gzip, zopfli, brotli, статическое сжатие, поддержка Nginx и браузеров.
4. Быстрый TLS: конфигурация Nginx, нагрузка на сервер и клиент, наиболее оптимизированные шифры, типы сертификатов, stapling, кэширование сессий, HTTP/2.
5. Настройка TCP/IP-стека в Linux для веб-приложений.
6. Оптимизация картинок: для JPEG, PNG, SVG, применение WebP.
7. Веб-шрифты: форматы, подходы к оптимизации.
8. Общий подход к ускорению рендеринга страниц (синхронная/асинхронная загрузка CSS, JS, объединение ресурсов), клиентские SPOF.
9. Использование CDN: когда нужно, зачем. Влияние задержек сети на скорость.
10. Средства синтетического тестирования клиентской скорости.

Веб-графика, оптимизация изображений
,
Сетевое администрирование
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

Рост с нуля до 15000 сообщений в секунду. Мучительный и поучительный

Юрий Колесов

Компания TIMCONNECT процессит банковские смс-сообщения, по возможности отправляя их как push.

Расскажем, как мы за 2 месяца небольшой командой масштабировались в 15 раз, минимально переписывая код, применяя паттерны из хайлоада методом проб и ошибок. На примерах проиллюстрируем, что хайлоад может быть достижим просто и быстро. Если повезет.

Доклад о собранных граблях и сделанных выводах, применимых к большинству проектов.

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