Ну это просто PLUS
Да, я с запозданием. Нет времени сидеть на дтф, сорямба. Поговорим о премах!
Итак, вы жалуетесь на то, что обслуживание жрёт бабосики. Давайте посмотрим небольшой пример: страницу премов...
Да, я с запозданием. Нет времени сидеть на дтф, сорямба. Поговорим о премах!
Итак, вы жалуетесь на то, что обслуживание жрёт бабосики. Давайте посмотрим небольшой пример: страницу премов...
Привет, давай по частям разберём тобою написанное. Меня зовут Илья, я технический директор DTF.
При открытии страницы мы видим, что есть 1800 аватарок пользователей, каждая загружается отдельным запросом...Моей первой реакцией на макеты со стеной с аватарками было что-то вроде "давайте только так, чтобы это было статичной картинкой", но это означало бы, что нам нужно с нуля написать собиралку этого полотна на бэкенде.
Что это значит:
- Нужно уметь обрабатывать незагрузившиеся аватарки, вставляя, например, дефолтную.
- Нужно понимать, что генерация такого полотна будет занимать память и время (загрузка аватарок и генерация выходной картинки); впрочем, мы умеем параллелить такие штуки, это должно помочь.
- На фронтенде надо реализовать img-map (и вытерпеть едкие шутки насчёт 2020 года, в котором мы вообще-то живём).
- Либо сделать какую-то JS-обёртку, видимо, над канвасом, чтобы сохранить эффект при наведении.
Между опциями релизиться с самой простой версией или отложить релиз платных аккаунтов и потратить ещё несколько дней на реализацию, мы выбрали первый вариант. Не только из-за времени, но и потому что у нас много важных задач, которыми заняты бэкенд-разработчики и мы стараемся всегда приоритезировать их. Вдобавок сделали так, что аватарки грузятся в том же размере, что и в комментариях, а это значит, что у многих пользователей они будут в кэше браузера.
Что касается стоимости CDN, то отмечу, что картинки на странице со спонсорами весят суммарно 4,6МБ. Если зайти в случайную новость с кучей комментов (https://dtf.ru/95393), то картинки в комментах будут весить 6,5МБ (и ещё 2,2МБ — видео), а просмотров у этой новости 16 000. Конечно, не все пролистывают комментарии до конца, но на DTF таких новостей выходит каждый день не одна и не две. Страница со спонсорами куда менее популярна. Это всё значит, что наши затраты на CDN для раздачи аватарок на этой странице — на уровне погрешности по сравнению со всем мультимедиа-трафиком всего сайта.
Несмотря на это, лично мне не нравится, как сейчас работает эта страница, я бы хотел, чтобы аватарки грузились быстрее, но считаю, что пока поживём с тем, что есть. Думаю, мы вернёмся к переделке этой страницы, но пока просто есть более важные задачи.
Я просто не понимаю почему вы вместо оптимизации движка выбрали путь масштабирования через увеличение кластера машин.
Мы шли путём оптимизации движка восемь лет, удерживая каждый из наших сайтов в рамках одного сервера (опционально вынося какие-то куски на отдельные машины). Дальше мы так идти не можем. В какой-то момент рабочее время разработчиков, которое надо потратить на ускорение страницы на 50мс становится дороже нового сервера, который обеспечит эти 50мс просто за счёт распределения нагрузки. Плюс если вы помните, у нас была проблема с пушами — иногда при очень резонансных новостях сайт ложился на 10-15 минут из-за нагрузки, это не решить никакой оптимизацией, поэтому нам пришлось пойти в сторону Кубернетис-архитектуры, где мы можем докидывать ресурсы для сайта под нагрузкой в любой момент.
веб серверу, который отвечает клиенту, виесто того чтобы напряму отдавать контент от CDN провайдера по типу gcs\s3\какая-нибудь очередная хуйня.
Мне кажется, я не понял вас или вы не до конца разобрались с тем, как работает наш CDN. Все картинки, видео и аудио лежат в хранилище. Отдельно мы подключили CDN, который если не находит файл у себя, идёт за ним в это хранилище. Мы не тратим ресурсы на доставку, наоборот, это самая эффективная с нашей точки зрения архитектура (кроме, скажем, идеального p2p), так как все популярные картинки лежат на сервере в вашем городе или городе неподалёку. И лишь за некоторыми надо идти к хранилищу.
Тим лид, который дирижировал данным оркестром явно не планировал, что леонардо будет жить долго.
А это в точку. Я и правда не рассчитывал, что Леонардо придётся когда-либо хранить видео и аудио, что на нём будет так много файлов. Более того, ещё девять месяцев назад было понятно, что ему срочно нужен рефакторинг, который нам пришлось откладывать из-за нехватки человеческих ресурсов и к которому мы только приступаем. Впрочем, хотя бы ставка на то, что нам нужно хранить один оригинал и резать его под нужные размеры позже сработала.
Спасибо за ваше сообщение, мы ценим это, правда. Просто хотелось показать, что за нашими решениями стоит логика, хотя, конечно, порой мы ошибаемся, как и все.
но это означало бы, что нам нужно с нуля написать собиралку этого полотна на бэкенде
Генерить и кешировать на X минут. На клиенте можно разбивать картинку или img-map, да. Ну, день-два работы на всё. Мы могли бы потерпеть. К чему такая спешка?
Мы не тратим ресурсы на доставку, наоборот, это самая эффективная с нашей точки зрения архитектураЭффективная. Но в случае с тем же aws cdn (поверх s3) за трафик бы платили очень много D:
P.S. а что на беке? Балансите через что? Для сервис дискавери что? Диплоите чем? Ансибл? Пупет? Какой язык в основном для сервисов? Какие базы? Какая основная? Постгря? Кеши в Редисе? Что для очередей? Кролик или Каффка?
Вообще, было бы интересно почитать подробнее про инфраструктуру (─‿‿─)
P.S. за такой подробный коммент спасибо.
P.P.S. почему галочки нету у ника? D:
Привет, Илья. Спасибо за ответ. Возможно в посте сложилось впечатление, что я немного контуженный, но тут нужно внести некоторую ясность:
Пример страницы премов здесь не для того чтобы сказать какая она ресурсоёмкая, а для того чтобы напомнить про такое понятие как "технический долг" и о том как часто компании пренебрегают качеством в угоду скорости с надеждой оптимизировать "потом". Все мы знаем когда это "потом" настаёт. Вместо оптимизации приходится докупать вычислительные ресурсы, увеличивая тем самым затраты на содержание и поддержку этого зоопарка машин.
По поводу вашей архитектуры хранения данных:
Я не знаю как это выглядит с вашей перспективы как человека, который видит всё изнутри, с перспективы простого пользователя это выглядит так: вы храните где-то контент, который имеет свой отдельный реестр с http приложением/api интерфейсом и это самое приложение выступает прослойкой между разными типами хранилищ данных (3rd party video services, imgs, audio, etc). С одной стороны да, это прикольно когда у вас каждый контент-элемент имеет свой айди, всё красиво подаётся через одно место и доступ строго регламентирован, но с другой стороны получается, что помимо бекенд сервера с бизнес-логикой приложения вы ещё породили дополнительную сущность, потенциальное бутылочное горлышко в виде прослойки между контентом и пользователями. Вместо того чтобы отдавать контент напрямую (свой через s3, 3rd party прямыми ссылками) и все ссылки хранить в прямом формате вы храните иды для работы с леонардо через WYSIWYG редактор. По-моему это выстрел себе же в ногу.
Да, я понимаю, что есть легаси, есть несбывшиеся мечты и даже возможно опрометчивые решения, но это всё поправимо когда есть ресурсы. И в реалиях нашего времени основной ресурс отнюдь не деньги, а кадры. И мне бы как пользователю, который за то чтобы сервис развивался даже с платными подписками и возможным пейволом, хотелось бы чтобы деньги пошли не на докупку вычислительных мощностей, а на поиск кадров, с помощью которых будет возможность уменьшать технический долг, а не накапливать его до часа расплаты и продажи кому-либо. В этом весь мессейдж данного треда, не для того чтобы кого-либо оскорбить или ещё, что-либо. no offense, как говорится.
Ох, забыл ответить на самый интересный пункт:
- На фронтенде надо реализовать img-map (и вытерпеть едкие шутки насчёт 2020 года, в котором мы вообще-то живём). - Либо сделать какую-то JS-обёртку, видимо, над канвасом, чтобы сохранить эффект при наведении. Либо на бекенде собирать единую картинку - композицию аватарок пользователей, которую указывали бы в css атрибуте background-image у нужного html тега, а выборку из этой композиции делали бы через background-position. Иными словами - решили проблемы через классические css spritesheets. Таким образом вы бы сохранили все нужные эффекты, но при этом получили бы более оптимизированное решение.
А как уж вы там билдили бы эту картинку - вам виднее. Хоть раз в N минут, часов, дней, лет или при проверке изменилось ли что-либо с момента последнего запуска крон скрипта, или даже через собственные вебхуки. В общем, это точно заняло бы не так уж много времени.