Драма 24/7
Netless
794

Ну это просто PLUS

Да, я с запозданием. Нет времени сидеть на дтф, сорямба. Поговорим о премах!

В закладки

Итак, вы жалуетесь на то, что обслуживание жрёт бабосики. Давайте посмотрим небольшой пример: страницу премов...

При открытии страницы мы видим, что есть 1800 аватарок пользователей, каждая загружается отдельным запросом... Я конечно всё понимаю, но бекендеру привет. Раньше за такое били больно и ногами всей командой.

Вы жалуетесь на трафик cdnки, но при этом вместо генерации по крону одного спрайтшита с аватарками пользователей вы обрабатываете 1800 запросов в которых 1/4 сайза ответа занимают заголовки http протокола.

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

А - Ахуительная архитектура

Я не против премиумов. Это ок, всё збс. Я просто не понимаю почему вы вместо оптимизации движка выбрали путь масштабирования через увеличение кластера машин.

Ваша CDN это монолит, который не жизнеспособен в контексте хайлода. Вы попытались и рыбку съесть, и косточкой не подавиться, создав унифицированный интерфейс для работы с контентом. По факту вы впустую тратите ресурсы на обработку и передачу данных от облака данных (используете ли вы сторонние решения или подняли свой кластер ipfs) к веб серверу, который отвечает клиенту, виесто того чтобы напряму отдавать контент от CDN провайдера по типу gcs\s3\какая-нибудь очередная хуйня.

Тим лид, который дирижировал данным оркестром явно не планировал, что леонардо будет жить долго.

Большому кораблю — большое плаванье

Ребзи, за эдитор конечно фронтендерам спасибо. Надеюсь проблемный коуб не сожрёт у вас ресурсы и вы наконец введёте пользовательские подсайты, тёмную тему и разберётесь с проблемами на сервер сайде без расширения кластера ибо по закону мура в определённый момент коубом станете вы.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Netless", "author_type": "self", "tags": [], "comments": 87, "likes": 45, "favorites": 9, "is_advertisement": false, "subsite_label": "dramaqueen", "id": 95477, "is_wide": true, "is_ugc": true, "date": "Tue, 21 Jan 2020 21:28:01 +0300", "is_special": false }
0
{ "id": 95477, "author_id": 116280, "diff_limit": 1000, "urls": {"diff":"\/comments\/95477\/get","add":"\/comments\/95477\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/95477"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 160556, "last_count_and_date": null }
87 комментариев
Популярные
По порядку
Написать комментарий...
37

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

Ответить
4

Нихуя не понял, но со всем согласен. Когда читал пост Ширяева, тоже не понял прикола сохранения и наращивания мощностей для DTF (в том объеме, который описан), как и загрузки аватарок с прямыми ссылками на профили. Зачем?

Ответить
0

Зачем?

Чтобы оправдать введение према, конечно.

Ответить
0

Не читал пост, понял твой комментарий, вьебал обоим минуса. Ибо нехуй писать хуйню.

Ответить
31

Привет, давай по частям разберём тобою написанное. Меня зовут Илья, я технический директор 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), так как все популярные картинки лежат на сервере в вашем городе или городе неподалёку. И лишь за некоторыми надо идти к хранилищу.
        
Тим лид, который дирижировал данным оркестром явно не планировал, что леонардо будет жить долго.

А это в точку. Я и правда не рассчитывал, что Леонардо придётся когда-либо хранить видео и аудио, что на нём будет так много файлов. Более того, ещё девять месяцев назад было понятно, что ему срочно нужен рефакторинг, который нам пришлось откладывать из-за нехватки человеческих ресурсов и к которому мы только приступаем. Впрочем, хотя бы ставка на то, что нам нужно хранить один оригинал и резать его под нужные размеры позже сработала.
        
Спасибо за ваше сообщение, мы ценим это, правда. Просто хотелось показать, что за нашими решениями стоит логика, хотя, конечно, порой мы ошибаемся, как и все.

Ответить
5

но это означало бы, что нам нужно с нуля написать собиралку этого полотна на бэкенде

Генерить и кешировать на X минут. На клиенте можно разбивать картинку или img-map, да. Ну, день-два работы на всё. Мы могли бы потерпеть. К чему такая спешка?

Мы не тратим ресурсы на доставку, наоборот, это самая эффективная с нашей точки зрения архитектура

Эффективная. Но в случае с тем же aws cdn (поверх s3) за трафик бы платили очень много D:

