Ускорение показа превью изображений в Яндекс.Диске / Сергей Нечаев (Яндекс)

•Als PPTX, PDF herunterladen•

0 gefällt mir•1,057 views

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

Ingenieurwesen

Ускорение генерации
превью в
Яндекс.Диске
Сергей Нечаев

Файлов в сутки
25.5M
15.2M
47.2M
загружается всего
загружается изображений
запросов превью

Статические превью
+ Нет расходов
на генерацию

Стадии загрузки и показа
DNS+TCP SSL request response delay before showdelay before request

Оптимизации
• Задержки на клиенте
• Генерация превью
• Доставка
Что из этого вносит
наибольший вклад в общее
время?

Измерения на клиенте
Запрос списка Рендеринг сетки Загрузка всех картинок в порции
Фотоньки Фотоньки Фотоньки

Измерения на клиенте – 2
Для отдельной картинки
– время установки ssl
соединения
– время собственно загрузки
Resource Timing API*
* Помним о Timing-Allow-Origin

Время показа превью
Запрос листинга
Получение порции превью
Рендеринг
сетки

До: время показа порции
3,200 мс
800 мс
200 мс
Время
Рендер
Листинг
Загрузка
порции

Генерация превью
• Проверка валидности ссылки
• Проверка доступов
• Получение большого превью
из хранилища
• Собственно генерация

Генерация превью
• Было:
• Генерация на машинах,
обрабатывающих добавляемые
файлы
• Кэш в рамках одной машины
• Стало:
• Отдельный кластер для генерации
• Кэш в рамках ДЦ

Время для пользователя
Запрос листинга
Получение порции превью
Рендеринг
сетки

Оптимизация доставки
Уменьшить размер: jpeg quality
95% 92%
124КB 62KB

SPDY для >24 картинок
1.5
2.6
3.7
8.0
1.5
2.3
3.2
6.8
25% 50% 75% 95%
Время отдачи порции в секундах

Предзапросы превью
Сгенерируй превью
Отдай превью
Клиент Сервер

Склеивать картинки
Дай пачку превью
Клиент Сервер

Качество по запросу
Дай превью
Клиент Сервер
Дай превью получше

До и после
3,200 мс
1,800 мс
800 мс
1,230 мс
200 мс
220 мс
До После
РендерЛистинг
Загрузка
порции

Выводы и рекомендации
• Перед началом
оптимизации необходимо
получить полную картину
• Разные сервисы нужно
изолировать по ресурсам
• Для SPDY нужна служба
поддержки :)
• После каждой оптимизации
нужно заново
профилировать

Сергей Нечаев
Менеджер технических проектов
Яндекс.Диска
@spnechaev

Weitere ähnliche Inhalte

Was ist angesagt?

Это реальный рассказ об архитектуре Единой Фронтальной Системы (ЕФС) - системы, которая будет обслуживать абсолютно всех клиентов Сбербанка во всех каналах (отделения, интернет-банки, мобильные приложения, АТМ и т.д.). Это означает: десятки миллионов активных клиентов, 24х7, и еще пара NFR'ов, от которых порой вздрагиваешь по ночам :) С одной стороны мы должны гарантировать 99.99% доступность, с другой стороны мы должны сокращать time-to-market для новых продуктов и быть готовыми обновлять ЕФС очень часто и по кусочкам – и это малая часть вызовов, с которыми нам приходиться сталкиваться. В моем докладе я расскажу: · Как мы гарантируем 99.99% доступности для всего ЕФС, включая хранилище (и особенно включая хранилище). · Как мы масштабируемся на миллионы пользователей, оставаясь внешнее единой системой. · Как мы реализуем zero downtime deployment, чтобы оставаться в 99.99% в условиях частых обновлений.

Высокопроизводительная и отказоустойчивая архитектура фронтальных систем / Ма...

Ontico

О чем доклад: - Как в нашем проекте устроен Zabbix, применяемые нами способы автоматизации, собственные методы "дискавери" серверов и сервисов. Плюс как правильно держать Zabbix под высокой нагрузкой и не упираться в ресурсы серверов. - Для чего мы используем Pinba, какие именно метрики помогают нам узнать о реальных проблемах пользователей. - Как мы храним графики в RRD. Мониторинг этих графиков: User activity monitoring. - Zabbix -> RRD => Capacity Planning. Как быстро найти слабые места среди кластеров в десятки и сотни нод.

Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".

