Hello!

On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote:

> > > Востребованные ресурсы из push-кэша переходят в основной и будут
> > > использованы для следующих страниц.
> > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> > в
> > > кэше.
> > > В крайнем случае несложно пометить клиента стандартным способом
> > через
> > > cookie.
> >
> > Проблема в том, что даже отказ от push-ресурсов - это нагрузка как
> > на сервер, так и на канал. И статистика как бы говорит нам, что в
> > среднем эти накладные расходы - больше, чем польза.
>
> Я таковой статистикой не располагаю.

Ссылку на статистику я привёл. Если вы не располагаете другой -
вероятно, другой и нет.

> Но предполагаю, что клиенту отказаться от push'а проще, чем сделать
> дополнительный запрос к ресурсу.

По ресурсам "получить push" и "сделать дополнительный запрос и
получить на него ответ" - строго одно и то же. Разница - только во
времени, полученный push будет доступен чуть раньше, что в хорошем
случае немного сократит время до показа страницы. А в плохом -
потребует передачи по сети дополнительных данных (начала push'а и
его отмены) и приведёт к увеличению времени до показа страницы.
Именно на баланс "хороших" и "плохих" случаев и стоит смотреть.

> > Что будет конкретно в вашем случае - зависит, безусловно, от
> > конкретной нагрузки и от того, насколько "в крайнем случае
> > несложно" вам будет избежать лишних push'ей. Но, повторюсь, в
> > среднем - будет хуже, потому что "в крайнем случае" никто не
> > заморачивается. Именно поэтому я начал с вопроса пробовали ли вы
> > тестировать, что получится. Подозреваю, что от банального
> > перекладывания существующих <link rel="preload"> в push'ы -
> > станет только хуже.
>
> Да, я понял Вашу точку зрения.
> Да, узкого эксперимента я не проводил.
>
> >
> https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf
> > >
> > > Не совсем понимаю какие выводы делают авторы.
> > >
> > > Предлагают работать над приоритезацией (которая и так корректная, и
> > > регулируется preload'ом), использовать экспериментальный QUIC,
> > поддержики
> > > которого толком нет.
> >
> > Авторы ясно и однозначно показывают, что server push - в среднем
> > вредит, и в большинстве случаев лишь способ выстрелить себе в
> > ногу. И предлагают работать над другими технологиями,
> > потенциально более полезными.
> >
> > Тут важно понимать, что речь идёт про взгляд разработчиков
> > браузера, и рассказывалось это всё на HTTP working group, то есть
> > в рамках встречи людей, занимающихся разработкой протокола.
>
> Из Ваших соображений и трактовке вышеприведённого исследования складывается
> впечатление, что даже разработчики протокола не донца понимают зачем push
> нужен.
> При том, что не только они описали его в протоколе, но и сторонние
> разработчики реализовали поддержку push'а клиентах и нескольких серверах.

Зачем нужен push - все понимают. Насколько он при этом полезен
для интернета в среднем - можно выяснить только практически. Вот
есть исследование от команды одного из браузеров, которое говорит,
что в среднем - вреден.

Что до "реализовали поддержку push'а", то вот мы - всегда считали,
что полезность push'а, мягко говоря, преувеличена. Но, тем не
менее, вынуждены были реализовать, просто мотому, что пользователи
читают маркетинговые материалы, рассказывающие о новом красивом
протоколе HTTP/2 и его замечательных возможностях. А понимать,
какие недостатки есть у этих замечательных возможностей - не
пытаются.

> > (Ну и да, про приоритезацию - смешно. Нет, это не про preload,
> > это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с
> > бассейном и джакузи запроектирован в рамках стандарта, корректности
> > ждать не приходится.)
>
> Я о текущей примитивной приоретизации.
> Сомневаюсь, что когда-нибудь появятся инстументы точного управления ею,
> браузеры всё равно будут вынуждены использовать указания как рекомендацию.

Приоритизация в рамках стандарта HTTP/2 - это вполне конкретная
вещь, и именно она и упоминается в соответствующем докладе. И с
ней проблемы, именно потому она там и упоминается.

> > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на
> > практике
> > > проталкивание критических ресурсов, которые в любом случае
> > приоритетны и
> > > будут загружены для отрисовки.
> >
> > Именно с этого я и начал: попробуйте на практике на отдельных
> > страницах, без попыток вытаскивать версии ресурсов через SSI и вот
> > этого всего. Получите статистику, сравните.
> >
> > Сейчас же вы пришли и убеждаете разработчиков, что вам надо,
> > потому что оно точно будет лучше, но тестировать вы ничего не
> > тестировали и не хотите.
>
> Где именно и кого я в чём-то убеждал и убеждал в том, что мне нужно?
> Я задал вопрос о планах.

И получили на него ответ. А равно рекоменацию о том, с чего
начать, если вы вдруг считаете, что вам, тем не менее, надо.

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

> А учитывая, что использовать саму директиву http2_push затруднительно — один
> ресурс за раз, невозможность использования в if — и предвидя рекомендацию
> использовать http2_push_preload, я рассказал о том, в какую сторону пошёл и
> что уже попробовал сделать своими силами, и о том, какие возможности могли
> бы помочь в решении задачи.

Директив http2_push может быть сколько угодно. Если после
интерполяции переменных парамером оказалась пустая строка -
директива не делает ничего. То есь если хочется push'ить ресурсы
условно, то это можно сделать элементарно:

set $push "";
if ($want_push_css) {
set $push "/css/main.css";
}

http2_push $css;

Аналогично можно push'ить произвольное количество ресурсов, если
это нужно. Достаточно написать соответствующий конфиг.

> > Так это не работает. Придёте со
> > стастикой, явно показывающей плюсы - мы задумаемся над тем, как
> > облегчить вам жизнь в конфигурации с SSI. Пока же из статистике
> > есть вот только ссылка выше, из которой явно следует, что делать
> > что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно.
>
> То, о чём я рассказываю и есть эксперимент.
> Проще внедрить это на dev- или даже production-версии сайта, чем готовить
> узкие эксперименты из двух страниц.
> В случае pdocution'а можно прогнозировать значимое изменение в статистике
> загрузки страниц, в том числе по данным браузеров — в той же Метрике, Google
> Console или PageSpeed Insights.
>
> Простой эксперимент, конечно, имеет право на жизнь, но это пара страниц и
> несколько доступных браузеров и инструментов.

Ну вот для эксперимента - у вас есть все ресурсы, начиная от
собственно отдачи страниц с бекенда напрямую, без кеширования
SSI-кусков, с явно проставленными заголовками Link, и заканчивая
явной выдачей необходимых push'ей с помощью директивы http2_push.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru