Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Hello! On Mon, Apr 27, 2020 at 04:29:44PM -0400, gz wrote: > > > Maxim Dounin Wrote: > > > --- > > > > > В HTML страницы бэкендом выдаются элементы > > с > > > > указанием > > > > > на ресурсы для предзагрузки. > > > > > Хотелось бы перейти с предзагрузки на http2_push указанных > > ресурсов. > > > > > > > > А вы пробовали тестировать, что вы получите на выходе? > > > > > > Практически не проверял, но здравый смысл подсказывает, что даже в > > рамках > > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить > > минимум > > > один запрос на получение ресурсов, объявленных в > rel="preload">. > > > > Здравый смысл тут подсказывает неправильно. Поскольку сервер не > > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт > > push'ы всегда, и тем самым расходует как канал, так и лишние > > ресурсы на сервере. Соответственно результат будет зависеть от > > того, насколько польза от push'а (сэкономленный 1 rtt при запросе > > дополнительных ресурсов у тех клиентов, у которых этих ресурсов > > нет) больше или меньше тех проблем, которые push добавляет всем > > остальным клиентам. > > Востребованные ресурсы из push-кэша переходят в основной и будут > использованы для следующих страниц. > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в > кэше. > В крайнем случае несложно пометить клиента стандартным способом через > cookie. Проблема в том, что даже отказ от push-ресурсов - это нагрузка как на сервер, так и на канал. И статистика как бы говорит нам, что в среднем эти накладные расходы - больше, чем польза. Что будет конкретно в вашем случае - зависит, безусловно, от конкретной нагрузки и от того, насколько "в крайнем случае несложно" вам будет избежать лишних push'ей. Но, повторюсь, в среднем - будет хуже, потому что "в крайнем случае" никто не заморачивается. Именно поэтому я начал с вопроса пробовали ли вы тестировать, что получится. Подозреваю, что от банального перекладывания существующих в push'ы - станет только хуже. > > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют > > предолжить, > > > > > > > что результат скорее всего будет хуже, чем то, что у вас есть > > > > сейчас. > > > > > > Я встречал обратные исследования. > > > https://dexecure.com/blog/http2-push-vs-http-preload/ > > > > По ссылке нет исследований, там только общие соображения. > > Исследования выглядят как-то так: > > > > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > Не совсем понимаю какие выводы делают авторы. > > Предлагают работать над приоритезацией (которая и так корректная, и > регулируется preload'ом), использовать экспериментальный QUIC, поддержики > которого толком нет. Авторы ясно и однозначно показывают, что server push - в среднем вредит, и в большинстве случаев лишь способ выстрелить себе в ногу. И предлагают работать над другими технологиями, потенциально более полезными. Тут важно понимать, что речь идёт про взгляд разработчиков браузера, и рассказывалось это всё на HTTP working group, то есть в рамках встречи людей, занимающихся разработкой протокола. (Ну и да, про приоритезацию - смешно. Нет, это не про preload, это, как я понимаю, про приоритеты в рамках HTTP/2. Там самолёт с бассейном и джакузи запроектирован в рамках стандарта, корректности ждать не приходится.) > > > Плюс у push шире поддерживается. > > > > Я бы не был столь категоричен. > > Нет никакой категоричности: > https://caniuse.com/#search=rel%20preload — 84% > https://caniuse.com/#feat=http2 — 94% > > Не совсем корректное сравнение точно preload vs push, тем не менее. Ну вот это сравнение - говорит о минимальной разнице, и при этом мы не знаем, сколько в том http2 поддержики push'а, и не знаем, сколько глюков там, где она таки есть. > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике > проталкивание критических ресурсов, которые в любом случае приоритетны и > будут загружены для отрисовки. Именно с этого я и начал: попробуйте на практике на отдельных страницах, без попыток вытаскивать версии ресурсов через SSI и вот этого всего. Получите статистику, сравните. Сейчас же вы пришли и убеждаете разработчиков, что вам надо, потому что оно точно будет лучше, но тестировать вы ничего не тестировали и не хотите. Так это не работает. Придёте со стастикой, явно показывающей плюсы - мы задумаемся над тем, как облегчить вам жизнь в конфигурации с SSI. Пока же из статистике есть вот только ссылка выше, из которой явно следует, что делать что-либо для лучше поддержки HTTP/2 push - в среднем бессмысленно. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> В крайнем случае несложно пометить клиента стандартным способом через > cookie. Советую смотреть не на куки, а на наличия клиенских заголовков - If-None-Match и/или If-Modified-Since, только при отсутствии или не валидности данных заголовков делать push. Из нашего опыта - push полезен только для клиентов у которых нет валидного кеша, в этом случаи вы получите не большой прирост в скорости около 5-10%. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287855#msg-287855 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Nginx перенаправление на другой адрес
Здравствуйте друзья, есть сервер "03" на нем стоит Nginx. Я хочу чтобы он
делал все поиски которые осуществляются на яндексе перенаправлялись на гугл,
со всем компутеров в домене
Код
worker_processes 1;
error_log logs/error.log;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
gzip on;
server {
listen 80;
server_name ya.ru www.ya.ru;
return 301 https://www.google.ru;
}
}
Но оно не работает так как Я хочу.
В логах
Код
2020/04/22 10:44:29 [notice] 2184#1820: signal process started
Допустим название сервера "Третий"
Обращаюсь к нему со своего компа http://Трейти/new-name
При обращение Я получаю к "Трейтий" Я уже получаю доступ к адресу
http://192.168.1.1/new-name.
То есть все запросы которые идут на http://третий .. используютися на
локальных компутерах как http://192.168.1.1/new-name.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,287854,287854#msg-287854
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
вт, 28 апр. 2020 г. в 01:29, gz : > > > Maxim Dounin Wrote: > > > --- > > > > > В HTML страницы бэкендом выдаются элементы > > с > > > > указанием > > > > > на ресурсы для предзагрузки. > > > > > Хотелось бы перейти с предзагрузки на http2_push указанных > > ресурсов. > > > > > > > > А вы пробовали тестировать, что вы получите на выходе? > > > > > > Практически не проверял, но здравый смысл подсказывает, что даже в > > рамках > > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить > > минимум > > > один запрос на получение ресурсов, объявленных в > rel="preload">. > > > > Здравый смысл тут подсказывает неправильно. Поскольку сервер не > > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт > > push'ы всегда, и тем самым расходует как канал, так и лишние > > ресурсы на сервере. Соответственно результат будет зависеть от > > того, насколько польза от push'а (сэкономленный 1 rtt при запросе > > дополнительных ресурсов у тех клиентов, у которых этих ресурсов > > нет) больше или меньше тех проблем, которые push добавляет всем > > остальным клиентам. > > Востребованные ресурсы из push-кэша переходят в основной и будут > использованы для следующих страниц. > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в > кэше. > В крайнем случае несложно пометить клиента стандартным способом через > cookie. > > > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют > > предолжить, > > > > > > > что результат скорее всего будет хуже, чем то, что у вас есть > > > > сейчас. > > > > > > Я встречал обратные исследования. > > > https://dexecure.com/blog/http2-push-vs-http-preload/ > > > > По ссылке нет исследований, там только общие соображения. > > Исследования выглядят как-то так: > > > > > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > > Не совсем понимаю какие выводы делают авторы. > > Предлагают работать над приоритезацией (которая и так корректная, и > регулируется preload'ом), использовать экспериментальный QUIC, поддержики > которого толком нет. > > > > Плюс у push шире поддерживается. > > > > Я бы не был столь категоричен. > > Нет никакой категоричности: > https://caniuse.com/#search=rel%20preload — 84% > https://caniuse.com/#feat=http2 — 94% > > Не совсем корректное сравнение точно preload vs push, тем не менее. > > Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике > проталкивание критических ресурсов, которые в любом случае приоритетны и > будут загружены для отрисовки. > я бы с интересом посмотрел на аналитику, которая привела к такому развитию событий. какие метрики вы с приложения снимаете, методика, всё вот это. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287846,287852#msg-287852 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
> > Maxim Dounin Wrote: > > --- > > > > В HTML страницы бэкендом выдаются элементы > с > > > указанием > > > > на ресурсы для предзагрузки. > > > > Хотелось бы перейти с предзагрузки на http2_push указанных > ресурсов. > > > > > > А вы пробовали тестировать, что вы получите на выходе? > > > > Практически не проверял, но здравый смысл подсказывает, что даже в > рамках > > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить > минимум > > один запрос на получение ресурсов, объявленных в rel="preload">. > > Здравый смысл тут подсказывает неправильно. Поскольку сервер не > знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт > push'ы всегда, и тем самым расходует как канал, так и лишние > ресурсы на сервере. Соответственно результат будет зависеть от > того, насколько польза от push'а (сэкономленный 1 rtt при запросе > дополнительных ресурсов у тех клиентов, у которых этих ресурсов > нет) больше или меньше тех проблем, которые push добавляет всем > остальным клиентам. Востребованные ресурсы из push-кэша переходят в основной и будут использованы для следующих страниц. Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся в кэше. В крайнем случае несложно пометить клиента стандартным способом через cookie. > > > Имеющиеся исследования про эффективность HTTP/2 push позволяют > предолжить, > > > > > что результат скорее всего будет хуже, чем то, что у вас есть > > > сейчас. > > > > Я встречал обратные исследования. > > https://dexecure.com/blog/http2-push-vs-http-preload/ > > По ссылке нет исследований, там только общие соображения. > Исследования выглядят как-то так: > > https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf Не совсем понимаю какие выводы делают авторы. Предлагают работать над приоритезацией (которая и так корректная, и регулируется preload'ом), использовать экспериментальный QUIC, поддержики которого толком нет. > > Плюс у push шире поддерживается. > > Я бы не был столь категоричен. Нет никакой категоричности: https://caniuse.com/#search=rel%20preload — 84% https://caniuse.com/#feat=http2 — 94% Не совсем корректное сравнение точно preload vs push, тем не менее. Я прекрасно понимаю, что push — не панацея, и хотел попробовать на практике проталкивание критических ресурсов, которые в любом случае приоритетны и будут загружены для отрисовки. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287852#msg-287852 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Hello! On Mon, Apr 27, 2020 at 02:44:26PM -0400, gz wrote: > Maxim Dounin Wrote: > --- > > > В HTML страницы бэкендом выдаются элементы с > > указанием > > > на ресурсы для предзагрузки. > > > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. > > > > А вы пробовали тестировать, что вы получите на выходе? > > Практически не проверял, но здравый смысл подсказывает, что даже в рамках > HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить минимум > один запрос на получение ресурсов, объявленных в . Здравый смысл тут подсказывает неправильно. Поскольку сервер не знает, какие ресурсы уже есть у клиента, а каких ещё нет, он шлёт push'ы всегда, и тем самым расходует как канал, так и лишние ресурсы на сервере. Соответственно результат будет зависеть от того, насколько польза от push'а (сэкономленный 1 rtt при запросе дополнительных ресурсов у тех клиентов, у которых этих ресурсов нет) больше или меньше тех проблем, которые push добавляет всем остальным клиентам. > > Имеющиеся исследования про эффективность HTTP/2 push позволяют предолжить, > > > что результат скорее всего будет хуже, чем то, что у вас есть > > сейчас. > > Я встречал обратные исследования. > https://dexecure.com/blog/http2-push-vs-http-preload/ По ссылке нет исследований, там только общие соображения. Исследования выглядят как-то так: https://github.com/httpwg/wg-materials/blob/gh-pages/ietf102/chrome_push.pdf > Плюс у push шире поддерживается. Я бы не был столь категоричен. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Maxim Dounin Wrote: --- > > В HTML страницы бэкендом выдаются элементы с > указанием > > на ресурсы для предзагрузки. > > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. > > А вы пробовали тестировать, что вы получите на выходе? Практически не проверял, но здравый смысл подсказывает, что даже в рамках HTTP2 проталкивание ресурсов в первом запросе позволит сэкономить минимум один запрос на получение ресурсов, объявленных в . > Имеющиеся исследования про эффективность HTTP/2 push позволяют предолжить, > что результат скорее всего будет хуже, чем то, что у вас есть > сейчас. Я встречал обратные исследования. https://dexecure.com/blog/http2-push-vs-http-preload/ Плюс у push шире поддерживается. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287846,287848#msg-287848 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx + php-fpm = баг?
Сгораю от стыда - дело было в количестве воркеров :) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287839,287847#msg-287847 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: http2 push — не планируется ли поддержка по аналогии с заголовком Link?
Hello! On Mon, Apr 27, 2020 at 09:33:08AM -0400, gz wrote: > В HTML страницы бэкендом выдаются элементы с указанием > на ресурсы для предзагрузки. > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. А вы пробовали тестировать, что вы получите на выходе? Имеющиеся исследования про эффективность HTTP/2 push позволяют предолжить, что результат скорее всего будет хуже, чем то, что у вас есть сейчас. [...] > Нет ли в планах поддерживать преобразования в > http2_push? Нет, такого в планах нет. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx + php-fpm = баг?
27.04.2020 16:38, grey пишет: Приветствую всех! Прежде чем создавать топик, перепроверил всё несколько раз, но объяснения такого поведения nginx найти не смог. Суть проблемы: если из php-скрипта со своего сервера я обращаюсь посредством curl или fopen к своему же сайту, то получаю ошибку "504 Gateway Time-out". Если выполнить в консоли сервера "php /www/test.ru/1.php", то скрипт вернет html-страницу сервера. Если открыть в браузере адрес test.ru/1.php, то сайт будет какое-то время думать, а по прошествию таймаута вернет "504 Gateway Time-out" (пока сайт будет думать, в лог будут сыпаться ошибки 2020/04/27 15:02:09 [error] 6540#6968: *960636 connect() failed (10061: No connection could be made because the target machine actively refused it) while connecting to upstream, client: 5.34.*.*, server: test.ru, request: "GET / HTTP/2.0", upstream: "fastcgi://127.0.0.1:9123", host: "test.ru", referrer: "http://***.ru/;). Если в скрипте заменить адрес сервера test.ru на любой другой внешний, пусть будет ya.ru, то и в консоли и в браузере все открывает без ошибок. Из чего я делаю вывод, php тут не при чем, затык именно в nginx. nginx не самой последней версии - 1.17.3 и обновить пока не могу, php 7.3.х - тоже самая последняя версия. А почему в нгинксе, а не в php. сделайте запрос за статичным файлом к тому же нгинксу, который отдаётся не через php. Воркеров php сколько ? точно >1? /А ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx + php-fpm = баг?
Приветствую всех!
Прежде чем создавать топик, перепроверил всё несколько раз, но объяснения
такого поведения nginx найти не смог.
Суть проблемы: если из php-скрипта со своего сервера я обращаюсь посредством
curl или fopen к своему же сайту, то получаю ошибку "504 Gateway Time-out".
Если выполнить в консоли сервера "php /www/test.ru/1.php", то скрипт вернет
html-страницу сервера. Если открыть в браузере адрес test.ru/1.php, то сайт
будет какое-то время думать, а по прошествию таймаута вернет "504 Gateway
Time-out" (пока сайт будет думать, в лог будут сыпаться ошибки
2020/04/27 15:02:09 [error] 6540#6968: *960636 connect() failed (10061: No
connection could be made because the target machine actively refused it)
while connecting to upstream, client: 5.34.*.*, server: test.ru, request:
"GET / HTTP/2.0", upstream: "fastcgi://127.0.0.1:9123", host: "test.ru",
referrer: "http://***.ru/;). Если в скрипте заменить адрес сервера test.ru
на любой другой внешний, пусть будет ya.ru, то и в консоли и в браузере все
открывает без ошибок. Из чего я делаю вывод, php тут не при чем, затык
именно в nginx. nginx не самой последней версии - 1.17.3 и обновить пока не
могу, php 7.3.х - тоже самая последняя версия.
Конфиг nginx-а минимальный.
server {
server_name test.ru;
location ~ \.(php|html)$ {
fastcgi_pass 127.0.0.1:9123;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
includefastcgi_params;
}
}
Сам скрипт, который вызывает проблему:
https://test.ru/;);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HEADER, 1);
curl_setopt($ch, CURLOPT_NOBODY, 0);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE);
$$contents=curl_exec ($ch);
curl_close ($ch);
/*
или вариант без curl-а
$handle = fopen("https://test.ru;, "rb");
$contents = stream_get_contents($handle);
fclose($handle);
*/
echo $contents;
?>
Может это я где-то туплю, но где понять не могу и почему смена адреса решает
проблему?
Просьба проверить у себя.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,287839,287839#msg-287839
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
http2 push — не планируется ли поддержка по аналогии с заголовком Link?
В HTML страницы бэкендом выдаются элементы с указанием на ресурсы для предзагрузки. Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. Казалось бы, нет проблемы перейти на заголовок Link, который модулем ngx_http_v2_module при http2_push_preload on будет преобразован в push'и. Однако, в путях к ресурсам используются SSI-вставки с текущими версиями, а HTML вместе в SSI-директивами хранится в кэше. Условно: " as="style"/> … "/> … … А после работы SSI получаем нужный результат: … … … Выходит, поможет либо поддержка SSI в заголовках ответа — чего nginx не умеет, либо поддержка модулем ngx_http_v2_module преобразования в http2_push. Посмотрел, было, в строну njs в надежде что смогу процессить тело ответа после SSI, выкусывать оттуда , преобразовывать их в Link-заголовки, которые затем будут преобразованы в ngx_http_v2_module в push'и, но в js_content тело ответа оказалось пустым, а js_filter работает на уровне stream'а. Так же попробовал использовать js_set для формирования заголовка Link на основе в теле, но в этом случае в теле в теле сохранятся и неясно как поведёт себя браузер при получении и preload-инструкций и http2_push'а. Нет ли в планах поддерживать преобразования в http2_push? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287838,287838#msg-287838 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