Badoo Development

Антон Галицын

CodeFest

Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры? Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы! Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий. Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.

Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)

Ontico

Мы создаем nodejs приложения, используя различные современные технологии, такие как Docker, Consul, pm2. Современный спектр решений настолько обширен, что сложно не заблудиться. Как же выбрать нужные вашему проекту технологии, чтобы успешно его запустить и поддерживать? Будут рассказаны истории и, конечно же, даны вредные советы :) Как на nodejs пройти путь от Hello world приложения до распределённого решения, состоящего из микросервисов? Мы пройдём жизненный цикл продукта, начав с простого приложения на nodejs. Научимся его правильно запускать и будем постепенно добавлять элементы, убирая при этом ненужные. Так к нашему приложению присоединится гипервизор, а само оно будет разделено на части, где каждая сущность будет управлять своей частью приложения. Построив таким образом архитектуру на чистом nodejs, мы займёмся развитием приложения, добавим современные технологии и применим новые подходы к организации инфраструктуры. Запакуем приложение в Docker, попутно обсудим, зачем он нужен и что может дать. И, наконец, решим проблему поиска запущенных сервисов и отслеживания их статусов, используя Consul.

Инфраструктура распределенных приложений на nodejs / Станислав Гуменюк (Rambl...

Ontico

Zabbix в сервисной компании ОНЛАНТА - Zabbix Meetup Moscow

Vadim Nesterov

Оптимизация любого веб-приложения — это нетривиальная задача, для решения которой требуется проводить мониторинг загрузки системных ресурсов, выполнять микро-вэнчмаркинг, экспериментировать с настройками, проводить нагрузочное тестирование и т.д. В текущем году нашей команде довелось поучаствовать в нескольких проектах, в которых перед нами стояла задача оптимизации J2EE веб-приложений. Один из них — портал для ОАО «Сбербанк России» (www.sberbank.ru). Основной сайт Сбербанка реализован на основе портального движка BackBase и является J2EE-приложением. При проведении оптимизации его работы нам пришлось изучить и собрать много информации и документов, которые связаны с настройкой и оптимизацией высоконагруженных веб-приложений. В ходе реализации проектов я заметил, что не существует сводного документа с инструкциями по оптимизации работы приложения, поэтому решил поделиться нашим опытом. Этот доклад может послужить в качестве дорожной карты (Road Map) для настройки и оптимизации J2EE веб-приложений. В докладе будут рассмотрены следующие аспекты: 1) Общие подходы и методология оптимизации веб-приложения. 2) Оптимизация настроек веб-сервера. 3) Оптимизация кода приложения на стороне клиента. 4) Оптимизация на стороне middleware, в том числе на сервере приложений. 5) Оптимизация на уровне Базы Данных.

