Высокая Загрузка Там, Где Вы Этого Не Ожидаете. Приключение На 20 Минут

Всем привет. Меня зовут Женя, я Full Stack разработчик в рекламной команде ВКонтакте.

В этой статье я расскажу вам о высоконагруженном месте в рекламном аккаунте ВКонтакте.

Любой разработчик может столкнуться с подобной ситуацией в своем проекте.

Материал будет полезен не только тем, кто занимается бэкендом, но и всем ИТ-специалистам, стремящимся сделать свои продукты быстрыми и отказоустойчивыми.

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

Одним из них является показ предварительного просмотра объявления размером 30 на 30 пикселей в таблице объявлений.

Кажется, что здесь происходит? Я добавил в запрос к базе дополнительное поле, вставил полученную ссылку на изображение на передний план и нарисовал ее в столбце.

Выглядит просто: 30 строк кода и 20 минут, включая поход за чашечкой кофе.

Итак, начнем!

Шаг 1. Получение изображения

Они могут содержать разный контент: фотографии, граффити, музыку, видео, истории, клипы, товары, карты, прикрепленные файлы – или несколько сразу в одном объявлении.

Каждый формат имеет свои особенности структуры данных.

Для некоторых, например фотографий и граффити, из них можно получить миниатюры.

А для видеорекламы нужно использовать специальные функции для получения неподвижных изображений.

Есть и другие форматы без изображений, и там приходится использовать плейсхолдеры от дизайнеров.

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

Шаг 2. Сжимаем изображение

И нам нужен небольшой превью, 30х30 пикселей.

Заставлять браузер пользователя работать с тяжелыми изображениями — значит увеличивать время загрузки всего контента на странице и съедать для нас гигабайты трафика.

Поэтому все большие изображения необходимо сжимать.

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

Мы запускаем все предварительные просмотры через эту функцию.

Шаг 3. Сохранение превью

Поиск изображений и создание миниатюр меньшего размера каждый раз, когда вы открываете страницу, отнимает очень много времени.

Вам нужно где-то хранить связь между ссылкой на превью и идентификатором объявления.

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

Шаг 4. Фронтенд

Шаг 5. Загрузите

Но давайте представим, что после внедрения нового функционала на товарном рынке рекламодатель впервые открыл свой аккаунт, содержащий 1000 объявлений, и начал прокручивать таблицу вниз.

По умолчанию объявления загружаются пакетами.

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

Логичным решением является установка ограничения на количество объявлений, обрабатываемых за одну загрузку страницы.

Давайте установим лимит в 20.

Шаг 6. И снова нагрузка

Потом заглянул во второй раз, мы создали превью следующих 20 объявлений.

Оказывается, чтобы увидеть миниатюры всех своих объявлений, рекламодателю необходимо 50 раз войти в свой аккаунт. Похоже на проблему.

Решением может быть прогрев кеша: мы запустим логику поиска миниатюр под капотом, и каждый раз, когда пользователь зайдет в систему, мы будем генерировать 20 новых и помещать их в memcached, а не показывать новый столбец в перед. Но возникает вопрос: а почему бы сразу не собрать все превью под капот? Ответ: из-за нагрузки.

В нашей системе имеется огромное количество рекламных объявлений, как активных, так и архивных.

Архивные открываются крайне редко, и тратить ресурсы на поиск превью к ним в фоновом режиме нецелесообразно.

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

Шаг 7. Что, еще раз загрузиться?

Мы сделали фоновый прогрев кеша, но если выкатить это на продакшн для 100% пользователей, то столкнёмся с проблемой.

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

Так мы делаем плавное включение функционала: можем контролировать процент пользователей, на которых запускается новая функция.

Шаг 8. Восстановление предварительного просмотра

Но что произойдет, если пользователь изменит содержание объявления? Это можно сделать не только в рекламном аккаунте, но и, например, при редактировании продвигаемой публикации.

Тогда превью станет неактуальным.

Поэтому после таких изменений нужно начинать генерировать новый.

Давайте добавим.

Шаг 9. Статистика

Итак, давайте добавим логи для каждого этапа генерации предварительного просмотра.

Шаг 10: Тестирование

Шаг 11. Внедрение в производство

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

Шаг 12. Мониторинг

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

И идем сбривать полуторамесячную бороду.

Теги: #Разработка сайтов #Высокая производительность #вконтакте #highload #дизайн и рефакторинг

• Как Убедить Посетителей Купить Что-Нибудь На Вашем Сайте....

  19 Oct, 24

• Вопросы Практического Экзамена Ccna, Ccnp И Ccent: Шифрование Паролей, Набор Брандмауэров Ios И Многое Другое!

  19 Oct, 24

• Госдума Может Обязать Российских Операторов Потратить Триллионы Рублей На Борьбу С Терроризмом

  19 Oct, 24

• Yahoo! Что Такое Страница Входа

  19 Oct, 24

• Если Собираются Воровать, То Лучше Воровать У Нас - Официальная Позиция М.с.

  19 Oct, 24

• Varchar(Max)-Varchar(Max) И В Производстве

  19 Oct, 24

• Как Мы Делали Первый В Снг Хакатон Для Инженеров По Автоматизации: От Идеи К Реализации, Достижения И Ошибки

  19 Oct, 24

• Крупнейший Пиратский Синдикат Китая Закрылся

  19 Oct, 24

• Яндекс Поддерживает «Правильные» Интернет-Тарифы

  19 Oct, 24

• Eee Pc С Сенсорным Управлением?

  19 Oct, 24