Так это делается просто копированием параметров сборки существующего nginx, и всегда делалось. Формат вывода команды nginx -V специально для этого предназначен.
Вот ведь магия самовнушения. =) В статье вы сделали ровно то же самое — пересобрали nginx с новыми модулями, но на этот раз вам этот процесс не показался сложным.
Замечу, что все то же самое верно и в случае статических модулей, заменить только --add-dynamic-module на --add-module и не нужны будут лишние строчки в конфиге.
В вашем описании вы никак не используете приемущества динамических модулей.
Стоит в очереди задач пока без каких-либо точных сроков. Агент собирает метрики не только с NGINX, но используя различные средства операционной системы.
Пока неизвестно будет ли это платный продукт. Этот вопрос ещё обсуждается. Возможно будут какие-то гибкие политики, включая бесплатные аккаунты для небольших пользователей.
Тем у кого плохое соединение HTTP/2 не только не поможет, но и все сильно ухудшит. Потеря пакета в HTTP/1.x соединении приводит к задержке всего одного запроса, та же самая потеря в HTTP/2 тормозит все запросы. А заметное количество регулярно передаваемой туда и обратно служебной информации только умножает эту вероятность.
Использовать слово "мерял" по отношению к этой статейке на httpwatch — это какое-то издевательство. Открыть один раз страничку с google.co.uk и сделать скриншот — я даже не буду комментировать, ибо это смешно.
За время разработки модулей spdy/2, spdy/3.1 и http/2 в nginx, я собрал огромное количество статистики, отзывов, информации о работе протокола в реальных условиях и подводных камней, провел множество измерений. Некая квинтэссенция того, что можно выжать из типичного сайта с помощью HTTP/2, а именно те самые 200-300 мс показана на слайдах с прошлого доклада: слайды 58 и 59. Это на примере отлично подходящего по объектам для HTTP/2 сайта без каких-либо оптимизаций под HTTP/1.x, как то шардинга, CDN и прочего, что может негативно сказаться на результатах HTTP/2. А также без случайных потерь пакетов, которые просто смертельны для HTTP/2.
Да, конечно, с одной стороны даже 200 мс — это здорово. Но вот эти 200-300 мс разницы никак не стоят той сложности нового протокола, головной боли, которую эта сложность приносит и ресурсов которые отъедает под себя каждое HTTP/2 соединение. Учитывая, что можно было приложить голову и потратить больше времени на разработку стандарта, сделав что-то нормальное. К сожалению, с технической точки зрения протокол очень плох и решает всего одну задачу оптимизации взаимодействия браузера и сервера по TLS в условиях ограниченного числа соединений и большого числа объектов.
Современные браузеры не ждут, пока html скачается, а открывают сразу несколько соединений. Единственная их проблема, что они по-умолчанию ограничены 6 соединениями по RFC и если уж запросили какую-то картинку, то не могут остановить передачу и запросить что-то другое не разрывая соединения. Собственно на этом HTTP/2 и выигрывает, только для реализации того же не нужно было столько всего городить.
HTTP/2 server push? Вообще с ним пока все не так хорошо в браузерах (как в общем и самим протоколом), кто пытается использовать — время от времени сталкивается не с ускорением, а с багами. Реализация и отладка HTTP/2 и так отняла столько ресурсов, что на данный момент пока никаких ETA на дополнительные работы по HTTP/2.
Проверьте выполнение следующих условий:
https://github.com/nginxinc/nginx-amplify-doc/blob/master/amplify-guide.md#what-to-check-if-amplify-agent-isnt-reporting-metrics
Также стоит расширить формат логов и повысить уровень логгирования у
error_log:https://github.com/nginxinc/nginx-amplify-doc/blob/master/amplify-guide.md#additional-nginx-metrics
Так это делается просто копированием параметров сборки существующего nginx, и всегда делалось. Формат вывода команды
nginx -Vспециально для этого предназначен.Вот ведь магия самовнушения. =) В статье вы сделали ровно то же самое — пересобрали nginx с новыми модулями, но на этот раз вам этот процесс не показался сложным.
Замечу, что все то же самое верно и в случае статических модулей, заменить только
--add-dynamic-moduleна--add-moduleи не нужны будут лишние строчки в конфиге.В вашем описании вы никак не используете приемущества динамических модулей.
Всем, кто столкнулся с подобной проблемой, просьба написать в тех. поддержку указав внешний IP с которого не удается подключиться.
Будет.
[deleted]
Пакетный менеджер подсказывает, что для доступа к репозиториям по https нужно доустановить
apt-transport-https.Речь видимо о сертификатах? Ключи он трогать не пытается. Подробности тут.
Использовать абсолютный путь:
https://github.com/nginxinc/nginx-amplify-doc/blob/master/amplify-guide.md#detecting-and-monitoring-nginx-instances
Да.
Стоит в очереди задач пока без каких-либо точных сроков. Агент собирает метрики не только с NGINX, но используя различные средства операционной системы.
traceroute? Проверил из разных концов света — всё работает.
В будущем всё может быть. Проект ещё очень молодой.
На данный момент это только онлайн сервис.
Пока неизвестно будет ли это платный продукт. Этот вопрос ещё обсуждается. Возможно будут какие-то гибкие политики, включая бесплатные аккаунты для небольших пользователей.
QUIC пока что только один большой эксперимент с переизобретением сongestion сontrol и много того, что нам TCP и TLS дают практически бесплатно.
Тем у кого плохое соединение HTTP/2 не только не поможет, но и все сильно ухудшит. Потеря пакета в HTTP/1.x соединении приводит к задержке всего одного запроса, та же самая потеря в HTTP/2 тормозит все запросы. А заметное количество регулярно передаваемой туда и обратно служебной информации только умножает эту вероятность.
Использовать слово "мерял" по отношению к этой статейке на httpwatch — это какое-то издевательство. Открыть один раз страничку с google.co.uk и сделать скриншот — я даже не буду комментировать, ибо это смешно.
За время разработки модулей spdy/2, spdy/3.1 и http/2 в nginx, я собрал огромное количество статистики, отзывов, информации о работе протокола в реальных условиях и подводных камней, провел множество измерений. Некая квинтэссенция того, что можно выжать из типичного сайта с помощью HTTP/2, а именно те самые 200-300 мс показана на слайдах с прошлого доклада: слайды 58 и 59. Это на примере отлично подходящего по объектам для HTTP/2 сайта без каких-либо оптимизаций под HTTP/1.x, как то шардинга, CDN и прочего, что может негативно сказаться на результатах HTTP/2. А также без случайных потерь пакетов, которые просто смертельны для HTTP/2.
Вот BBC обнаружили, что HTTP/2 вообще не подходит для стриминга: http://www.bbc.co.uk/rd/blog/2015-07-performance-testing-results-of-adaptive-media-streaming-over-http
А здесь люди исследовали влияние различных факторов на производительность SPDY и выявили целый набор условий при которых SPDY не только не дает приемуществ, но даже и сказывается негативно: https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf
Ну и естественно, если вам просто нужно качать файлы, то вы будете разочарованы, как этот человек в списке рассылки:
http://mailman.nginx.org/pipermail/nginx-ru/2015-October/056870.html
Да, конечно, с одной стороны даже 200 мс — это здорово. Но вот эти 200-300 мс разницы никак не стоят той сложности нового протокола, головной боли, которую эта сложность приносит и ресурсов которые отъедает под себя каждое HTTP/2 соединение. Учитывая, что можно было приложить голову и потратить больше времени на разработку стандарта, сделав что-то нормальное. К сожалению, с технической точки зрения протокол очень плох и решает всего одну задачу оптимизации взаимодействия браузера и сервера по TLS в условиях ограниченного числа соединений и большого числа объектов.
HTTP/2 server push? Вообще с ним пока все не так хорошо в браузерах (как в общем и самим протоколом), кто пытается использовать — время от времени сталкивается не с ускорением, а с багами. Реализация и отладка HTTP/2 и так отняла столько ресурсов, что на данный момент пока никаких ETA на дополнительные работы по HTTP/2.