P.S. а что на беке? Балансите через что? Для сервис дискавери что? Диплоите чем? Ансибл? Пупет? Какой язык в основном для сервисов? Какие базы? Какая основная? Постгря? Кеши в Редисе? Что для очередей? Кролик или Каффка?
Вообще, было бы интересно почитать подробнее про инфраструктуру (─‿‿─)

P.S. за такой подробный коммент спасибо.
P.P.S. почему галочки нету у ника? D:

Ответить
9

Ну, день-два работы на всё

День-два работы, ещё один день на тестирование, потом на исправление багов, и всё это время можно было бы потратить (и было потрачено) на что-то более полезное. Я ещё раз обращу внимание, что я не считаю, что решение идеальное или конечное. Оно  д о с т а т о ч н о е  для продакшена на сейчас.
        
        
Но в случае с тем же aws cdn (поверх s3) за трафик бы платили очень много

Поэтому мы его и не используем, хотя AWS безумно удобный. Но для нас слишком дорогой.
        
        
а что на беке? Балансите через что? Для сервис дискавери что? Диплоите чем? Ансибл? Пупет? Какой язык в основном для сервисов? Какие базы? Какая основная? Постгря? Кеши в Редисе? Что для очередей? Кролик или Каффка?

PHP, k8s, werf, postgres, redis, memcached, php-resque & rabbitmq
        
почему галочки нету у ника

ID, лапы и хвост — вот моя верификация :)

Ответить
0

k8s

У себя хостите и сами настраиваете кубик? Через какую веб-морду кстати? Не ранчер?

Ответить
1

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

Ответить
1

Ух, круто, что отдельная команда. На прошлом месте работы СТО всё это дело повесил на админа (единственного в команде). Вышло противоречиво)

Ответить
1

 P.P.S. почему галочки нету у ника? D:

Из редакции вроде ни у кого нету галочки, потому что они ближе к народу.

Ответить
0

Если ты не заметил, галочки на ДТФ только у более-менее медийных личностей извне. У администрации их нет.

Ответить
2

Сколько килограмм медийности нужно, чтоб получить галочку? А, @Denis Shiryaev? Боюсь, 92.4 не смогу набрать.

Ответить
5

Привет, Илья. Спасибо за ответ. Возможно в посте сложилось впечатление, что я немного контуженный, но тут нужно внести некоторую ясность:

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

По поводу вашей архитектуры хранения данных:
Я не знаю как это выглядит с вашей перспективы как человека, который видит всё изнутри, с перспективы простого пользователя это выглядит так: вы храните где-то контент, который имеет свой отдельный реестр с http приложением/api интерфейсом и это самое приложение выступает прослойкой между разными типами хранилищ данных (3rd party video services, imgs, audio, etc). С одной стороны да, это прикольно когда у вас каждый контент-элемент имеет свой айди, всё красиво подаётся через одно место и доступ строго регламентирован, но с другой стороны получается, что помимо бекенд сервера с бизнес-логикой приложения вы ещё породили дополнительную сущность, потенциальное бутылочное горлышко в виде прослойки между контентом и пользователями. Вместо того чтобы отдавать контент напрямую (свой через s3, 3rd party прямыми ссылками) и все ссылки хранить в прямом формате вы храните иды для работы с леонардо через WYSIWYG редактор. По-моему это выстрел себе же в ногу.

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

Ответить
1

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

А что нужно для счастья? Всего лишь хороший менеджмент и грамотные сотрудники в n количестве. Не так уж и много.

Ответить
3

Не, торопиться это тоже хорошо. Такая позиция позволяет бизнесу оставаться на плаву или даже обгонять конкурентов. Все мы знаем, что нет предела совершенству и если дать волю программисту писать код без дедлайнов, то он напишет и будет его вылизывать пока не случится второе пришествие, не приступая к следующим задачам. Плохо когда некому защищать приверженцев сделать "хорошо", но медленно. Тогда приверженцы вылизывать код веками не получают ни желаемого даже намёка на вылизывания, ни стабильный продукт, ни удовольствие.

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

(это я сейчас не про ДТФ, Комитет или Илью в частности, а вообще)

Ответить
0

