DevConf 2016
"Производительность MySQL: что нового?", Алексей Копытов
Алексей Копытов — разработчик MySQL и связанных с ним проектов с 2004г. Работал в компаниях MySQL AB, Sun Microsystems и Oracle. В компании Percona участвовал в разработке Percona Server, XtraBackup и XtraDB Cluster. В настоящее время занимается проблемами производительности MySQL на современном оборудовании.
MySQL 5.7 предлагает огромное количество улучшений в производительности практически всех компонентов: InnoDB, секционирования, бэкапов, репликации, DDL и оптимизаторе запросов.
В этом докладе мы рассмотрим эти оптимизации подробно, а также поговорим о проблемах, которые остаются актуальными до сих пор, возможных методах их решения и планируемых дальнейших оптимизациях в MySQL 8.
Быстрый старт iOS приложения на примере iOS Почты Mail.Ru / Николай Морев (Ma...Ontico
Мы посвятили два месяца исследований и разработки сокращению времени запуска нашего приложения. В докладе мы расскажем все, что нам удалось узнать на собственном опыте о приемах и хитростях ускорения приложений под iOS, поделимся конкретными рецептами и расскажем о результатах проделанной работы.
- Что можно и нужно оптимизировать?
- Как сократить время от нажатия на иконку до показа экрана запуска?
- Инструменты анализа производительности: не только Time Profiler.
- Что быстрее: XIB или создание UI в коде?
- Замеры скорости запуска как часть Continuous Integration.
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
DevConf 2016
"Производительность MySQL: что нового?", Алексей Копытов
Алексей Копытов — разработчик MySQL и связанных с ним проектов с 2004г. Работал в компаниях MySQL AB, Sun Microsystems и Oracle. В компании Percona участвовал в разработке Percona Server, XtraBackup и XtraDB Cluster. В настоящее время занимается проблемами производительности MySQL на современном оборудовании.
MySQL 5.7 предлагает огромное количество улучшений в производительности практически всех компонентов: InnoDB, секционирования, бэкапов, репликации, DDL и оптимизаторе запросов.
В этом докладе мы рассмотрим эти оптимизации подробно, а также поговорим о проблемах, которые остаются актуальными до сих пор, возможных методах их решения и планируемых дальнейших оптимизациях в MySQL 8.
Быстрый старт iOS приложения на примере iOS Почты Mail.Ru / Николай Морев (Ma...Ontico
Мы посвятили два месяца исследований и разработки сокращению времени запуска нашего приложения. В докладе мы расскажем все, что нам удалось узнать на собственном опыте о приемах и хитростях ускорения приложений под iOS, поделимся конкретными рецептами и расскажем о результатах проделанной работы.
- Что можно и нужно оптимизировать?
- Как сократить время от нажатия на иконку до показа экрана запуска?
- Инструменты анализа производительности: не только Time Profiler.
- Что быстрее: XIB или создание UI в коде?
- Замеры скорости запуска как часть Continuous Integration.
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Database First! О распространённых ошибках использования РСУБДNikolay Samokhvalov
Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки:
- элементарная модификация данных;
- работа с датой, временем и временными зонами;
- проверка ограничений целостности;
- очередь заданий;
- пакетная работа с данными (например, удаление пачки записей в таблице);
- полнотекстовый поиск;
- относительно новые задачи (создание API, machine learning).
ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)Ontico
Сначала несколько слов про предпосылки задачи.
1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна
2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.
3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.
Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;
Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.
Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.
* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.
Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk
Планирование требуемых ресурсов, (не-)линейность масштабирования.
Эффективная отладка репликации MySQL / Света Смирнова (Percona)Ontico
Репликация - одна из ключевых возможностей MySQL. Лёгкая в установке, позволяющая производить изменения и на мастере, и на слейве, что в свою очередь позволяет создавать сколь угодно сложные развёртывания. Репликация в MySQL асимметричная, допускающая некоторый уровень синхронизации при помощи semi-sync replication plugin. Начиная с версии 5.7 поддерживает одновременную репликацию с нескольких мастеров на один слейв.
Простота использования имеет свою обратную сторону: при проектировании репликации достаточно легко выбрать неправильное решение и познакомиться со всеми его подводными камнями.
В рамках этого доклада я расскажу об особенностях репликации MySQL, типичных ошибках и способах борьбы с ними. Мы затронем как проблемы, приводящие к появлению неожиданных данных и десинхронизации, так и производительность.
Оптимизация высоконагруженных ASP.NET приложений, работающих с MS SQL Server ...Stas Vyschepan
Вы разрабатываете веб-приложения и используете хранимые процедуры? Вы пишите SELECT … WITH(NOLOCK)? Вы считаете, что ORMы снижают быстродействие приложений? Тогда этот доклад для вас!
В докладе будут развенчаны популярные мифы о применении библиотек Object-Relational Mapping (ORM) в ASP.NET при работе с Microsoft SQL Server. Также будут рассмотрены конкретные методики увеличения быстродействия работы с данными в веб-приложениях.
Быстрый рендеринг с DOM шаблонизаторами / Борис Каплуновский (aviasales.ru)Ontico
1. Типы шаблонизаторов DOM/innerHTML.
2. Внутренности AngularJS и почему он тормозит.
3. Внутренности ReactJS и почему он тормозит.
4. Менее раскрученные решения Blaze/PaperclipJS/Riot и что там сделано лучше.
5. Плюсы и минусы virtualdom.
6. Работа с DOM может быть быстрее, если:
6.1 Использовать одни и те-же участки DOM несколько раз.
6.2 Сокращать количество reflow с DocumentFragment.
6.3 Быстрое создание повторяющихся участков DOM с помощью cloneNode.
6.4 Создавать куски DOM ahead of time.
7. Встречаем temple - шаблонизатор, работающий в разы быстрее reactjs и не требующий загрузки 40k библиотеки времени исполнения.
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
SERP или просто страница результатов поисковой выдачи — это действительно большой проект с огромной аудиторией. Над ним работают около 40 фронтендеров из разных городов. Эта страница показывается больше 200 000 000 раз в день. При таких размерах даже модульная архитектура уже не слишком спасала нас от странных, неочевидных зависимостей, лишних стилей и нескольких разных реализаций почти одинаковых компонентов.
Процесс разработки новой, даже довольно простой на первый взгляд фичи занимал чудовищное количество времени и представлял из себя хаотичное взаимодействие большого количества людей: фронта, бэкенда, дизайнеров и менеджеров.
Стала закрадываться мысль, что пора что-то менять. И мы поменяли.
В докладе я расскажу о том, как мы с помощью проекта на стыке фронтендеров, менеджеров, и дизайнеров, навели во всем этом идеальный порядок. Каким образом поменяли наш код процессы и инструменты, а также что нам это дало, и как будем жить с этим дальше.
Если вам знакомы похожие проблемы, то наш опыт может оказаться вам чертовски полезным.
libfpta — обгоняя SQLite и Tarantool / Леонид Юрьев (Positive Technologies)Ontico
HighLoad++ 2017
Зал «Найроби + Касабланка», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2837.html
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
Компания Positive Technologies производит программные продукты в области информационной безопасности, в том числе обеспечивающие предотвращение вторжений и мониторинг событий безопасности, в том числе на крупномасштабных объектах относящихся к критической инфраструктуре. Для ряда таких продуктов потребовалось разделяемое оперативное хранилище.
...
Database First! О распространённых ошибках использования РСУБДNikolay Samokhvalov
Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки:
- элементарная модификация данных;
- работа с датой, временем и временными зонами;
- проверка ограничений целостности;
- очередь заданий;
- пакетная работа с данными (например, удаление пачки записей в таблице);
- полнотекстовый поиск;
- относительно новые задачи (создание API, machine learning).
ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)Ontico
Сначала несколько слов про предпосылки задачи.
1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна
2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.
3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.
Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;
Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.
Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.
* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.
Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk
Планирование требуемых ресурсов, (не-)линейность масштабирования.
Эффективная отладка репликации MySQL / Света Смирнова (Percona)Ontico
Репликация - одна из ключевых возможностей MySQL. Лёгкая в установке, позволяющая производить изменения и на мастере, и на слейве, что в свою очередь позволяет создавать сколь угодно сложные развёртывания. Репликация в MySQL асимметричная, допускающая некоторый уровень синхронизации при помощи semi-sync replication plugin. Начиная с версии 5.7 поддерживает одновременную репликацию с нескольких мастеров на один слейв.
Простота использования имеет свою обратную сторону: при проектировании репликации достаточно легко выбрать неправильное решение и познакомиться со всеми его подводными камнями.
В рамках этого доклада я расскажу об особенностях репликации MySQL, типичных ошибках и способах борьбы с ними. Мы затронем как проблемы, приводящие к появлению неожиданных данных и десинхронизации, так и производительность.
Оптимизация высоконагруженных ASP.NET приложений, работающих с MS SQL Server ...Stas Vyschepan
Вы разрабатываете веб-приложения и используете хранимые процедуры? Вы пишите SELECT … WITH(NOLOCK)? Вы считаете, что ORMы снижают быстродействие приложений? Тогда этот доклад для вас!
В докладе будут развенчаны популярные мифы о применении библиотек Object-Relational Mapping (ORM) в ASP.NET при работе с Microsoft SQL Server. Также будут рассмотрены конкретные методики увеличения быстродействия работы с данными в веб-приложениях.
Быстрый рендеринг с DOM шаблонизаторами / Борис Каплуновский (aviasales.ru)Ontico
1. Типы шаблонизаторов DOM/innerHTML.
2. Внутренности AngularJS и почему он тормозит.
3. Внутренности ReactJS и почему он тормозит.
4. Менее раскрученные решения Blaze/PaperclipJS/Riot и что там сделано лучше.
5. Плюсы и минусы virtualdom.
6. Работа с DOM может быть быстрее, если:
6.1 Использовать одни и те-же участки DOM несколько раз.
6.2 Сокращать количество reflow с DocumentFragment.
6.3 Быстрое создание повторяющихся участков DOM с помощью cloneNode.
6.4 Создавать куски DOM ahead of time.
7. Встречаем temple - шаблонизатор, работающий в разы быстрее reactjs и не требующий загрузки 40k библиотеки времени исполнения.
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
SERP или просто страница результатов поисковой выдачи — это действительно большой проект с огромной аудиторией. Над ним работают около 40 фронтендеров из разных городов. Эта страница показывается больше 200 000 000 раз в день. При таких размерах даже модульная архитектура уже не слишком спасала нас от странных, неочевидных зависимостей, лишних стилей и нескольких разных реализаций почти одинаковых компонентов.
Процесс разработки новой, даже довольно простой на первый взгляд фичи занимал чудовищное количество времени и представлял из себя хаотичное взаимодействие большого количества людей: фронта, бэкенда, дизайнеров и менеджеров.
Стала закрадываться мысль, что пора что-то менять. И мы поменяли.
В докладе я расскажу о том, как мы с помощью проекта на стыке фронтендеров, менеджеров, и дизайнеров, навели во всем этом идеальный порядок. Каким образом поменяли наш код процессы и инструменты, а также что нам это дало, и как будем жить с этим дальше.
Если вам знакомы похожие проблемы, то наш опыт может оказаться вам чертовски полезным.
libfpta — обгоняя SQLite и Tarantool / Леонид Юрьев (Positive Technologies)Ontico
HighLoad++ 2017
Зал «Найроби + Касабланка», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2837.html
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
Компания Positive Technologies производит программные продукты в области информационной безопасности, в том числе обеспечивающие предотвращение вторжений и мониторинг событий безопасности, в том числе на крупномасштабных объектах относящихся к критической инфраструктуре. Для ряда таких продуктов потребовалось разделяемое оперативное хранилище.
...
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Как мы разрабатываем новый фронтенд / Филипп Нехаев (Tinkoff.ru)Ontico
Недавно запустили новый сайт Тинькофф.
У нас есть желание поделиться с аудиторией подходом и опытом разработки большого изоморфного приложения на React.js и Flux. Меньше чем за год мы разработали новый сайт и интернет-банк, заложив платформу на ближайшие несколько лет для быстрой разработки фронтенда новых продуктов.
Сейчас tinkoff.ru насчитывает более 3000 компонентов и сотни страниц.
Pconnect: граната в руках обезьяны. Сергей Аверин, Badoo.
Persistent connect. Это всегда преподносится как plug'n'play. В учебниках информации очень мало. Но все всегда думают, что это «просто работает».
- Что это, вообще, такое, зачем было придумано и какие задачи призвано решать.
- О том, как этим всем пользуются, и что получается в итоге.
- О том, как, на самом деле, это работает. Про что не пишут в учебниках.
- Stateful-протоколы, пример с проблемами в mysql.
- В stateless-мире все не так уж солнечно.
- Большинство протоколов просто не рассчитано на pconnect. Баги в C++ софте (которые есть всегда) + pconnect + простоватый протокол = адская смесь. Каким должен быть протокол.
- Мелкие нюансы, из-за которых возникают проблемы.
- Connection pooling — что это и с чем его едят.
- Как со всем этим жить.
Антон Щербаков, Отказоустойчивость на примере aviasales — почему даже если на...Tanya Denisyuk
В докладе на примере системы метапоиска aviasales будет рассмотрен переход от монолитной архитектуры RoR приложения к многозвенной системе внутренней разработки на базе tornado/python в целях ослабления зависимостей между подсистемами, упрощения контроля за потоком данных и изоляции потенциальных аварийных ситуаций.
Будут рассмотрены побочные эффекты этого перехода, такие как устойчивость к пиковым нагрузкам, упрощение схемы выкатки обновлений и сокращение потребляемых машинных ресурсов.
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
2. Задача
● Выдача ссылок на новости
● База из тысяч новостей
● Ссылки выбираются произвольно
● Распределение – неравномерное
● Форматирование ссылок перед выдачей
● Ссылки должны иметь формат блока
● Дополнительные поля: идентификатор блока, …
3. Ta-da!
● Требования: >= 5000 запросов в секунду
● Не справляемся – должны быстро выдавать
пустую страницу, чтобы не «ломать» вёрстку
● Никакого кэширования
● Срок выполнения: полтора месяца.
● При этом у разработчика баннерокрутилки
есть и другие задачи
4. Структура решения
● Структуры в памяти, хранящие новости
и статистику показов
● Множество потоков, обрабатывающих
HTTP-запросы
● Контроллер
● добавляющий и удаляющий новости
● собирающий статистику
● на основе TCP-сокетов
6. Erlang
● DSL для многопоточных приложений
● Встроенные в язык примитивы для посылки
и приёма сообщений
● Встроенные в язык шаблоны поведения
● Встроенная в язык in-memory БД
7. Структура решения
● Структуры в памяти, хранящие новости и
статистику показов: mnesia/ets/dict!
● Множество потоков, обрабатывающих HTTP-
запросы: gen_server!
● Контроллер: gen_tcp!
8. Структура решения
● Структуры в памяти, хранящие новости и
статистику показов: mnesia/ets/dict!
● Множество потоков, обрабатывающих HTTP-
запросы: gen_server!
● который уже написан за нас! mochiweb/misultin
● Контроллер: gen_tcp!
Batteries included
10. Основная часть решения
● HTTP-сервер Mochiweb получает запрос,
создаёт поток
● Поток забирает из Mnesia данные
● Поток производит выборку, сортирует
данные, форматирует строки, выдаёт,
умирает.
Все счастливы.
«In theory, there's no difference between
theory and practice. In practice, there is».
L. A. van der Snepscheut.
11. Факап #1
У каждой новости есть коэффициент
важности. В соответствии с этим
коэффициентом необходимо выдавать
новость чаще или реже остальных.
● Перед выдачей нужно назначать
взвешенные произвольные числа каждой
новости и делать по ним выборку.
● Новостей много.
12. Факап #1
● Mnesia построена на основе ETS
● http://www.erlang.org/doc/man/ets.html:
«In the current implementation, every object insert
and look-up operation results in a copy of the
object.»
● Т. е. в копировании сотен новостей из потока
в поток. Slow as hell.
13. Эврика!
● Вместо ETS напишем собственную структуру
данных на основе gen_server, dict, queue,
blackjack и hookers.
● Повесим её в виде отдельного потока
● Будем делать там грубую предвыборку
новостей, которые потом быстро
скопируются в рабочий поток
14. ● Результат:
рост производительности в 3 раза
● Вывод:
● всегда думай, какие объёмы данных копируешь!
● профилируй!
15. Основная часть решения v0.2
● HTTP-сервер Mochiweb получает запрос,
создаёт поток
● Поток отправляет запрос в gen_server
● gen_server производит предвыборку
новостей и присылает результат
● Поток производит выборку, сортирует
данные, форматирует строки, выдаёт,
умирает.
Все счастливы.
16. Факап #2
Новости – это текст.
Текст – это строки.
● Строки в Erlang – это связные списки
символов
● IO в Erlang – это очень медленно
17. Эврика!
● Если вы пишете на Erlang,
то строка символов записывается так:
"Hello world!~n"
● Конкатенация записывается так:
"Hello " ++ Username ++ "!~n"
18. Эврика!
● Если вы пишете на Erlang веб-приложения,
то строка символов записывается так:
<<"Hello world!~n">>
● Конкатенация записывается так:
[<<"Hello ">>, Username, <<"!~n">>]
19. Почему:
● <<>> – встроенный бинарный тип
● <<"">> – бинарная строка
● Списки символов нужно обрабатывать
перед выдачей
● Вывод бинарных данных – это просто
вызов writev(2)
● Blazingly Fast
20. Почему:
● "Hello" ++ "!n" => "Hello!n" => строка
● Конкатенация списков – O(n)
● Вывод строки => цикл по списку из 7 символов
● [<<"Hello">>, <<"!n">>] – тип iolist().
● Добавление в начало списка – O(1)
● Вывод => цикл по списку из 2 элементов
● Встроенным функциям I/O всё равно, что
выводить
21. Кроме того
● Строковые операции, наподобие обработки
регулярных выражений, всё равно дорогие
● Впрочем, они вообще не очень дешевы.
Обработку данных нужно делать не на этапе
выдачи, а на этапе помещения в базу – до
тех пор, пока позволяют объёмы памяти и
специфика решаемой задачи.
● В данном случае кэширование
конструируемых URL новостей и т. п.
позволило отыграть 15%
22. ● Результат:
рост производительности в 10 (десять) раз
● Вывод:
● всегда думай, как обрабатывать строки!
● профилируй!
23. Основная часть решения v0.3
● HTTP-сервер Mochiweb получает запрос,
создаёт поток
● Поток отправляет запрос в gen_server
● gen_server производит предвыборку
новостей и присылает результат
● Поток производит выборку, сортирует
данные, форматирует iolist()'ы, выдаёт,
умирает.
25. Основная часть решения v0.4
● HTTP-сервер Misultin получает запрос,
создаёт поток
● Поток отправляет запрос в gen_server
● gen_server производит предвыборку
новостей и присылает результат
● Поток производит выборку, сортирует
данные, форматирует iolist()'ы, выдаёт,
умирает.
26. Misultin
● Реализация gen_server, как и Mochiweb
● Интерфейс, абсолютно аналогичный
Mochiweb
● Стабильно на 10-15% быстрее
27. Результат
● Один человекомесяц
● Быстрое веб-приложение
# ab -qc 7200 -n 450000 http://localhost/block/35237
| grep Requests per sec
Requests per second: 7693.35 [#/sec] (mean)
#
28. Killing feature!
Начиная со второй недели разработки (как
только был написан каркас), приложение
было готово к работе.
В любой момент не работал только тот
функционал, который не был дописан.
● Ни отладки
● Ни непредусмотренного поведения
● Только профилирование
29. Killing feature!
● Ни отладки
● Ни непредусмотренного поведения
В Erlang есть концепция «Let it crash».
Близкий перевод – «Ну и хрен с ним».
30. Let it crash
● На обычном языке программирования:
res = web_server.start_link(callback = Fun)
if res == web_server.port_in_use:
raise Exception("Port in use")
elif res == web_server.socket_error:
raise Exception("Socket error")
elif res == errno.EACCES:
raise Exception("Not enough privileges")
31. Let it crash
● На Erlang:
{ok, Pid} = misultin:start_link([{loop, Fun}]).
32. Let it crash
● На Erlang:
{ok, Pid} = misultin:start_link([{loop, Fun}]).
● Если что-то шандарахнется, то
предположение
misultin:start_link/1 => {ok, _}
окажется неверным, и поток вылетит сам
с сообщением, например, таким:
{badmatch, {error, eacces}}
33. Результат
● Один человекомесяц
● Быстрое веб-приложение
● Стабильное веб-приложение – за счёт eunit
и «Let it crash»
● Минимум кода – за счёт множества
встроенных примитивов и «Let it crash»
● Минимум требуемого опыта – Erlang
изучается за 2 недели
34. Уровень программиста
● С одной стороны, Erlang учится за 2 недели
● С другой стороны, нужно иметь навыки
программирования. Not all batteries included
Для написания баннерокрутилки в разное время
требовался то JSON-декодер, то перекодировка из
UTF8 в CP1251, то htmlspecialchars(). Ничего этого
в stdlib нет, нужно брать сторонние библиотеки,
оценивать их работоспособность и
производительность.
35. Напутствие
● Предобрабатывай данные, пока это дёшево!
● Не выполняй одни и те же операции дважды!
● Используй «Let it crash» в интерфейсах
собственного кода!
● Профилируй!
● Переписывай медленные операции на C,
PHP, OCaml, whatever: существуют открытые
биндинги