Tue, Jul 14, 2015 at 20:31:48, hunter wrote about "Re: [uanog] sql traffic":
Есть портал, типа olx-а, достаточно посещаемый. Трафик исходящий примерно 50 мегабит, на этих 50 мегабит исходящего трафика к клиенту, при чем в этом трафике много графики, сервер баз данных имеет среднюю загрузку интефейса 150 мегабит.
Ситуация типичная для сайтов, где морда сайт фактически является интерфейсом к базе данных и нет кэширования или оно не возможно. Худшее, что я видел, это на 500 мегабит от базы данных отдавалось примерно пять наружу. :)
То есть внутренний трафик в 100 раз превосходил внешний? У facebook этот коэффициент около 900, по тому, что я слышал. И ничего, живут и развиваются, [редиски]. ;-\
Если в остальном производительность устраивает, то я бы не дергался.
Вопрос тут действительно в эффективности - наши сайтостроители иногда ухитряются совершенно безумные решения делать. Есть хрестоматийный пример с форумом, который просматривается этак на 200-й странице. Первый шаг: типичный представитель Duppa Govnosite Ltd. пишет SELECT {всё, что можно, с 10 каскадами JOIN} FROM topics ORDER BY topics.ts_posted DESC (очень гордясь последним словом и тем, что весь этот каскад JOIN'ов вообще смог скомпилироваться парсером выбранного SQL), и отбрасывает из начала нужное количество данных. В зависимости от настроек БД, ответы или отдаются построчно сервером (тогда это проживёт чуть дольше), или отдаются целиком клиенту и разгребаются на нём (типично для MySQL). Отлично работает на почти пустой тестовой базе, перестаёт удовлетворять после первых пары сотен тем - процессы веб-сервера просто падают (хорошо, если не роняя весь сайт). Второй шаг: получив по шее за предыдущее решение, аффтырь дочитывает до наличия потрясающих слов LIMIT и OFFSET в доступном варианте SELECT и дописывает их в предыдущее. Клиентская сторона прекращает падать. Сервер живёт некоторое время, пока объём ответа не начинает превосходить ресурсы (LIMIT+OFFSET отрабатываются уже после фильтрации по WHERE и после всех JOIN). Третий шаг: аффтырь дочитывает stackoverflow с аналогами до гениального, как ему кажется, решения: SELECT {опять всё, что можно} FROM topics WHERE msgid in (SELECT msgid FROM topics WHERE фильтры LIMIT k OFFSET n). 99% на этом и останавливаются, перебрасывая SQL-писателя на придумку новых модных тем на CSS. Пользователи, в зависимости от ситуации, или тихо ругаются, или зеленеют с разбиванием мониторов и клавиатур, от того, что вынуждены по 3-му разу читать давно прочитанные темы от того, что понятие "N первых" сменилось оттого, что спамер вкатил 100 новых тем (а потом снова сменилось назад, когда модератор их удалил, и они пропускают какие-то темы). Но Всем Пофиг (tm), потому что реклама продолжает показываться. До четвёртого шага - вместо "OFFSET n" делать "WHERE id < last_seen_id" и передавать этот самый last_seen_id в запросе HTTP вместо номера страницы - доходят считанные единицы - в чистом виде это я видел только у facebook (из чего видно, кто в нашем земном вебе работает с реальными нагрузками - а остальные только шумят). См. "aftercursorr=" в query в переходах на m.facebook.com. Кроме них, я вижу озаботившихся тем, чтобы не было таких дурных сдвигов, только разрабов ithappens.me с сиблингами: но те сделали, наоборот, фиксированную нумерацию от начала времён (а переход со входной страницы на нумерованную зафиксировали за счёт переменного размера входной - действительно умеют думать, молодцы). Садомазохистское удовольствие от использования подобных сайтов обычно усугубляется кнопками для хождения между страницами, не проверявшимися на эргономику прохода далее входной страницы. Чаще всего "вперёд" и "назад", причём "вперёд" это в прошлое (очевидно, светлое?), а "назад" это в будущее (надо полагать, мрачное и безысходное - не то шумерские плачи по Золотому Веку, не то индийская Калиюга в разгаре, в общем, неуютно - надо идти вперёд в прошлое, где поднималось то, что нужно, а не артериальное давление). То же самое "следующая страница" и "предыдущая". Но в некоторых местах (LOR), "вперёд" это в будущее, а "назад" это в прошлое (люди хотя бы немного оптимизма показали, уже хорошо). Самый хит дебилизма - "сюда"/"туда" на Хабре с аналогами (Ржевский негодует). Написать на кнопках слова, явно означающие направление времени (например, "раньше"/"позже"), это уже выходит за пределы способностей очень серого вещества... -netch-