Для того, чтобы не копить техдолг бесконечно, мы раз в год в январе устраиваем комплексный рефакторинг, стараясь избавиться от как можно большего количества техдолга. И всё же в условиях эджайла жить без техдолга невозможно, если ты коммерческий проект. Всегда есть бизнес-интересы, всегда ресурсы ограничены. Не выбирать между меньшим и большим техдолгом нельзя :) Эта страничка с аватарками не самый страшный техдолг, который у нас есть, есть и похуже. Просто не думайте, пожалуйста, что мы не отдаём себе в этом отчёт, отдаём. Здорово, что обращаете внимание, это помогает не расслабляться.

        
Мы храним дополнительные данные, а не только ссылку по нескольким причинам:
- генерация ссылок на разные размеры картинки (в статье, в ленте, в приложении, как обложка итд)
- фиксация места для картинки в DOM до момента её загрузки (чтобы при переходе по ссылке в комменты не прыгала вся страница туда-сюда)
- генерация подложки в цвет картинки на момент, пока она грузится
- другое
        
Поэтому нам и нужна собственная прослойка между оригиналами файлов и браузером в виде Леонардо — он позволяет нарезать картинки на нужные размеры, занимается кэшированием и работает с CDN. Хранить вместо JSON с данными об объекте просто ссылку на него — огромное висящее ружьё. Мы пришли к текущей архитектуре через достаточно долгий путь и уверены в том, что это отличное решение для наших требований.
        
А почему вам кажется, что техдолг, какой бы он ни был, составляет какую-то значительную часть наших затрат? Например, по вашей оценке, сколько стоит поддержка Леонардо и сколько могла бы стоить раздача из собственного s3-like хранилища по прямым ссылкам?

Ответить
0

Например, по вашей оценке, сколько стоит поддержка Леонардо и сколько могла бы стоить раздача из собственного s3-like хранилища по прямым ссылкам?

Затраты на леонардо у вас составляют, по моим довольно абстрактным подсчётам в районе 5+к зелени, основная часть трат как и у любого контентного проекта это плата за egress трафик. Считал только для дтф выводя среднюю сумму в месяц(на основании предположения, что всего 100к статей, по 15к просмотров каждая и 5 мб контента на каждую статью / за 4 года ака 48 месяцев).

Посчитать примерно траты на self hosted s3-like хранилище я не могу т.к. для этого нужно знать более точно откуда к вам ходят, сколько жрут трафика и уже тогда прикидывать сколько нужно кеширующих серверов, где они будут находиться и сколько они сожрут ресурсов. 
Данное решение поможет только если реально существует возможность размазать трафик между цодами. Нужно садиться, смотреть сколько реально трафика жрёт каждый регион, какие в каждом регионе есть цоды с нормальным доступом к магистрали, смотреть какой канал они дают и считать сколько нужно поднять кеширующих серверов для каждого региона чтобы умещаться в потребляемый объём трафика и сколько нужно брать запаса.
Таким же образом можно потом сравнить исторические данные роста аудитории и построить прогноз на будущее через экстраполяцию исторических данных.

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

Я вижу как вы стараетесь asap выкачивать фичи, которые ну не совсем production-ready. Например с теми же mention'ами в комментах, я показывал давно как можно слапнуть порядка 200 человек за раз и генерация данного поста - ванлайнер на жсе. Проспамить добротную часть пользователей, нагрузив вас даже простыми упоминаниями пользователей не составило бы труда. А ведь вы ещё отправляете пуши, имейлы.
Так же и этот момент с аватарками. Я бы пул реквест с такой реализацией завернул обратно девелоперу на рефакторинг.
Дьявол кроется в мелочах и исходя из вот таких вот мелочей я прихожу к выводу, что процесс контроля качества разработки в комитете очень далёк от идеала.

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

Ответить
0

Затраты на леонардо в несколько раз ниже того, что вы написали. И я имею ввиду все три сайта.

Что касается контроля качества, тут я ничего сказать не могу, у меня совершенно другой взгляд на вещи. Я не считаю, что мы где-то счастливо висим на золотой середине между скоростью и качеством, но, по моим оценкам, мы к ней гораздо ближе, чем по вашим 🙂

Ответить
0

Затраты на леонардо в несколько раз ниже того, что вы написали.

Ну так это очевидно, я же считаю среднее значение взятое с потолка.

Вы говорите про золотую середину, а конечные потребители уже и не ждут обещанных кастомных юзерских разделов и тёмной темы. Ну что же, подождём ещё

Не, круто конечно, что вы вводите всякие вещи типа чатика, подписок и т.д. Особенно лучи добра за editor.js, в опенсорсе wysiwyg редакторов мало никогда не бывает. Но я знаю каким оверхайпнутым был коуб пару лет назад, как его переоценивали и как они в итоге ничего не смогли. И на фоне последней новости о присоединении коуба, в купе с тем, что создаётся впечатление будто бы не всё гладко при разработке, опасения о том, что и дтф накроется тазом произвели данный тред.

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

