Комментарии 16
А чем не устроило отличное готовое решение? Перед ним можно кеширующий прокси поставить, кстати.
Что мешало пойти по классической схеме с генерацией превью сразу при загрузке изображения или видео и хранением его на сервере?
Архивных много, после помещения в архив, генерировать на лету для таких объявлений, если просмотров единицы.
В качестве контента для рекламного объявления пользователь может использовать ранее загруженные в свой профиль фотографии и видео или уже созданные посты. Поэтому превью генерируется только для используемого в рекламной записи контента.
Как устроены ссылки на объявление? На простых проектах это постоянный url, по которому не возможно определить, создана миниатюра или еще нет.
Шаг 5. Зашел в рекламный кабинет - прогреть кеш, когда вошел для остальных не в пачке на сервере заранее, сомнительно что рекламодатели из кабинета не вылезают, обычно распределено в течении дня. Нагрузка распределяется.
Технически - пропустить 20-40 записей, для которых создается в реальном времени, для всех остальных кроме архивных предварительная генерация на сервере по запросу.
Шаг 7. Запустить заранее не на полной скорости, так не возможно?
Шаг 8. Усложнение не понятно, вроде бы элементарно, удалили по ключу, добавили новое. Пока создается используем генератор в режиме онлайн, таких объявлений единицы.
В Вконтакте рекламная система изначально очень высоконагружена, для маленьких проектов данная ситуация может и не быть проблемой.
Я не отрицаю, что возможны разные решения данной ситуаций. Цель статьи - показать читателям, что нужно задумываться о том, что в каких-то местах могут возникнуть дополнительные нагрузки.
Меня раздражают, когда говорят про хайлоад и не приводят вообще никаких цифр.
При этом Вы очень лихо оцениваете сложность задачи, не зная структуры проекта и не опираясь на цифры по текущей нагрузке системы.))
Как я уже писал, существуют различные варианты решения проблемы. Вы предлагаете нагружать систему по ночам, мы у себя решили размазать нагрузку в течение суток, так как у нас пользователи в разных часовых поясах, и понятие ночи размывается.
Как отмечалось в самой статье, она предназначена для большого круга читателей, поэтому в ней нет технических моментов и, конечно, нет конфиденциальных данных.
В шаге 5 это как раз и делается, превьюшки генерятся по 20 штук при каждом заходе на страницу. Запускать фоном создание всех превьюшек в кабинете - слишком затратно, так как есть большие кабинеты с тысячами объявлений.
Шаг 7 идет в дополнение к шагу 6. Если прогревать кеш для всех пользователей, то это займет больше времени. Нам хотелось быстрее предоставить пользователям данное улучшение рекламного кабинета.
В шаге 8 никакого усложнения нет, при изменении контента (не только в самом объявлении, но и, как вариант, в продвигаемом посте группы) запускается генератор превьюшки.
Картинка 30 на 30 в JPG занимает аж 183 байта, ваш клиент который генерит вам бабло за 1000 объявлений займет аж 200 килобайт! Нельзя этого допустить! Давайте будем писать логику кэширования! А то вдруг эти 200кб месяцами не будут использоваться? Мы же разоримися!
Выражаясь русским языком вы придумали себе работу, абсолютно не требующуюся в данной задаче.
А для всех старых неторопясь в фоне за неделю или сколько там надо сгенерить.
Старые можно как-то логично ограничить по любому подходящему условию. Ну хотя бы по логам что оно показывалось хотя бы раз за последний месяц или свежее месяца. Для остальных выводить любую заглушку.
Хранить все это добро просто в поле в БД рядышком со всем текстом объявления.
Вот так люди и находят себе хайлоад на пустом месте. Задачка для джуна, под присмотром мидла. Сеньер нужен разок глянуть на архитектуру и все.
Если нет превью в кэше, то отдаём полное изображение, параллельно запуская генерацию превью в фоне.
Highload там, где его не ждёшь. Приключение на 20 минут