Настройка и оптимизация высоконагруженных J2EE веб-приложений / Шамим Ахмед (...

Ontico

Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения. К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур. В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы. 1. Когда "интересно" не значит "правильно"? 1.1. Специфика развития высоконагруженного проекта. 1.2. Требования бизнеса и современные технологии. 1.3. Типичные "сомнительные" решения. 2. Проблемы в архитектуре отказоустойчивых систем. 2.1. Ошибки в планировании резервирования. 2.2. Ошибки в планировании системы выкладок. 2.3. Ошибки в архитектурах систем хранения данных. 3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку. 3.1. Ошибки в планировании мощностей системы. 3.2. Ошибки в планировании возможностей масштабирования системы. 3.3. Ошибки в архитектурах систем хранения данных.

Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...

Ontico

+ Функционал разных решений для балансировки. + Виды балансировщиков (DNS, hardware, software, облачные решения). + Поведение при скачках трафика и возможности скалирования сервиса. + Специфика трафика RTB в контексте балансировки. + Проблемы, которые возникали у нас, и как мы их решали.

Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...

Ontico

Главная → Тезисы и презентации Балансировка нагрузки и отказоустойчивость в Одноклассниках Системное администрирование Доклад принят в Программу конференции Никита Духовный Одноклассники Ведущий системный администратор в Одноклассниках. Начинал IT-карьеру разработчиком, занимался релиз инженерией, выбрал системное администрирование. Возглавляет одну из команд. Занимается задачами, обеспечивающими работу портала - автоматизацией, запуском новых решений, поддержкой инфраструктуры. Ведёт несколько хардкорных проектов, в том числе - по повышению отказоустойчивости портала. Тезисы Проект Одноклассники начинал свою жизнь в одном датацентре. С ростом популярности растёт и нагрузка. С ростом нагрузки открываются проблемы: - Ни один, даже самый мощный, сервер больше не справляется в одиночку. - Нагрузка растёт, а в датацентре нет места для нового оборудования. - Падение датацентра безоговорочно приводит к даунтайму. - Сетевой сбой выводит портал из строя. - Пользователи в удалённых регионах страдают от низкой скорости. Я без прикрас расскажу вам, как мы в Одноклассниках решаем эти проблемы. Поговорим о следующем: - CDN - каким пользователям важен, его архитектура, устройство наших CDN-приложений, что происходит при авариях. - Датацентры - почему мы используем три основных датацентра, где они расположены (и почему именно там), распределение пользовательского трафика между ними. - Сеть - как и до чего мы балансируем трафик. - Балансировщики - как мы используем LVS, почему (и в каких случаях) используем и другие решения. Что делаем с приложениями, которые нельзя ставить за балансировщик. - Модули портала - о балансировке в нашем RPC протоколе, о том, что происходит с Одноклассниками при падении датацентра.

Балансировка нагрузки и отказоустойчивость в Одноклассниках

Ontico

В докладе поделимся опытом построения комплексного процесса последовательного улучшения производительности информационных систем мобильного оператора, расскажем об используемых инструментах и компонентах (Oracle, Tarantool, Java, Jmeter и т.д.). Особенность нашего оператора в том, что основной канал взаимодействия с клиентом - это мобильное приложение или web Личный кабинет, а не USSD команды и СМС, как у основной массы операторов. Данная особенность создает высокие требования к времени отклика и доступности сервисов и ставит перед нами целый ряд вопросов: - Как достичь приемлемого времени отрисовки страниц (не более 2х секунд) и не "уронить" backend при увеличении кол-ва абонентов в несколько раз за год до 4х миллионов? - Как обеспечить приемлемую производительность при наличии сложных оркестрирующих процессов на ESB и достаточно медленного, основанного на Oracle биллинга? - Как контролировать и улучшать производительность и доступность постоянно и на упреждение, а не когда "жареный петух клюнет"? Мы расскажем о том, как мы отвечаем на выше обозначенные вопросы. В частности, расскажем о внедрении двух БД - inmemory БД на чтение и Oracle на запись с соответствующей синхронизацией, о технике кэширования на нескольких уровнях, оптимизации синхронных и асинхронных процессов, о постоянном выявлении узких мест на тестировании, о кластеризации и других аспектах улучшения общей и частной производительности и доступности при быстро растущей абонентской базе и беспощадной креативности бизнеса.

Стратегия и тактика улучшения производительности BSS систем оператора мобильн...

Ontico

В процессе рефакторинга архитектуры мы начали переделывать часть системы на микросервисы, и вышло настолько клево, что мы просто обязаны этим поделиться. Микросервисы. Зачем они вообще: - В простых сервисах легче разбираться и локализовывать проблемы. - В микросервисной архитектуре проще добиваться отказоустойчивости. - Хотим выбирать лучший инструмент для каждой задачи. Получаем зоопарк технологий, которые в монолитные сервисы интегрировать сложнее. - Независимое обновление компонентов. - Тестирование частей системы. Как: - 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: описание архитектуры обязано быть актуальным и полным, иначе беда. Трудности: Допишу через пару дней.

Мастер-класс "Микросервисы: удобно, надежно, серебрянопульно" / Евгений Павло...

Ontico

Zabbix и правильное обнаружение проблем - Алексей Владышев @ RootConf 2015

Zabbix

HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников. Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных. Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше. Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering). В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE. В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности: - как мы определяем, когда сайт работает, а когда - нет? - что делаем, когда сайт лежит? - как настроили мониторинг и другие инструменты для быстрой локализации проблемы; - как нагружаем сайт, чтобы заранее выявить узкое место? Чтобы не было скучно, расскажу о конкретных кейсах: - как мы масштабировали реплики базы данных; - почему отказались от PgBouncer для высоконагруженных бэкендов; - почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом; - как решили проблему заваливания себя ретраями; - и др.