Keep it up!

Ответить
0

٩(ఠ益ఠ)۶

Ответить
0

Не, я не хочу ни отсиживаться, ни уверять кого-то, что у нас в полном порядке — мы недавно открыли вакансию тимлида, чтобы улучшить качество кода и контроль качества https://vc.ru/team/101307-team-lead — мы понимаем, что у нас не всё с этим идеально и хотим делать лучше в рамках наших возможностей.

Ответить
0

Если бы не пыха, то возможно бы отправил вам резюме. Но я у мамы рельсовик-затейник

Ответить
0

Ох, забыл ответить на самый интересный пункт:

- На фронтенде надо реализовать img-map (и вытерпеть едкие шутки насчёт 2020 года, в котором мы вообще-то живём). 

- Либо сделать какую-то JS-обёртку, видимо, над канвасом, чтобы сохранить эффект при наведении. 

Либо на бекенде собирать единую картинку - композицию аватарок пользователей, которую указывали бы в css атрибуте background-image у нужного html тега, а выборку из этой композиции делали бы через background-position. Иными словами - решили проблемы через классические css spritesheets. Таким образом вы бы сохранили все нужные эффекты, но при этом получили бы более оптимизированное решение.

А как уж вы там билдили бы эту картинку - вам виднее. Хоть раз в N минут, часов, дней, лет или при проверке изменилось ли что-либо с момента последнего запуска крон скрипта, или даже через собственные вебхуки. В общем, это точно заняло бы не так уж много времени.

Ответить
0

Это классный вариант. Я про него даже не подумал, но фронтендеры его рассматривали как вероятный сценарий. Однако пока не думаю, что в ближайшее время мы будем переделывать эту страницу.

Ответить
0

От себя добавлю — сохранил пару изображений с леонардо и ради любопытства прогнал через imagemin и получил -27% (jpg) и -65% (png) к размеру файла без потери качества. Я бы на этапе кропа/ресайза оптимизировал. Хотя большая часть контента это видео и гифки, уверен.

Ответить
1

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

Ответить
0

Ну и раз уж я ворвался в тред, не думали в эту сторону https://github.com/rryqszq4/ngx_php7 ?
Бенчмарки показывают солидный рост производительности. У нас похожее решение на lua работало крайне быстро.

Ответить
1

Ну там не в php проблема, а в скорости работы алгоритмов, они все небыстрые. 

Ответить
9

по закону мура в определенный момент коубом станете вы

Ответить
18

ты мог бы вставить это в виде коуба и получить +2 к иронии

Ответить
17

А если бы он не загрузился то +4

Ответить
14

А ты кто такой? Че самый умный что ли.

Ответить
4

А я не тебя спрашиваю

Ответить
7

А тут ещё умные есть?

Ответить
4

С отдельного запроса на каждую иконку в этой стене я тоже поржал (а концовка прям драматическая, пиши исчо)

Ответить
0

введёте пользовательские подсайты

Уже не введут

Ответить
9

Введем :)

Ответить
0

этого я не понял! Ты считаешь Уважаемый, Денис Сергеевич Ширяев, что подсайты важнее возможности отключения уведомлений  в определенных темах? 

Ответить
3

абсалютли

Ответить
0

не ну это МАйдан!

Ответить
0

Так подсайты то уже сделаны, админы могут создавать.

Потом починят чтобы и пользователи могли и все.
А ты тут про совсем новую фичу просишь, которую они даже сломать не успели.

Ответить
0

 ЧЕ вы такие ДУШНЫЕ?

Ответить
0

Почему? Я что то пропустил? По моему как раз самое время запускать подсайты, но только для премов.

Ответить
1

да это я так администрацию подтруниваю!

Ответить
3

Самое фиговое еще и то что эта стена каждый раз разная, то есть аватарки в разном порядке. Были бы постоянно в одном и том же, например по датам или по времени, можно было бы аватарками большой хуй нарисовать ( ͡° ͜ʖ ͡°)

Ну или чего-нить более скучное

Ответить
1

нихуя не понятно, но очень интересно

го лонгрид с подробным детальным разбором и пояснениями 

Ответить
2

Не будет никакого детального разбора, потому что это частная уникальная закрытая CMS, которая работает неизвестно на чём и как. Всё, что тут можно проанализировать, это мелкие детали/элементы/компоненты, которые можно увидеть через дев инструменты браузера и всё. А это очень малая часть всего.

Ответить
0

