Ну это просто PLUS
Да, я с запозданием. Нет времени сидеть на дтф, сорямба. Поговорим о премах!
Итак, вы жалуетесь на то, что обслуживание жрёт бабосики. Давайте посмотрим небольшой пример: страницу премов...
При открытии страницы мы видим, что есть 1800 аватарок пользователей, каждая загружается отдельным запросом... Я конечно всё понимаю, но бекендеру привет. Раньше за такое били больно и ногами всей командой.
Вы жалуетесь на трафик cdnки, но при этом вместо генерации по крону одного спрайтшита с аватарками пользователей вы обрабатываете 1800 запросов в которых 1/4 сайза ответа занимают заголовки http протокола.
И это только сейчас. А ведь вы планируете, что пользователи будут подписываться, а значит кол-во аватарок будет расти.
А - Ахуительная архитектура
Я не против премиумов. Это ок, всё збс. Я просто не понимаю почему вы вместо оптимизации движка выбрали путь масштабирования через увеличение кластера машин.
Ваша CDN это монолит, который не жизнеспособен в контексте хайлода. Вы попытались и рыбку съесть, и косточкой не подавиться, создав унифицированный интерфейс для работы с контентом. По факту вы впустую тратите ресурсы на обработку и передачу данных от облака данных (используете ли вы сторонние решения или подняли свой кластер ipfs) к веб серверу, который отвечает клиенту, виесто того чтобы напряму отдавать контент от CDN провайдера по типу gcs\s3\какая-нибудь очередная хуйня.
Тим лид, который дирижировал данным оркестром явно не планировал, что леонардо будет жить долго.
Большому кораблю — большое плаванье
Ребзи, за эдитор конечно фронтендерам спасибо. Надеюсь проблемный коуб не сожрёт у вас ресурсы и вы наконец введёте пользовательские подсайты, тёмную тему и разберётесь с проблемами на сервер сайде без расширения кластера ибо по закону мура в определённый момент коубом станете вы.
Из всего текста понял только маты, но однозначно поддерживаю. Ибо нехуй.
Комментарий недоступен
Не читал пост, понял твой комментарий, вьебал обоим минуса. Ибо нехуй писать хуйню.
Привет, давай по частям разберём тобою написанное. Меня зовут Илья, я технический директор 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 минут, часов, дней, лет или при проверке изменилось ли что-либо с момента последнего запуска крон скрипта, или даже через собственные вебхуки. В общем, это точно заняло бы не так уж много времени.