Как SRE следит за стабильностью и скоростью HeadHunter / Антон Иванов (HeadHu...

Ontico

РИТ++ 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) - получаем информацию из собственных приложений - получаем статистику из логов - Заключение - возможности масштабирования - какую нагрузку держим

Переезжаем с Zabbix на Prometheus / Василий Озеров (fevlake)

Ontico

HighLoad++ 2017 Зал «Калининград», 8 ноября, 13:00 Тезисы: http://www.highload.ru/2017/abstracts/3010.html В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта. ...

Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)

Ontico

В этом году мы перевели наш портал на HTTPS. Это оказалось непростой задачей. Основными проблемами явились рост нагрузки, увеличение Round Trip Times (RTT) и Mixed Content. Мы опробовали различные известные механизмы, призванные нивелировать эти проблемы, но, как оказалось на практике, все они скрывают в себе особенности. Эти особенности стоило знать заранее, но их не удалось почерпнуть из открытых источников. В этом докладе мы хотим поделиться сложностями, с которыми мы столкнулись, а также тем, к каким выводам в итоге пришли. Надеемся, что набитые нами шишки будут полезны тем проектам, которые только планируют переход на HTTPS.

Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники)

Ontico

Многие веб-студии не имеют в своем штате системных администраторов. И зачастую узнают о проблемах с запущенными проектами уже после того, как они случились. В докладе рассмотрим: - Явные и не очень потери на медленном / недоступном сайте. - Общие принципы внедрения систем real-time мониторинга. - Мониторинг нетипичных характеристик (наличие бэкапов, делегирование домена и т.п.). - Автоматизацию типовых реакций на алерты. - Зачем нужна аналитика в мониторинге (пробуем предугадать проблемы до того, как они случатся). - Инструменты и общие подходы быстрого поиска "узких" мест.

Мониторинг веб-проектов real-time мониторинг и аналитика, поиск ошибок и боев...

Ontico

Услуга виртуального дата-центра предъявляет жесткие требования к платформе виртуализации - клиенты хотят высокую производительность и стабильность, а провайдерам нужна возможность максимально плотно размещать нагрузки клиентов. Мы расскажем: 1. как мы работали с Virtuozzo, чтобы сделать его более производительным и стабильным и, вместе с тем, добиться максимальной плотности размещения виртуальных машин; 2. контейнеры Virtuozzo прекрасно решают эту задачу, но не подходят для размещения некоторых типов приложений, например, Windows; 3. как мы будем переходить на Virtuozzo с KVM, каких целей мы хотим добиться.

Виртуальный ЦОД для корпоративных клиентов на базе Virtuozzo: стабильность, п...

Ontico

За последние годы мечты фантастов XX века стали реальностью: смартфоны, видеозвонки, виртуальная реальность и, наконец, Интернет вещей. К сожалению, у прогресса всегда есть темная сторона. Я думаю, ни для кого не секрет, что такие компании как Sony, Yahoo, Adobe, Target и многие другие столкнулись с проблемами безопасности в последние годы. Количество скомпрометированных систем растет день ото дня. Node.js - это одна из самых быстрорастущих экосистем разработки приложений на рынке, которая постепенно перестает быть инструментом для разработки стартапов и проникает в корпоративный сектор. Вы уверены, что ваше приложение, разработанное на базе MEAN-стека, безопасно? В своем докладе я хотел бы рассмотреть данный вопрос. Мы поговорим о криптографии, аутентификации, авторизации, уязвимостях web-приложений, построенных на базе Node.js. К концу доклада вы получите пошаговое руководство, как уменьшить вероятность взлома вашего проекта.

Безопасность Node.js / Илья Вербицкий (Независимый консультант)

Ontico

Was ist angesagt? (20)