Почему же. Я точно помню, что они отвечали на некоторые вопросы про движок.

Ответить
0

Некоторые вопросы это далеко не открытый исходный код, где можно было бы по каждой строке пройтись и спросить "Что это за говно и зачем оно тут?".

Ответить
0

@Denis Shiryaev пост про инфраструктуру запили что ли.

Ответить
5

Выход тёмной темы звучит более реально, чем это

Ответить
1

В следующем году

Ответить
1

Обещали после нового года.
Так что ждём нового года🤔

Ответить
11

Пиздёж и провокация.

Ответить
0

Да, всё верно. Если бы был доступ к исходникам, то можно было бы тогда что-либо пилить. С публичной поркой через git blame. А без сорцов можно только внешние ресурсы подёргать за сосочки и пофейспалмить слегка

Ответить
1

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

Ответить
0

А теперь ещё и впарить другим пытаются :^)

Ответить
0

Я помню, как они к @Sergey Galyonkin  подкатывали, чтоб с EGS интегрироваться)

Ответить
14

У одних тёмнaя тeма и пользовательские подсайты, у других корзина и ачивки. А вместе они трансформируются в Аджайлмена, вооружённого МВПалкой.

Ответить
5

У меня от твоего комментария скрам головного мозга.

Ответить
0

Срочно нужно догнаться митапами и запить аджайлом.

Ответить
1

Как бы вселенная не схлопнулась после этого

Ответить
–1

Неправда, до сих пор все запросы отклоняем.

Ответить
1

Какой бы ни был движок, когда сайт растёт он перестаёт умещаться в маленькой уютной односерверной архитектуре.

Ответить
0

Да, судя по тому, что новый функционал вводится очень долго, а старый выглядит слишком наивно (привет всё тому же самому леонардо) у меня тоже складывается впечатление, что им приходится ехать на том, что уже имеют. Но расширяя парк машин они не лечат болезнь, а только симптомы

Ответить
0

У них просто большая часть штата это Циплухины, а работает один лишь @Шериф DTF.

Ответить
2

Которого наняли только полгода назад, а какие результаты - местами т.е.м.н.а.я тема, чс, сообщения, подсайты!

Ответить
0

движок изначально делали на коленке и не планировали на такой рост.

Будто бывает по-другому

Ответить
0

А если попросить боженьку включить всем функцию "не показывать меня на странице спонсоров", то он сэкономит трафик бедным работникам ДТФ?

Ответить
2

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

Ответить
0

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

Ответить
5

расти из за постоянно генерируемого пользователями контента

Значит надо забанить самых активных, всяких Труханов, и тогда проблема решится

Ответить
4

Я заслужил место интерна менеджера по проекту?

Ответить
6

Твоя идея проста и решает проблему. Когда не будет хватать денег на поддержку проекта нужно просто заходить в топ рейтинга и банить первую десятку.

@Denis Shiryaev  всё, проблема решена, можно тред удалять. Этого атома берите на работу.

Ответить
1

И Д Е А Л Ь Н О

Ответить
0

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

Ответить
–1

Для меня, как для простого юзера -  много. 

Позвольте глупый вопрос. А почему бы просто не сносить комментарии полугодовой давности оставляя лишь плюсы для пользователей?

Ответить
0

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

Ответить
0

Возможно к проблеме стоит подойти более комплексно?

На первый взгляд, все новости старше 10 дней в целом перестают генерировать трафик (По опыту личного блога).

Ответить
0

Selectel-это же ваша мат.компания ..Скидок не дают ? Или вы тут не про это ..

Ответить

Комментарий удален

Комментарий удален

0

Я уже сделал ход конем и отказался публиковать новости в своем блоге, чтобы не получать ДТФ Плюс. Бум!

Ответить
0

Спасибо, поржал.

Еще один псто для цитирования на ебаном.айти, эта неделя неплохо начинается, да

Ответить
0

Пока что лучший тред за сегодня

Ответить

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovz", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-250597-0", "render_to": "inpage_VI-250597-0-1134314964", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=clmf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudo", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "chvjx", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvc" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "chfbl", "p2": "gnwc" } } } ]
{ "jsPath": "/static/build/dtf.ru/specials/DeliveryCheats/js/all.min.js?v=05.02.2020", "cssPath": "/static/build/dtf.ru/specials/DeliveryCheats/styles/all.min.css?v=05.02.2020", "fontsPath": "https://fonts.googleapis.com/css?family=Roboto+Mono:400,700,700i&subset=cyrillic" }