Ускорение показа превью изображений в Яндекс.Диске / Сергей Нечаев (Яндекс)
•Download as PPTX, PDF•
0 likes•1,057 views
В сутки Яндекс.Диск отдает более 40 миллионов сгенерированных превью изображений для просмотра в веб-интерфейсе Диска и в мобильных приложениях. В докладе будет рассказано о поиске узких мест в цепочке от запроса пользователя до показа ему картинки, создания мониторингов скорости показа картинок, мерах по оптимизации: какие варианты рассматривали, какие реализовали, и какие были итоги.
Report
Share
Report
Share
Recommended
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
Прежде всего, мы постараемся сделать доклад не сравнением feature-листов, а рассмотреть особенности практического применения разных систем для конкретной задачи - для сайта, который не должен падать (а точнее - для возможности оперативно отреагировать на аварию, понять что к ней привело, и как можно ее исправить).
Zabbix и миллионы метрик: наилучший опыт масштабного мониторинга / Алексей Вл...
Управление миллионами метрик таит в себе множество сложностей. Это вопросы автоматизации, масштабируемости, интеграции с другими системами и многое другое. Хочется максимально всё автоматизировать — один раз настроил и забыл. Возможно ли это?
Я подробно расскажу о накопленном практическом опыте использования Zabbix в самых жестоких условиях различных сценариев, расскажу на реальных примерах о том, как справиться с мониторингом тысяч удалённых точек, как не заблудиться в десятках миллионов триггеров и осилить динамические среды. Тут и о производительности нужно серьёзно задуматься.
Zabbix обладает целым набором функциональности, которая позволяет упростить жизнь отдела мониторинга. Конечно, подробности можно найти в документации, только не всегда понятно, как это правильно использовать.
Цель доклада — поделиться практическим опытом, это бесценно!
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
Как не положить тысячи серверов с помощью системы централизованного управлени...
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
Zabbix 3.4 - простая непростая дружба с сообществом / Алексей Владышев (Zabbix)
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 14:00
Тезисы:
http://rootconf.ru/2017/abstracts/2708.html
Сообщество любого открытого проекта созидательно по сути, не использовать эту силу будет большой ошибкой. Но всегда ли нужно слепо следовать за мнением большинства?
В своём докладе я расскажу о новой функциональности, ожидаемой в версии Zabbix 3.4, какие запросы наших пользователей мы решили реализовать, и какую роль в формировании роадмапа играет сообщество. Затрону тему общих принципов формирования роадмапа, и почему мы не готовы работать над всеми хотелками сообщества. Некоторые из них приходится ждать годами, а некоторые мы реализуем буквально за день.
Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?
Приходите! Доклад будет интересен не только тем, кто интересуется Zabbix и мониторингом в целом, но, надеюсь, что и разработчикам открытых программных продуктов.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
Recommended
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
Прежде всего, мы постараемся сделать доклад не сравнением feature-листов, а рассмотреть особенности практического применения разных систем для конкретной задачи - для сайта, который не должен падать (а точнее - для возможности оперативно отреагировать на аварию, понять что к ней привело, и как можно ее исправить).
Zabbix и миллионы метрик: наилучший опыт масштабного мониторинга / Алексей Вл...
Управление миллионами метрик таит в себе множество сложностей. Это вопросы автоматизации, масштабируемости, интеграции с другими системами и многое другое. Хочется максимально всё автоматизировать — один раз настроил и забыл. Возможно ли это?
Я подробно расскажу о накопленном практическом опыте использования Zabbix в самых жестоких условиях различных сценариев, расскажу на реальных примерах о том, как справиться с мониторингом тысяч удалённых точек, как не заблудиться в десятках миллионов триггеров и осилить динамические среды. Тут и о производительности нужно серьёзно задуматься.
Zabbix обладает целым набором функциональности, которая позволяет упростить жизнь отдела мониторинга. Конечно, подробности можно найти в документации, только не всегда понятно, как это правильно использовать.
Цель доклада — поделиться практическим опытом, это бесценно!
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
Как не положить тысячи серверов с помощью системы централизованного управлени...
В 2012 году мы начали внедрение CFEngine в нашу инфраструктуру. Переход на централизованное управление конфигурацией в проектах такого масштаба подобен ремонту - его невозможно закончить, его можно только прекратить. И уже весной 2013 года (в день 404 ошибки и международного дня Интернета) этот "ремонт" превратился в катастрофу и был остановлен. После 3 суток недоступности портала нам пришлось изобрести схему, которая бы физически ограничивала возможность повторения катастрофы. Схема включает в себя тестирование политик на тестовых серверах различной важности и конфигурации. "Маринование" в этой тестовой среде сопровождается автоматизированным контролем характеристик нагрузки этих серверов. Далее происходит обязательный ревью и плавное распространение последовательно по всем датацентрам.
В докладе будет рассказано:
1. почему мы выбрали CFEngine, а не Chief или Puppet;
2. как мы научили CFEngine быть дружелюбным (примеры политик и выдержки из библиотеки);
3. 100500 предпринятых мер, что бы не повторить "день 404" и соблюсти баланс между безопасностью и удобством;
4. как ещё можно использовать системы управления серверами.
Zabbix 3.4 - простая непростая дружба с сообществом / Алексей Владышев (Zabbix)
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 14:00
Тезисы:
http://rootconf.ru/2017/abstracts/2708.html
Сообщество любого открытого проекта созидательно по сути, не использовать эту силу будет большой ошибкой. Но всегда ли нужно слепо следовать за мнением большинства?
В своём докладе я расскажу о новой функциональности, ожидаемой в версии Zabbix 3.4, какие запросы наших пользователей мы решили реализовать, и какую роль в формировании роадмапа играет сообщество. Затрону тему общих принципов формирования роадмапа, и почему мы не готовы работать над всеми хотелками сообщества. Некоторые из них приходится ждать годами, а некоторые мы реализуем буквально за день.
Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?
Приходите! Доклад будет интересен не только тем, кто интересуется Zabbix и мониторингом в целом, но, надеюсь, что и разработчикам открытых программных продуктов.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые ...
Доклад осветит вопросы устройства REST API для веб-приложений и мобильных клиентов, от которых требуется высокая производительность.
Проектирование высокопроизводительных REST API.
- Кто должен участвовать в проектировании.
- Как узнать, что оптимизировать.
- Как измерять производительность REST API.
Паттерны и антипаттерны.
- Почему pagination - это плохо, и на что лучше заменить.
- Проблема N+1 и как с ней бороться.
- Бесполезные данные - как обнаружить и уничтожить.
- Как не ломать кэширование на клиенте.
- Эффективная работа с интерфейсами "мастер-детали".
Кэширование.
- Три слоя кэширования.
- Самый быстрый запрос - тот, которого не было. Как увеличить их количество.
- Экономия трафика.
- Исключение ненужных вычислений.
- Подходы к инвалидации кэша.
Приемы оптимизации работы с API на клиенте.
- Параллельные запросы.
- Эффективный разбор данных.
- In-memory DB на клиенте.
- Стратегии кэширования на клиенте.
Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Ма...
Это реальный рассказ об архитектуре Единой Фронтальной Системы (ЕФС) - системы, которая будет обслуживать абсолютно всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и т.д.). Это означает: десятки миллионов активных клиентов, 24х7, и еще пара NFR'ов, от которых порой вздрагиваешь по ночам :)
С одной стороны мы должны гарантировать 99.99% доступность, с другой стороны мы должны сокращать time-to-market для новых продуктов и быть готовыми обновлять ЕФС очень часто и по кусочкам – и это малая часть вызовов, с которыми нам приходиться сталкиваться.
В моем докладе я расскажу:
· Как мы гарантируем 99.99% доступности для всего ЕФС, включая хранилище (и особенно включая хранилище).
· Как мы масштабируемся на миллионы пользователей, оставаясь внешнее единой системой.
· Как мы реализуем zero downtime deployment, чтобы оставаться в 99.99% в условиях частых обновлений.
Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".
О чем доклад:
- Как в нашем проекте устроен Zabbix, применяемые нами способы автоматизации, собственные методы "дискавери" серверов и сервисов. Плюс как правильно держать Zabbix под высокой нагрузкой и не упираться в ресурсы серверов.
- Для чего мы используем Pinba, какие именно метрики помогают нам узнать о реальных проблемах пользователей.
- Как мы храним графики в RRD. Мониторинг этих графиков: User activity monitoring.
- Zabbix -> RRD => Capacity Planning.
Как быстро найти слабые места среди кластеров в десятки и сотни нод.
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
Zabbix в сервисной компании ОНЛАНТА - Zabbix Meetup Moscow
Презентация для Zabbix Moscow Meetup, June 27th 2015
http://www.meetup.com/Zabbix-Moscow-Meetup/events/223289028/
Настройка и оптимизация высоконагруженных J2EE веб-приложений / Шамим Ахмед (...
Оптимизация любого веб-приложения — это нетривиальная задача, для решения которой требуется проводить мониторинг загрузки системных ресурсов, выполнять микро-вэнчмаркинг, экспериментировать с настройками, проводить нагрузочное тестирование и т.д.
В текущем году нашей команде довелось поучаствовать в нескольких проектах, в которых перед нами стояла задача оптимизации J2EE веб-приложений. Один из них — портал для ОАО «Сбербанк России» (www.sberbank.ru).
Основной сайт Сбербанка реализован на основе портального движка BackBase и является J2EE-приложением. При проведении оптимизации его работы нам пришлось изучить и собрать много информации и документов, которые связаны с настройкой и оптимизацией высоконагруженных веб-приложений.
В ходе реализации проектов я заметил, что не существует сводного документа с инструкциями по оптимизации работы приложения, поэтому решил поделиться нашим опытом. Этот доклад может послужить в качестве дорожной карты (Road Map) для настройки и оптимизации J2EE веб-приложений.
В докладе будут рассмотрены следующие аспекты:
1) Общие подходы и методология оптимизации веб-приложения.
2) Оптимизация настроек веб-сервера.
3) Оптимизация кода приложения на стороне клиента.
4) Оптимизация на стороне middleware, в том числе на сервере приложений.
5) Оптимизация на уровне Базы Данных.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Балансировка нагрузки и отказоустойчивость в Одноклассниках
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...
В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.).
Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов:
- Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов?
- Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга?
- Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"?
Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Zabbix и правильное обнаружение проблем - Алексей Владышев @ RootConf 2015
Что такое Zabbix?
Как работает Zabbix?
Как правильно обнаруживать проблемы?
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...
HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
Переезжаем с Zabbix на Prometheus / Василий Озеров (fevlake)
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 11:00
Тезисы:
http://rootconf.ru/2017/abstracts/2507
- Почему prometheus?
- быстрый (golang)
- time series database
- простота развертывания через scm (ansible/chef/puppet/salt)
- готовые exports & dashboars for grafana
- Внедряем
- переносим базовый мониторинг систем в prometheus (cpu/disk/net/mem)
- настраиваем discovery новых хостов и сервисов
- подключаем визуализацию
- настраиваем алертинг
- Дополнительно
- резервируем prometheus (alertmanager + prometheus instance)
- получаем информацию из собственных приложений
- получаем статистику из логов
- Заключение
- возможности масштабирования
- какую нагрузку держим
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
HighLoad++ 2017
Зал «Калининград», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3010.html
В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта.
...
Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники)
В этом году мы перевели наш портал на HTTPS. Это оказалось непростой задачей. Основными проблемами явились рост нагрузки, увеличение Round Trip Times (RTT) и Mixed Content. Мы опробовали различные известные механизмы, призванные нивелировать эти проблемы, но, как оказалось на практике, все они скрывают в себе особенности. Эти особенности стоило знать заранее, но их не удалось почерпнуть из открытых источников.
В этом докладе мы хотим поделиться сложностями, с которыми мы столкнулись, а также тем, к каким выводам в итоге пришли. Надеемся, что набитые нами шишки будут полезны тем проектам, которые только планируют переход на HTTPS.
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Многие веб-студии не имеют в своем штате системных администраторов. И зачастую узнают о проблемах с запущенными проектами уже после того, как они случились.
В докладе рассмотрим:
- Явные и не очень потери на медленном / недоступном сайте.
- Общие принципы внедрения систем real-time мониторинга.
- Мониторинг нетипичных характеристик (наличие бэкапов, делегирование домена и т.п.).
- Автоматизацию типовых реакций на алерты.
- Зачем нужна аналитика в мониторинге (пробуем предугадать проблемы до того, как они случатся).
- Инструменты и общие подходы быстрого поиска "узких" мест.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Безопасность Node.js / Илья Вербицкий (Независимый консультант)
За последние годы мечты фантастов XX века стали реальностью: смартфоны, видеозвонки, виртуальная реальность и, наконец, Интернет вещей. К сожалению, у прогресса всегда есть темная сторона. Я думаю, ни для кого не секрет, что такие компании как Sony, Yahoo, Adobe, Target и многие другие столкнулись с проблемами безопасности в последние годы. Количество скомпрометированных систем растет день ото дня.
Node.js - это одна из самых быстрорастущих экосистем разработки приложений на рынке, которая постепенно перестает быть инструментом для разработки стартапов и проникает в корпоративный сектор. Вы уверены, что ваше приложение, разработанное на базе MEAN-стека, безопасно? В своем докладе я хотел бы рассмотреть данный вопрос. Мы поговорим о криптографии, аутентификации, авторизации, уязвимостях web-приложений, построенных на базе Node.js. К концу доклада вы получите пошаговое руководство, как уменьшить вероятность взлома вашего проекта.
Скорость с доставкой до пользователя / Анатолий Орлов (Self Employed), Денис ...
1. Многие коллективы разработчиков пытаются измерять скорость отклика сайта и пишут, например, “эта страничка сформирована за 300 ms”.
2. Проблема в том, что 300 ms — это "у нас на сервере". Пользователю, на самом деле, все равно, сколько это "у вас на сервере”, ему надо “сколько у меня в браузере”. В среднем по больнице, 300 ms на сервере с размером странички в 60-70 Кб, могут быть 2.5 секунды на клиенте.
3. Перед тем, как это лечить, надо это измерить. Есть 2 способа:
а. Navigation timing api, поддерживается сейчас много где, но не везде поддерживается одинаково, есть места, сложные для понимания и осмысления (тут много слайдов).
б. Можно взять tcpdump, в нем есть ACK ответов от клиентов, и измерять по ним. Есть Open Source soft (софт нап Насретдинов исан мной в Яндексе, есть договоренность его выпустить), который это делает. В tcpdump большой бонус в том, что можно понять, что происходит.
4. Что происходит в соединении, что такое rtt, как это влияет на latency. Как на это влияет cdn и вынесение всяких фронтендов ближе к пользователю.
5. Почему, вообще, бывает медленно, почему у пользователя может медленно работать wi-fi даже на широком и хорошем канале, уже не говоря про мобильный интернет.
6. Как влияют на скорость антивирусы и еще некоторая неведомая DPI херня (tm), которая делает так, что в советской России (а, возможно, во всем мире) https часто быстрее, чем http (и с чем, собственно, связано то, что на него куча компаний переходят).
Реализация восстановления после аварий / Сергей Бурладян (Avito)
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
More Related Content
What's hot
Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Ма...
Это реальный рассказ об архитектуре Единой Фронтальной Системы (ЕФС) - системы, которая будет обслуживать абсолютно всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и т.д.). Это означает: десятки миллионов активных клиентов, 24х7, и еще пара NFR'ов, от которых порой вздрагиваешь по ночам :)
С одной стороны мы должны гарантировать 99.99% доступность, с другой стороны мы должны сокращать time-to-market для новых продуктов и быть готовыми обновлять ЕФС очень часто и по кусочкам – и это малая часть вызовов, с которыми нам приходиться сталкиваться.
В моем докладе я расскажу:
· Как мы гарантируем 99.99% доступности для всего ЕФС, включая хранилище (и особенно включая хранилище).
· Как мы масштабируемся на миллионы пользователей, оставаясь внешнее единой системой.
· Как мы реализуем zero downtime deployment, чтобы оставаться в 99.99% в условиях частых обновлений.
Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".
О чем доклад:
- Как в нашем проекте устроен Zabbix, применяемые нами способы автоматизации, собственные методы "дискавери" серверов и сервисов. Плюс как правильно держать Zabbix под высокой нагрузкой и не упираться в ресурсы серверов.
- Для чего мы используем Pinba, какие именно метрики помогают нам узнать о реальных проблемах пользователей.
- Как мы храним графики в RRD. Мониторинг этих графиков: User activity monitoring.
- Zabbix -> RRD => Capacity Planning.
Как быстро найти слабые места среди кластеров в десятки и сотни нод.
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...
Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :)
Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов?
Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения.
Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.
Zabbix в сервисной компании ОНЛАНТА - Zabbix Meetup Moscow
Презентация для Zabbix Moscow Meetup, June 27th 2015
http://www.meetup.com/Zabbix-Moscow-Meetup/events/223289028/
Настройка и оптимизация высоконагруженных J2EE веб-приложений / Шамим Ахмед (...
Оптимизация любого веб-приложения — это нетривиальная задача, для решения которой требуется проводить мониторинг загрузки системных ресурсов, выполнять микро-вэнчмаркинг, экспериментировать с настройками, проводить нагрузочное тестирование и т.д.
В текущем году нашей команде довелось поучаствовать в нескольких проектах, в которых перед нами стояла задача оптимизации J2EE веб-приложений. Один из них — портал для ОАО «Сбербанк России» (www.sberbank.ru).
Основной сайт Сбербанка реализован на основе портального движка BackBase и является J2EE-приложением. При проведении оптимизации его работы нам пришлось изучить и собрать много информации и документов, которые связаны с настройкой и оптимизацией высоконагруженных веб-приложений.
В ходе реализации проектов я заметил, что не существует сводного документа с инструкциями по оптимизации работы приложения, поэтому решил поделиться нашим опытом. Этот доклад может послужить в качестве дорожной карты (Road Map) для настройки и оптимизации J2EE веб-приложений.
В докладе будут рассмотрены следующие аспекты:
1) Общие подходы и методология оптимизации веб-приложения.
2) Оптимизация настроек веб-сервера.
3) Оптимизация кода приложения на стороне клиента.
4) Оптимизация на стороне middleware, в том числе на сервере приложений.
5) Оптимизация на уровне Базы Данных.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Балансировка нагрузки и отказоустойчивость в Одноклассниках
Главная → Тезисы и презентации
Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование
Доклад принят в Программу конференции
Никита Духовный
Одноклассники
Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование.
Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала.
Тезисы
Проект Одноклассники начинал свою жизнь в одном датацентре.
С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы:
- Ни один, даже самый мощный, сервер больше не справляется в одиночку.
- Нагрузка растёт, а в датацентре нет места для нового оборудования.
- Падение датацентра безоговорочно приводит к даунтайму.
- Сетевой сбой выводит портал из строя.
- Пользователи в удалённых регионах страдают от низкой скорости.
Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем:
- CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях.
- Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними.
- Сеть - как и до чего мы балансируем трафик.
- Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик.
- Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...
В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.).
Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов:
- Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов?
- Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга?
- Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"?
Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...
В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться.
Микросервисы.
Зачем они вообще:
- В простых сервисах легче разбираться и локализовывать проблемы.
- В микросервисной архитектуре проще добиваться отказоустойчивости.
- Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее.
- Независимое обновление компонентов.
- Тестирование частей системы.
Как:
- Docker-образы как основа.
- Rancher как система деплоя и оркестрации Docker-контейнеров. High availability.
- Простота сервиса - ключевой момент.
== Критерий: Разработчик должен иметь возможность быстро понять и переписать сервис при необходимости.
== Забавное следствие: такие сервисы пишутся не на века, а под текущие требования. Получается быстро и agile-но, ведь изменения легко сможет внести любой разработчик.
== PEP8.
- HTTP API и поддержка Swagger. Резко упрощают тестирование.
- RabbitMQ pipelines как отказоустойчивая система взаимодействий между сервисами:
== DLX помогает разбираться со врЕменными проблемами.
== HTTP RPC.
- Метрики, метрики и ещё раз метрики.
== service status API.
== Graphite, Zabbix. Может, к ноябрю еще OKmeter успеем попробовать.
- Структурированые логи: JSON stdout => Fluentd => ELK => счастье. Локализация багов и пр. Об этом подробнее в отдельной презентации.
- В любой непонятной ситуации...
== Сервис должен падать, а не зависать.
== Healthchecks.
- Стабильность архитектуры.
== Осознанная деградация! Любой сервис должен быть готов к падению другого. При этом в первом должно быть явно описано, как будет при этом ограничиваться его функциональность. Это ведет к отсутствию эффекта домино, когда один малозначащий сервис, упав, утягивает за собой всю систему.
- Документация.
== Степень критичности каждого сервиса.
== Краткий обзор функциональности (вспоминаем: сервисы _простые_).
== Конфиги.
== drawback: описание архитектуры обязано быть актуальным и полным, иначе беда.
Трудности: Допишу через пару дней.
Zabbix и правильное обнаружение проблем - Алексей Владышев @ RootConf 2015
Что такое Zabbix?
Как работает Zabbix?
Как правильно обнаруживать проблемы?
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...
HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
Переезжаем с Zabbix на Prometheus / Василий Озеров (fevlake)
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 6 июня, 11:00
Тезисы:
http://rootconf.ru/2017/abstracts/2507
- Почему prometheus?
- быстрый (golang)
- time series database
- простота развертывания через scm (ansible/chef/puppet/salt)
- готовые exports & dashboars for grafana
- Внедряем
- переносим базовый мониторинг систем в prometheus (cpu/disk/net/mem)
- настраиваем discovery новых хостов и сервисов
- подключаем визуализацию
- настраиваем алертинг
- Дополнительно
- резервируем prometheus (alertmanager + prometheus instance)
- получаем информацию из собственных приложений
- получаем статистику из логов
- Заключение
- возможности масштабирования
- какую нагрузку держим
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
HighLoad++ 2017
Зал «Калининград», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3010.html
В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта.
...
Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники)
В этом году мы перевели наш портал на HTTPS. Это оказалось непростой задачей. Основными проблемами явились рост нагрузки, увеличение Round Trip Times (RTT) и Mixed Content. Мы опробовали различные известные механизмы, призванные нивелировать эти проблемы, но, как оказалось на практике, все они скрывают в себе особенности. Эти особенности стоило знать заранее, но их не удалось почерпнуть из открытых источников.
В этом докладе мы хотим поделиться сложностями, с которыми мы столкнулись, а также тем, к каким выводам в итоге пришли. Надеемся, что набитые нами шишки будут полезны тем проектам, которые только планируют переход на HTTPS.
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Многие веб-студии не имеют в своем штате системных администраторов. И зачастую узнают о проблемах с запущенными проектами уже после того, как они случились.
В докладе рассмотрим:
- Явные и не очень потери на медленном / недоступном сайте.
- Общие принципы внедрения систем real-time мониторинга.
- Мониторинг нетипичных характеристик (наличие бэкапов, делегирование домена и т.п.).
- Автоматизацию типовых реакций на алерты.
- Зачем нужна аналитика в мониторинге (пробуем предугадать проблемы до того, как они случатся).
- Инструменты и общие подходы быстрого поиска "узких" мест.
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...
Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов.
Мы расскажем:
1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин;
2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows;
3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.
Безопасность Node.js / Илья Вербицкий (Независимый консультант)
За последние годы мечты фантастов XX века стали реальностью: смартфоны, видеозвонки, виртуальная реальность и, наконец, Интернет вещей. К сожалению, у прогресса всегда есть темная сторона. Я думаю, ни для кого не секрет, что такие компании как Sony, Yahoo, Adobe, Target и многие другие столкнулись с проблемами безопасности в последние годы. Количество скомпрометированных систем растет день ото дня.
Node.js - это одна из самых быстрорастущих экосистем разработки приложений на рынке, которая постепенно перестает быть инструментом для разработки стартапов и проникает в корпоративный сектор. Вы уверены, что ваше приложение, разработанное на базе MEAN-стека, безопасно? В своем докладе я хотел бы рассмотреть данный вопрос. Мы поговорим о криптографии, аутентификации, авторизации, уязвимостях web-приложений, построенных на базе Node.js. К концу доклада вы получите пошаговое руководство, как уменьшить вероятность взлома вашего проекта.
What's hot (20)
Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Ма...
Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Ма...
Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".
Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...
Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...
Zabbix в сервисной компании ОНЛАНТА - Zabbix Meetup Moscow
Zabbix в сервисной компании ОНЛАНТА - Zabbix Meetup Moscow
Настройка и оптимизация высоконагруженных J2EE веб-приложений / Шамим Ахмед (...
Настройка и оптимизация высоконагруженных J2EE веб-приложений / Шамим Ахмед (...
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...
Балансировка нагрузки и отказоустойчивость в Одноклассниках
Балансировка нагрузки и отказоустойчивость в Одноклассниках
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...
Стратегия и тактика улучшения производительности BSS систем оператора мобильн...
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...
Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...
Zabbix и правильное обнаружение проблем - Алексей Владышев @ RootConf 2015
Zabbix и правильное обнаружение проблем - Алексей Владышев @ RootConf 2015
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...
Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...
Переезжаем с Zabbix на Prometheus / Василий Озеров (fevlake)
Переезжаем с Zabbix на Prometheus / Василий Озеров (fevlake)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники)
Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники)
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...
Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...
Безопасность Node.js / Илья Вербицкий (Независимый консультант)
Безопасность Node.js / Илья Вербицкий (Независимый консультант)
Viewers also liked
Скорость с доставкой до пользователя / Анатолий Орлов (Self Employed), Денис ...
1. Многие коллективы разработчиков пытаются измерять скорость отклика сайта и пишут, например, “эта страничка сформирована за 300 ms”.
2. Проблема в том, что 300 ms — это "у нас на сервере". Пользователю, на самом деле, все равно, сколько это "у вас на сервере”, ему надо “сколько у меня в браузере”. В среднем по больнице, 300 ms на сервере с размером странички в 60-70 Кб, могут быть 2.5 секунды на клиенте.
3. Перед тем, как это лечить, надо это измерить. Есть 2 способа:
а. Navigation timing api, поддерживается сейчас много где, но не везде поддерживается одинаково, есть места, сложные для понимания и осмысления (тут много слайдов).
б. Можно взять tcpdump, в нем есть ACK ответов от клиентов, и измерять по ним. Есть Open Source soft (софт нап Насретдинов исан мной в Яндексе, есть договоренность его выпустить), который это делает. В tcpdump большой бонус в том, что можно понять, что происходит.
4. Что происходит в соединении, что такое rtt, как это влияет на latency. Как на это влияет cdn и вынесение всяких фронтендов ближе к пользователю.
5. Почему, вообще, бывает медленно, почему у пользователя может медленно работать wi-fi даже на широком и хорошем канале, уже не говоря про мобильный интернет.
6. Как влияют на скорость антивирусы и еще некоторая неведомая DPI херня (tm), которая делает так, что в советской России (а, возможно, во всем мире) https часто быстрее, чем http (и с чем, собственно, связано то, что на него куча компаний переходят).
Реализация восстановления после аварий / Сергей Бурладян (Avito)
Базы данных PostgreSQL занимают одно из центральных мест в Авито. Они являются разделяемой платформой, вокруг которой построено множество дополнительных сервисов. Одной из основных задач при их администрировании является задача восстановления после аварий как самих баз, так и связанной с ними инфраструктуры.
В своём докладе я постараюсь рассказать про:
+ общую схему связей баз данных между собой и с другими компонентами;
+ точки отказа и виды аварий, затрагиваемые связи;
+ бинарную репликацию и архив;
+ логическую репликацию, pgq, londiste, UNDO (REDO), пересоздание репки;
+ скрипт и процедуру переключения при аварии;
+ планы: развитие «восстановлений» по всем связям, автоматика на основе системы zookeeper (etcd и т.п.).
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
Near-realtime аналитика событий в высоконагруженном проекте / Александр Краше...
Типовой задачей аналитики для любого проекта является получение ответов на вопросы: "сколько у нас регистраций за последний день?", "сколько сообщений было отправлено (товаров добавлено в корзину и пр.) в стране N, мужчинами/женщинами из приложения/сайта?". Поиском ответов на эти вопросы в компании обычно занимается отдел BI.
Инструментарием могут служить различные технологии: файлы Excel, старые-добрые РСУБД (MySQL, PosgtreSQL, MS SQL, Oracle etc.), специализированные аналитические базы данных (Vertica, Exasol, etc.), вычисления на Hadoop-кластере. Естественно, любое решение обладает своими достоинствами и недостатками — что-то ограничено по объему обрабатываемой информации, что-то — по скорости, что-то — по realtime.
Перед нами стояла задача сделать систему аналитики:
+ Горизонтально масштабируемой — уже не хватает ресурсов SQL.
+ Близкой к реальному времени — аналитические базы и Hadoop не дают нам желаемого эффекта.
+ Легкой в конфигурировании — любой новый отчет требует минимума затрат от разработчика.
Мы можем рассказать о том, как мы построили систему, которая прямо сейчас обрабатывает 200к событий в секунду, строит 12М метрик и может еще расти и расти.
Под капотом: Apache Spark для near-realtime обработки событий, Hadoop — как фундамент для масштабирования.
Эволюция клиентской разработки от веба ко всеобщей мобилизации или mobile-fir...
История развития проекта с точки зрения клиентских технологий — от веб-сайта к появлению мобильных клиентов и смещению фокуса к mobile-first разработке. Общие черты нашей архитектуры и их отличия от стандартных решений.
Единый протокол общения с приложениями iOS/Android/WindowsMobile/MobileWeb/Web и особенности реализации для JavaScript платформ (десктопные и мобильные браузеры).
Изменение процесса разработки и подходов к реализации нового функционала для переключения на mobile-first стратегию.
Ускоряем исследования с помощью конкурсов как их готовить и выигрывать / Иван...
Мы в Авито часто сталкиваемся с ситуацией, когда нужно быстро придумать алгоритм, решающий некоторую бизнес задачу на основе анализа больших объёмов данных. Придумать какой-то алгоритм не сложно, но каждый раз возникает вопрос — а вдруг можно решить эту же задачу в разы более качественно. Исследования можно вести годами, но это рискованно — лучшего решения может и не быть, и будет затрачено много времени.
На помощь приходят конкурсы по анализу данных. Мы устраивали конкурсы на построение алгоритмов, работающих с совершенно различными типами и объемами данных:
+ Выявление запрещенных объявлений.
+ Прогнозирование вероятности клика на рекламное объявление.
+ Обнаружение телефонов на изображениях.
+ Прогнозирование инкрементального эффекта от скидочных акций.
Какие-то были более удачными, какие-то — менее. Расскажем про основные этапы подготовки задач к конкурсу, а также про основные трюки, используемые для победы в таких конкурсах
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)
Некоторое время назад, когда в очередной раз встал вопрос о производительности большого парка mysql sharding серверов, мы не захотели покупать новые сервера и производить resharding. Мы обнаружили, что компания facebook выпустила в opensource большое количество своих разработок, в том числе и модуль ядра flashcache.
Flashcache — модуль для кэширования блоков блочного устройства, предоставляющий 4 разных режима кэширования.
В данном докладе я расскажу, как мы тестировали, поэтапно проверяя под нагрузкой, 3 из 4 режимов кэширования, сравнивая и выбирая оптимальный. Итогом данной работы стало внедрение данного модуля в нашу архитектуру (фотосервера, сервера БД).
Производительность WebGL-приложений / Дмитренко Кирилл (Яндекс)
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Где живут Ваши объявления / Тюрин Михаил (Avito)
Авито с 2010 года — с момента запуска на широкую аудиторию — прошел уже немалый путь, успев собрать более 600 миллионов объявлений со всех уголков страны, и став при этом крупнейшим классифайдом в Европе.
В докладе будет дан обзор архитектуры ядра системы с ретроспективой, перечислены основные компоненты обработки объявлений, приведены оценки параметров функционирования от "продуктовых" "количество объявлений за единицу времени" до количества запросов на разные уровни стека (веб, базы, поиск, очереди) и степени утилизации железа.
Будут также продемонстрированы примеры реализаций классических паттернов веба: кэш, прокси, денормализация и репликация, шардинг, очереди и удаленный вызов процедур — подходы, уже более 5 лет лежащие в основе нашей архитектуры. При этом будут приведены неочевидные, на взгляд автора, особенности внедрения данных подходов.
Доклад должен заинтересовать соотнесением масштабов и ключевых слов.
Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)
В этом докладе мы поделимся опытом, полученным в ходе масштабного проекта по миграции Avito между дата-центрами: как мы осуществляли планирование, подготовку и непосредственно переезд с переключением площадки.
Опишу общие особенности и специфику нашей миграции, "подводные камни" и неочевидные ограничения, с которыми приходилось справляться, в том числе, и в экстремальных условиях.
SmartMonitoring - мониторинг бизнес-логики в Одноклассниках / Сергей Шарапов ...
Самым критичным в мониторинге бизнес-логики является этап выяснения сути инцидента, зачастую он занимает значительное время и требует высокой квалификации сотрудника, так как основные показатели работы сайта и сервисов представлены более чем 100 тысячами графиков, и нахождение первоисточника - не самое простое дело. Поэтому была создана система мониторинга (SmartMonitoring), которая умеет находить аномалии в работе портала и показывать связь между ними, что значительно упрощает работу как администраторам, так и программистам. Такая система помогает в случае инцидента понять, какой именно среди десятков наших сервисов засбоил первым и, соответственно, ускоряет распутывание «клубка» в процессе расследования инцидента и помогает быстро находить сервис, который во всем виноват.
В этом докладе я расскажу, как мы создали такую систему, как она работает, и с какими трудностями мы столкнулись.
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...
На примере нашей системы хранения фотографий мы хотим рассказать о проблемах, с которыми столкнулись в течение прошедших семи лет, связанных с ее программными и аппаратными компонентами, и о путях их решений.
В данном докладе речь пойдет о том, как сохранить независимость от поставщика и построить масштабируемую систему хранения с длительным сроком эксплуатации и способностью к оперативному внесению изменений в конфигурацию. Как сделать изменения на аппаратном уровне прозрачными для разработчиков, а также о том, как упростить развертывание и обслуживание.
В общих чертах изложен опыт и проблемы, которые мы получили в ходе эксплуатации классических мультиконтроллерных СХД. Основная тема - построение собственных хранилищ на базе общедоступных компонентов (полки, адаптеры, экспандеры, интерпозеры, диски, ЦПУ и т.д.) с потенциальной возможностью замены любого из выше перечисленного на другую модель. Дублирование критически важных узлов в рамках одной СХД. Обзор используемых транспортов - SRP, FC, iSCSI и описание того, каким образом можно быстро адаптировать такое хранилище под один или несколько транспортов, с минимальными вложениями. Обзор ПО для реализации СХД (SCST/LIO или проприетарные решения в области Software Defined Storage ). Автоматизация развертывания (инсталляция/управление с помощью Puppet). Тестирование перед вводом в эксплуатацию. Multipath I/O и упрощение именования экспортируемых блочных устройств. Политика составления наборов firmware для стабильной работы. Мониторинг. Расследование сбоев (Order of failure и т.п.).
Как мы сделали ровную балансировку нагрузки на фронтенд-кластере / Насретдино...
В докладе я расскажу о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe.
Тезисы - http://www.highload.ru/2015/abstracts/1950.html
Управление производительностью на базе HP Performance Center. Опыт Альфа-банк...
Альфа-Банк основан в 1990 году, является универсальным банком, осуществляющим все основные виды банковских операций, включая обслуживание частных и корпоративных клиентов, инвестиционный банковский бизнес. Одним из основных принципов стратегии развития Альфа-Банка является привлечение и удержание клиентов за счет предоставления финансовых услуг высочайшего качества и комфортности. В соответствии с этой бизнес-стратегией существует значительный внутренний запрос на высокопроизводительные гибкие ИТ-решения для бизнеса и процесс контроля и управления производительностью этих ИТ-решений. Мы называем этот процесс процессом управления мощностями (capacity management или performance management).
Тезисы - http://www.highload.ru/2015/abstracts/1968.html
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Как мы готовим MySQL / Николай Королёв (Badoo)
* Исторический экскурс, введение понятия спота, принцип функционального деления баз на группы (споты / не споты), шардирование как способ масштабирования спотов.
* Возникновение второго датацентра на другом континенте, создание самодельной репликации, позволяющей работать по схеме много -> много, краткая схема (структура спотов, схема репликации, служебные базы - очереди, репликация, мониторинг), плюсы и минусы этого решения, инструменты диагностики.
* Альтеры шадрированых спотов - первый вариант утилиты для этой задачи: схема его работы и возникшие проблемы; вторая версия утилиты - улучшения, а также, что осталось неисправленным.
* “Температура” спота, трудности её определения, проблемы, возникающие из-за его “перегрева”, наш способ решения и возникновение проекта “кладбище”.
* Деплой и около - почему мы используем MySQL в chroot, как мы его собираем и как деплоим.
* Бэкапы спотовых данных - первоначальное решение (ленточные хранилища), работа над ошибками, текущая схема.
* Query sampling: проект Minba.
Viewers also liked (16)
Скорость с доставкой до пользователя / Анатолий Орлов (Self Employed), Денис ...
Скорость с доставкой до пользователя / Анатолий Орлов (Self Employed), Денис ...
Реализация восстановления после аварий / Сергей Бурладян (Avito)
Реализация восстановления после аварий / Сергей Бурладян (Avito)
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...
Near-realtime аналитика событий в высоконагруженном проекте / Александр Краше...
Near-realtime аналитика событий в высоконагруженном проекте / Александр Краше...
Эволюция клиентской разработки от веба ко всеобщей мобилизации или mobile-fir...
Эволюция клиентской разработки от веба ко всеобщей мобилизации или mobile-fir...
Ускоряем исследования с помощью конкурсов как их готовить и выигрывать / Иван...
Ускоряем исследования с помощью конкурсов как их готовить и выигрывать / Иван...
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)
Flashcache в mamba.ru / Яковлев Александр Юрьевич (ЗАО Мамба)
Производительность WebGL-приложений / Дмитренко Кирилл (Яндекс)
Производительность WebGL-приложений / Дмитренко Кирилл (Яндекс)
Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)
Опыт миграции между дата-центрами / Михаил Тюрин, Сергей Бурладян (Avito)
SmartMonitoring - мониторинг бизнес-логики в Одноклассниках / Сергей Шарапов ...
SmartMonitoring - мониторинг бизнес-логики в Одноклассниках / Сергей Шарапов ...
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...
Эволюция программно-аппаратного обеспечения хранения фотографий в Badoo / Дми...
Как мы сделали ровную балансировку нагрузки на фронтенд-кластере / Насретдино...
Как мы сделали ровную балансировку нагрузки на фронтенд-кластере / Насретдино...
Управление производительностью на базе HP Performance Center. Опыт Альфа-банк...
Управление производительностью на базе HP Performance Center. Опыт Альфа-банк...
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)
Similar to Ускорение показа превью изображений в Яндекс.Диске / Сергей Нечаев (Яндекс)
HappyDev-lite-2016-весна 02 Дмитрий Пашкевич. Нетривиальный веб
Веб-приложения бывают разные: от сайтов-визиток небольших компаний или персональных блогов, до известных социальных сетей и популярных интернет-магазинов, обслуживающих миллионы пользователей по всему миру. Как устроены сложные веб-приложения «под капотом», за счет чего они выдерживают высокие нагрузки и как строится взаимодействие пользователя с такими нетривиальными веб-приложениеми, мы рассмотрим в докладе.
Скорость работы интернет-магазина
Доклад о влиянии скорости загрузки страниц на конверсию интернет-магазина. Информация об исследовании основных факторов, влияющих на время отображения страниц. Советы по ускорению сайтов.
РИФ+КИБ 2014 [Севальнев] - Плюсы и подводные камни для SEO при использовании CDN
= План доклада =
1. Факторы ранжирования поисковых систем, учитывающие скорость загрузки сайта:
- Время отклика сервера и загрузки страницы.
- Внутрихостовые поведенческие факторы.
- Конверсия в e-commerce сегменте.
- Кейсы реальных сайтов.
2. Избегаем подводных камней для SEO:
- Вертикальные поиски.
- Трафик в поиске по картинкам / видео и CDN.
- Дубли страниц, использование атрибута rel="canonical".
- Панель Вебмастера.
NoBigData - потоковая система аналитики clientside производительности, Сергей...
Доклад Сергея Рыжикова и Александра Сербула на HighLoad++ 2014.
Быстродействие веб сайта. Методичный анализ и глубины клиентской оптимизации
Что влияет на производительность. Средства анализа показателей. Правильно определяем цели и задачи. Глубины клиентской оптимизации.
WebCamp: Developer Day: Быстродействие веб-сайта. Методичный анализ и глубины...
Быстродействие веб-сайта. Методичный анализ и глубины клиентской оптимизации.
Евгений Котельницкий
Что влияет на производительность; средства анализа показателей; правильно определяем цели и задачи; глубины клиентской оптимизации; анализ нескольких сайтов, которые назовёт аудитория.
Highload++ 2016: Автоматизация тестирования клиентской производительности (Ла...
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
Здесь есть два принципиальных направления: синтетические тесты в тестовом окружении и сбор метрик у реальных пользователей. Оба этих направления важны, но мы сконцентрируемся на синтетических тестах и будем использовать их для оценки влияния изменений в приложении на клиентскую производительность как часть процесса тестирования.
Автоматизация тестирования клиентской производительности / Николай Лавлинский...
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
В этих условиях требуется автоматизированный процесс тестирования скорости клиентской части приложения. При этом тестировать нужно в настоящих браузерах, в максимально похожем на реальность окружении.
В этом докладе будем говорить о том, как совместить все эти требования и не потратить много месяцев на построение собственного "велосипеда". Предлагается рабочее решение задачи с использованием open source решения WebPagetest Private Instance. Рассмотрим основные достоинства и проблемы решения, а также способы использования этого инструмента.
Автоматизация тестирования клиентской производительности - Лавлинский Николай...
Доклад на Highload++ 2016. Как автоматизировать тестирование скорости сайта. Мы будем использовать Webpagetest PI через API для построения сервиса по тестированию скорости сайтов: ускорениесайтов.рф.
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Анастасия Кугач, Рексофт
Инструментарий для создания дистрибутивов продуктов | Владимир Селин
1. Что такое дистрибутив большого продукта?
2. Проблема: знаниями о процессе установки продукта владеет малое число людей.
3. Шаблоны + DSL - решение всех проблем!
SQL Server 2012 Deep Dive (rus)
Talk is called Deep Dive, so be prepared to hold your breath. In this talk we will take a look at the mechanisms of the SQL Server and literally dive into the bowels of SQL Server, going through all the stages of the request processing.
My Open Source (Sept 2017)
Доклад на Hacktoberfest 2017 в Avito.
Про некоторые мои проекты и несколько жизненных выводов.
Project under control
Slides from my presentation on PhpDevby (June 2012, Minsk) and DevConf (June 2012, Moscow)
So Your WAF Needs a Parser
Slides from our talk on HighLoad2017 conference about possible performance problems and caveats of usage parsers in high load applications.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Similar to Ускорение показа превью изображений в Яндекс.Диске / Сергей Нечаев (Яндекс) (20)
HappyDev-lite-2016-весна 02 Дмитрий Пашкевич. Нетривиальный веб
HappyDev-lite-2016-весна 02 Дмитрий Пашкевич. Нетривиальный веб
РИФ+КИБ 2014 [Севальнев] - Плюсы и подводные камни для SEO при использовании CDN
РИФ+КИБ 2014 [Севальнев] - Плюсы и подводные камни для SEO при использовании CDN
NoBigData - потоковая система аналитики clientside производительности, Сергей...
NoBigData - потоковая система аналитики clientside производительности, Сергей...
Быстродействие веб сайта. Методичный анализ и глубины клиентской оптимизации
Быстродействие веб сайта. Методичный анализ и глубины клиентской оптимизации
WebCamp: Developer Day: Быстродействие веб-сайта. Методичный анализ и глубины...
WebCamp: Developer Day: Быстродействие веб-сайта. Методичный анализ и глубины...
Highload++ 2016: Автоматизация тестирования клиентской производительности (Ла...
Highload++ 2016: Автоматизация тестирования клиентской производительности (Ла...
Автоматизация тестирования клиентской производительности / Николай Лавлинский...
Автоматизация тестирования клиентской производительности / Николай Лавлинский...
Автоматизация тестирования клиентской производительности - Лавлинский Николай...
Автоматизация тестирования клиентской производительности - Лавлинский Николай...
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...
полмиллиона юзеров в онлайне без падений оптимизация высоконагруженной Server...
полмиллиона юзеров в онлайне без падений оптимизация высоконагруженной Server...
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Инструментарий для создания дистрибутивов продуктов | Владимир Селин
Инструментарий для создания дистрибутивов продуктов | Владимир Селин
полмиллиона юзеров в онлайне без падений оптимизация высоконагруженной Server...
полмиллиона юзеров в онлайне без падений оптимизация высоконагруженной Server...
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн
More from Ontico
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
HighLoad++ 2017
Зал «Калининград», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3032.html
Протокол DNS на семь лет старше, чем Всемирная паутина. Стандарты RFC 882 и 883, определяющие основную функциональность системы доменных имён, появились в конце 1983 года, а первая реализация последовала уже годом позже. Естественно, что у технологии столь старой и при этом по сей день активнейшим образом используемой просто не могли не накопиться особенности, неочевидные обыкновенным пользователям.
...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3096.html
PostgreSQL is the world’s most advanced open source database. Indeed! With around 270 configuration parameters in postgresql.conf, plus all the knobs in pg_hba.conf, it is definitely ADVANCED!
How many parameters do you tune? 1? 8? 32? Anyone ever tuned more than 64?
No tuning means below par performance. But how to start? Which parameters to tune? What are the appropriate values? Is there a tool --not just an editor like vim or emacs-- to help users manage the 700-line postgresql.conf file?
Join this talk to understand the performance advantages of appropriately tuning your postgresql.conf file, showcase a new free tool to make PostgreSQL configuration possible for HUMANS, and learn the best practices for tuning several relevant postgresql.conf parameters.
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3115.html
During this session we will cover the last development in ProxySQL to support regular expressions (RE2 and PCRE) and how we can use this strong technique in correlation with ProxySQL's query rules to anonymize live data quickly and transparently. We will explain the mechanism and how to generate these rules quickly. We show live demo with all challenges we got from the Community and we finish the session by an interactive brainstorm testing queries from the audience.
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3114.html
ProxySQL aims to be the most powerful proxy in the MySQL ecosystem. It is protocol-aware and able to provide high availability (HA) and high performance with no changes in the application, using several built-in features and integration with clustering software. During this session we will quickly introduce its main features, so to better understand how it works. We will then describe multiple use case scenarios in which ProxySQL empowers large MySQL installations to provide HA with zero downtime, read/write split, query rewrite, sharding, query caching, and multiplexing using SSL across data centers.
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2954.html
MySQL Replication is powerful and has added a lot of advanced features through the years. In this presentation we will look into replication technology in MySQL 5.7 and variants focusing on advanced features, what do they mean, when to use them and when not, Including.
When should you use STATEMENT, ROW or MIXED binary log format?
What is GTID in MySQL and MariaDB and why do you want to use them?
What is semi-sync replication and how is it different from lossless semi-sync?
...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3120.html
Количество разработчиков мобильных приложений Сбербанк Онлайн с начала 2016 года выросло на порядок. Для того чтобы продолжать выпускать качественный продукт, мы кардинально перестраиваем процесс разработки.
Количество внутренних заказчиков тех или иных доработок в какой-то момент выросло настолько, что разработчики стали узким местом. Мы внедрили культуру разработки, которую можно условно назвать "внутренним open-source", сохранив за собой контроль над архитектурой и качеством проекта, но позволив разрабатывать новые фичи всем желающим.
...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2836.html
При использовании Eventually Consistent распределенных баз данных нет гарантий, что чтение возвращает результаты последних изменений данных, если чтение и запись производятся на разных узлах. Это ограничивает пропускную способность системы. Поддержка свойства Causal Consistency снимает это ограничение, что позволяет улучшить масштабируемость, не требуя изменений в коде приложения.
...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2858.html
Аудитория Одноклассников превышает 73 миллиона человек в России, СНГ и странах дальнего зарубежья. При этом ОК.ru - первая социальная сеть по просмотрам видео в рунете и крупнейшая сервисная платформа.
Качественный и количественный рост DDoS-атак за последние годы превращает их в одну из первоочередных проблем для крупнейших интернет-ресурсов. В зависимости от вектора атаки “узким” местом становится та или иная часть инфраструктуры. В частности, при SYN-flood первый удар приходится на систему балансировки трафика. От ее производительности зависит успех в противостоянии атаке.
...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/3008.html
Никогда не было и вот снова случилось! Компания Google в результате перенаправления трафика сделала недостпуными в Японии несколько тысяч различных сервисов, большинство из которых никак не связано с самой компанией Google. Однако, подобные инциденты происходят с завидной регулярностью, вот только не всегда попадают в большие СМИ. У таких инцидентов могут быть разные причины, начиная от ошибок сетевых инженеров и заканчивая государственным регулированием.
...
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2925.html
Облака и виртуализация – современные тренды развития IT-технологий. Операторы связи строят свои TelcoClouds на стандартах NFV (Network Functions Virtualization) и SDN (Software-Defined Networking). В докладе начнем с основ виртуализации, далее разберемся, для чего используются NFV и SDN, потом полетим к облакам и вернемся на землю для решения практических задач!
...
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/3045.html
Как мы заставили Druid работать в Одноклассниках.
«Druid is a high-performance, column-oriented, distributed data store» http://druid.io.
Мы расскажем о том, как, внедрив Druid, мы справились с ситуацией, когда MSSQL-based система статистики на 50 терабайт стала:
- медленной: средняя скорость ответа была в разы меньше требуемой (и увеличилась в 20 раз);
- нестабильной: в час пик статистика отставала до получаса (теперь ничего не отстает);
- дорогой: изменилась политика лицензирования Microsoft, расходы на лицензии могли составить миллионы долларов.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2913.html
Изначально будут раскрыты базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует.
Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны.
...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2947.html
Apache Ignite — Open Source платформа для высокопроизводительной распределенной работы с большими данными с применением SQL или Java/.NET/C++ API. Ignite используют в самых разных отраслях. Сбербанк, ING, RingCentral, Microsoft, e-Therapeutics — все эти компании применяют решения на основе Ignite. Размеры кластеров разнятся от всего одного узла до нескольких сотен, узлы могут быть расположены в одном ЦОД-е или в нескольких геораспределенных.
...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
Как мы учились чинить самолеты в воздухе / Евгений Коломеец (Virtuozzo)
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2975.html
Все мы слышали про изменение кода ядра Linux на лету (kernel live patching). Но кто-нибудь проводит подобные фокусы в user space? Оказалось, что да. Мы тоже попробовали.
И получилось.
Длинная дорога технологии Userspace Live Patching в жизнь:
Что такое Live Patching
1) Изменение части логики процесса.
2) Сохранение состояния процесса.
3) Делать 1+2 БЕЗОПАСНО.
...
Java и Linux — особенности эксплуатации / Алексей Рагозин (Дойче Банк)
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/2884.html
Java на Linux встречается повсеместно в информационных системах от больших данных до новомодных serverless архитектур. Как Linux, так и Java имеют свои эксплуатационные нюансы. Понимание этих нюансов важно, чтобы заставить стек Java + Linux работать стабильно и эффективно.
Но на практике "джависты" очень любят мыслить кроссплатформенно и не хотят разбираться с особенностями операционной системы, a "линускоиды" считают JVM чуждым миру Linux процессом, пожирающим всю доступную на сервере память.
А потом появляется Docker, и нюансов становится ещё больше...
Цель доклада - рассказать "джавистам" про Linux и Docker, а "линуксоидам" про JVM.
More from Ontico (20)
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Как мы учились чинить самолеты в воздухе / Евгений Коломеец (Virtuozzo)
Как мы учились чинить самолеты в воздухе / Евгений Коломеец (Virtuozzo)
Java и Linux — особенности эксплуатации / Алексей Рагозин (Дойче Банк)
Java и Linux — особенности эксплуатации / Алексей Рагозин (Дойче Банк)
Ускорение показа превью изображений в Яндекс.Диске / Сергей Нечаев (Яндекс)
- 3. Что может быть хуже?
- 6. Файлов в сутки 25.5M 15.2M 47.2M загружается всего загружается изображений запросов превью
- 7. Статические превью + Нет расходов на генерацию
- 9. Стадии загрузки и показа DNS+TCP SSL request response delay before showdelay before request
- 10. Оптимизации • Задержки на клиенте • Генерация превью • Доставка Что из этого вносит наибольший вклад в общее время?
- 11. Измерения на клиенте Запрос списка Рендеринг сетки Загрузка всех картинок в порции Фотоньки Фотоньки Фотоньки
- 12. Измерения на клиенте – 2 Для отдельной картинки – время установки ssl соединения – время собственно загрузки Resource Timing API* * Помним о Timing-Allow-Origin
- 13. Время показа превью Запрос листинга Получение порции превью Рендеринг сетки
- 14. До: время показа порции 3,200 мс 800 мс 200 мс Время Рендер Листинг Загрузка порции
- 15. Генерация превью • Проверка валидности ссылки • Проверка доступов • Получение большого превью из хранилища • Собственно генерация
- 16. Генерация превью • Было: • Генерация на машинах, обрабатывающих добавляемые файлы • Кэш в рамках одной машины • Стало: • Отдельный кластер для генерации • Кэш в рамках ДЦ
- 17. Время на сервере
- 18. Время для пользователя Запрос листинга Получение порции превью Рендеринг сетки
- 19. Оптимизация доставки Уменьшить размер: jpeg quality 95% 92% 124КB 62KB
- 20. SPDY Внедрили
- 21. SPDY для >24 картинок 1.5 2.6 3.7 8.0 1.5 2.3 3.2 6.8 25% 50% 75% 95% Время отдачи порции в секундах
- 23. Предзапросы превью Сгенерируй превью Отдай превью Клиент Сервер
- 24. Склеивать картинки Дай пачку превью Клиент Сервер
- 25. Качество по запросу Дай превью Клиент Сервер Дай превью получше
- 26. До и после 3,200 мс 1,800 мс 800 мс 1,230 мс 200 мс 220 мс До После РендерЛистинг Загрузка порции
- 27. Выводы и рекомендации • Перед началом оптимизации необходимо получить полную картину • Разные сервисы нужно изолировать по ресурсам • Для SPDY нужна служба поддержки :) • После каждой оптимизации нужно заново профилировать
- 28. Сергей Нечаев Менеджер технических проектов Яндекс.Диска @spnechaev