Вообще это довольно востребованная функциональность. Как простой пример, php-fpm не может вместить в себя бесконечное количество параллельно обрабатываемых запросов - просто память закончится. Поэтому число рабочих процессов ограничено сверху. И вместо того, чтобы пытаться наливать запросы сверх этого числа - более разумной стратегией будет выставить ограничение на балансировщике, чтобы тот не пытался наливать больше, чем позволяет ёмкость бекенда, тогда лишние запросы можно либо отсекать, либо складывать во временную очередь и далее направлять на первый освободившийся сервер (что и делает "queue").
Всё это верно в той или иной степени относительно любого балансируемого бекенда. Ресурсы бекендов не безграничны, в том числе поэтому их разворачивают несколько и горизонтально пытаются масштабировать.
> Думается, что если бы это было нужной многим фичей, то оно было бы в разных проксях доступно.
Оно доступно во многих серьезных балансировщиков крупных вендоров и появилось не на пустом месте.
А в тексте вроде это указано в конце соответствующих абзацев про эти модули: "Модуль "queue" создаёт .. Модуль существует для HTTP подсистемы и доступен в составе коммерческих продуктов Angie." и "Модуль активных проверок называется "upstream_probe" и доступен в составе коммерческих продуктов Angie.".
С точки зрения возможностей запуска процессов приложений - да. Производительность предполагается даже выше чем Unit отдельно и заметно выше, чем связка nginx+unit или любая другая комбинация с ним.
Или не работает, если есть какие-то конфликты или загружаются какие-то модули (модули от nginx не могут быть загружены в Angie, а пути к ним указываются в конфигах).
Как раз идея была в том, что не нужно сносить и останавливать nginx, а переход осуществляется плавно, предварительно протестировав и убедившись, что всё работает - уже далее переключать обработку запросов с nginx на Angie, сохраняя возможность в любой момент откатить обратно, если что-то пойдет не так.
Текущий подход позволяет мигрировать сохраняя конфигурацию nginx в первозданном виде и не удаляя его модулей из системы.
У нас SemVer по сути, т.е. 1.X.Y, где X обозначает основные обратно совместимые релизы новой функциональности, а Y - багфиксы. Стабильной и актуальной является единственная самая последняя версия на момент времени (на момент написания этого комментария - это 1.7.0).
Не стоит обманываться названием "стабильной" ветки nginx. Это просто неудачное название для legacy-ветки, из-за которого в своем блоге компания постоянно пыталась объяснять что "We generally recommend using the mainline branch". Стабильность стабильной ветки заключалась лишь в том, что это была замороженная на год произвольная версия, что давало время сторонним разработчикам адаптировать свой код, а тем, кто вынужден эти модули использовать - получать портированные из основной ветки исправления критических ошибок (где эти исправления появлялись одновременно или даже раньше).
Какой-то особой стабильности с точки зрения пользователя - там не было и не могло быть, поскольку она рождалась в результате ежегодного ритуала, когда просто текущий "mainline" релиз становился "stable", но в нем точно также содержались, как довольно старые фичи, добавленные год назад, так и самые свежие, добавленные только в последних версиях. В действительности, нечетные релизы зачастую были более стабильны просто за счет того, что там было больше актуальных исправлений и появлялись они раньше.
Поэтому всем рекомендовалось использовать именно нечетную ветку, если только у вас нет зависимости от какого-то стороннего модуля, который может сломаться. Более того, коммерческая версия NGINX Plus выпускалась на базе именно mainline ветки.
В сухом остатке - все релизы nginx - это стабильные релизы. А четные - это просто замороженные версии с возрастом от 0 до года.
У нас такой нужды в legacy-ветке нет, т.к. большинство популярных сторонних модулей мы собираем сами в своем репозитории под практически все мало-мальски популярные дистрибутивы и, при необходимости, сами их патчим.
Ошибки - это всегда неприятно и требуют исправления. К сожалению, не все ошибки в nginx можно легко исправить, некоторые из них имеют архитектурную природу. Но благо, как правило, такого рода ошибки не являются критичными.
Согласно Википедии, у Netflix 277 млн пользователей, т.е. получается на весь Netflix должно быть 20 стримящих серверов.
У Netflix-а около 18 000 серверов. У вас все расчеты имеют очень мало отношения к практике. Поэтому тут даже обсуждать нечего - всё это какие-то теоретические рассуждения исходя из того, что вам выдал чатгпт.
Я когда читал о протоколах мне показалось странным, что QUIC был уже два года на момент выхода HTTP/2
Вы что-то путаете. Финальная версия спецификации HTTP/2 появилась в мае 2015 году, а первый черновик в 2012.
QUIC стали придумывать ровно после того, как стала понятна неэффективность HTTP/2. Первый черновик спецификации на QUIC появился в в конце 2016, а финальная версия в 2021.
Стоимость шифрования упала, а объем HTTP-трафика также вырос в разы.
10 ГБ/с и 10 тыс. хендшейков это довольно мало для крупных сервисов. Вы очень странно пересчитали это в пользователей - оно разумеется не так и столько пользователей вы с такой низкой производительностью не обслужите.
Для сравнения, Netflix на своих серверах вынужден добиваться пиковой производительности до 800 Гб/c и таких серверов у них более десяти тысяч по всему миру.
Всего мировой трафик измеряется десятками эксабайт в день и немалую его часть составляет HTTP. Речь идет о протоколе, который будет использоваться отнюдь не на одном сервере, а во всей глобальной сети интернет. И тут стоит задуматься о том, какой вклад протокол вносит уже в энергопотребление всего человечества. По некоторым подсчетам: "20% of the world’s total electricity consumption may be used by the Internet by 2025" - в этот процент конечно входят затраты не только на передачу данных, но все равно она впечатляет и думать об энергоэффективности протокола имеет смысл.
Это один момент. А второй момент, заметная часть HTTP-клиентов - это мобильные устройства, где вопрос энергоэффективности также один из краеугольных сам по себе.
P.S. И спустя 10 лет можно с уверенностью сказать, что мистер Камп оказался во многом прав. Протокол HTTP/2 показал себя с не лучшей стороны, уязвимости в нем и вектора для DoS атак продолжают находить пачками по сей день. Пресловутый инновационный "server push" все браузеры повыкидывали, наигравшись и признав, что от этой технологии больше вреда нежели пользы, а работоспособность самого протокола в реальном мире оказалась местами хуже HTTP/1.1, что спешно начали изобретать замену в виде HTTP/3. Т.е. HTTP/2 не просуществовал и нескольких лет до того момента, как потребовалось создавать ему преемника.
man-pages - это не утилита. Это просто проект по документированию интерфейсов Linux-ядра и glibc (набор документации в формате понятном для утилиты man).
Отдельно есть утилита man и странички man по другим разделам, проектам, командам и т.д. - их разработкой и сопровождением занимаются другие люди.
Если man пропадет, для меня это будет катастрофой.
Так воспользуйтесь man, чтобы узнать кто же автор man/man-db. Не путать их с man-pages. Или хотя бы зайдите в репозиторий, чтобы посмотреть, кто же контрибьютер: https://gitlab.com/man-db/man-db/-/graphs/main?ref_type=heads - не сложно понять, что упомянутый Алехандро не имеет к самой утилите man никакого отношения.
The current man-pages maintainer is (since 2004) Michael Kerrisk (mtk.manpages@gmail.com; blog); starting in 2020, Alejandro Colomar (alx.manpages@gmail.com) has joined as comaintainer.
И похоже автор новости путает man-pages с man-db и утилитой man. Разрабочтик утилиты man с 2001 года и по сей день - Колин Ватсон.
График "Available burst tokens" на картинке "rate=2, burst=2" - неверен. На самом деле он должен быть таким же, как на последней картинке с nodelay.
Само наличие или отсутствие параметра nodelay никак не влияет на burst. При обработке запросов, которые попали в burst и отмечены желтым на картинке - доступные burst-токены должны прибавляться.
Для начала у всех комментаторов пишущих про "срубить бабла с государства" хочется спросить, хотя бы просто для расширения своего кругозора, а как это сделать? Расскажите, если у вас такой опыт имеется и видите сразу сходу такую перспективу. Отдельно интересно, как это сделать на OSS версии и зачем в таком случае вообще выпускать какую-то OSS версию? Есть у меня подозрения, что среди пишущих подобные комментарии нет никого, кто сам бы пытался вот так прийти и продать что-то в госкомпанию, либо получить какой-то грант от государства. Если коротко, это не секрет полишинеля, что хуже и труднее заказчика, чем госзаказчик для частного бизнеса - придумать сложно. Для компаний с участием государства возможно всё иначе, но я в таких не работал, не знаю.
А второй момент в том, что независимо от того, заинтересуются ли какие-нибудь госы нашим продуктом или нет - хочется продолжать разрабатывать достаточно хороший и проверенный временем веб-сервер, продолжать успешно применять свой опыт и знания в той сфере и в том продукте, где есть наибольшие компетенции. Если бы можно было продолжать разрабатывать nginx, мы бы сидели и спокойно продолжали его разрабатывать, никто бы и пальцем не пошевелил, никакого Angie не возникло. Но это вообще не наше решение. Это решение компании, которая владеет сейчас nginx, и довольно очевидно, что это её решение было принято не ради импортозамещения в России.
> Angie (и ещё тысячи “российских” продуктов из известного реестра т.н. “отечественного ПО”) вряд ли бы появился, кабы не принятый закон об импортозамещении (сослагательное наклонение призвано вполне недвусмысленно показать, что я этого не утверждаю, а лишь предполагаю/допускаю).
А Angie в реестре и не присутствует. В нем только Angie PRO.
Ссылаясь на этот закон, компании прекрасно используют nginx. Для OSS присутствие в реестре не дает примерно ничего, поэтому Angie OSS в реестре и не присутствует. Для не OSS пока тоже особо не дает, при наличии OSS аналога. Зато если не присутствуешь, то на твою коммерческую версию даже смотреть не будут.
Исходя из этого, по факту реестр отечественного ПО не особо работает, тем более в нашем случае.
Но мне интересно, почему вы написали определенные слова и в кавычках? Присутствие в данном реестре - это не какая-то формальность, из него и исключить могут. Это не означает, что все строчки кода ПО, которое там находится - были написаны в России, хотя для nginx это даже на 99% именно так. Но это означает прежде всего, что есть некая компания, некое юр.лицо в российской юрисдикции, которое может понести вполне себе не "ответственность", а ОТВЕТСТВЕННОСТЬ по всей строгости, если вдруг что. Как на мой взгляд, это вполне себе в духе отечества, чтобы не писать это слово в кавычках применительно к реестру. Готовы на себя такую ответственность за какой-нибудь продукт взять просто так?
Поднятие бабла с госов и военки в США с некоторых пор стало совсем невозможно совместить с наличием офиса в России. Поэтому проще всех уволить и закрыть офис, что и предопределило появление Angie.
Потому, что это ближе по концепции к LTS. Т.е. каждый mainline релиз является стабильным, просто некоторые из них получают продленный на год срок поддержки и исправления критических ошибок.
И если у кого-то ещё остаются какие-то сомнения по поводу стабильности и позиционирования mainline ветки, то отдельно обращу внимание на то, как появляется очередная stable ветка: раз в год, обычно весной, текущая mainline ветка превращается в очередную stable ветку, при этом не имеет никакого значения, что какие-то функции и модули там уже почти год, а какие-то были добавлены за месяц до того. И ничего другого не происходит, никакой стабилизации кода, никаких дополнительных тестов - это просто ежегодное чисто формальное мероприятие от которого код не становится каким-то магическим образом более стабилен, чем был до того.
И "экспериментальность" отдельных модулей и функций - тут тоже совершенно ортогональная история. От переименования mainline ветки в очередную stable - "экспериментальные" модули и функции не перестают быть экспериментальными. Так, например, perl-модуль является экспериментальным с момента своего появления (в версии 0.3.21, выпущенной ещё в 2006 году) и по сей день. Т.е. этот "экспериментальный" модуль входит во все stable ветки за последние 18 лет.
Вообще это довольно востребованная функциональность. Как простой пример, php-fpm не может вместить в себя бесконечное количество параллельно обрабатываемых запросов - просто память закончится. Поэтому число рабочих процессов ограничено сверху. И вместо того, чтобы пытаться наливать запросы сверх этого числа - более разумной стратегией будет выставить ограничение на балансировщике, чтобы тот не пытался наливать больше, чем позволяет ёмкость бекенда, тогда лишние запросы можно либо отсекать, либо складывать во временную очередь и далее направлять на первый освободившийся сервер (что и делает "queue").
Всё это верно в той или иной степени относительно любого балансируемого бекенда. Ресурсы бекендов не безграничны, в том числе поэтому их разворачивают несколько и горизонтально пытаются масштабировать.
> Думается, что если бы это было нужной многим фичей, то оно было бы в разных проксях доступно.
Оно доступно во многих серьезных балансировщиков крупных вендоров и появилось не на пустом месте.
А в тексте вроде это указано в конце соответствующих абзацев про эти модули: "Модуль "queue" создаёт .. Модуль существует для HTTP подсистемы и доступен в составе коммерческих продуктов Angie." и "Модуль активных проверок называется "upstream_probe" и доступен в составе коммерческих продуктов Angie.".
error_logв режимеdebugбыл всегда. Или что вы имеете в виду?С точки зрения возможностей запуска процессов приложений - да. Производительность предполагается даже выше чем Unit отдельно и заметно выше, чем связка nginx+unit или любая другая комбинация с ним.
Или не работает, если есть какие-то конфликты или загружаются какие-то модули (модули от nginx не могут быть загружены в Angie, а пути к ним указываются в конфигах).
Как раз идея была в том, что не нужно сносить и останавливать nginx, а переход осуществляется плавно, предварительно протестировав и убедившись, что всё работает - уже далее переключать обработку запросов с nginx на Angie, сохраняя возможность в любой момент откатить обратно, если что-то пойдет не так.
Текущий подход позволяет мигрировать сохраняя конфигурацию nginx в первозданном виде и не удаляя его модулей из системы.
При запуске всегда можно передать опцию
-cи изменить путь к конфигурационному файлу.У нас SemVer по сути, т.е. 1.X.Y, где X обозначает основные обратно совместимые релизы новой функциональности, а Y - багфиксы. Стабильной и актуальной является единственная самая последняя версия на момент времени (на момент написания этого комментария - это 1.7.0).
Не стоит обманываться названием "стабильной" ветки nginx. Это просто неудачное название для legacy-ветки, из-за которого в своем блоге компания постоянно пыталась объяснять что "We generally recommend using the mainline branch". Стабильность стабильной ветки заключалась лишь в том, что это была замороженная на год произвольная версия, что давало время сторонним разработчикам адаптировать свой код, а тем, кто вынужден эти модули использовать - получать портированные из основной ветки исправления критических ошибок (где эти исправления появлялись одновременно или даже раньше).
Какой-то особой стабильности с точки зрения пользователя - там не было и не могло быть, поскольку она рождалась в результате ежегодного ритуала, когда просто текущий "mainline" релиз становился "stable", но в нем точно также содержались, как довольно старые фичи, добавленные год назад, так и самые свежие, добавленные только в последних версиях. В действительности, нечетные релизы зачастую были более стабильны просто за счет того, что там было больше актуальных исправлений и появлялись они раньше.
Поэтому всем рекомендовалось использовать именно нечетную ветку, если только у вас нет зависимости от какого-то стороннего модуля, который может сломаться. Более того, коммерческая версия NGINX Plus выпускалась на базе именно mainline ветки.
В сухом остатке - все релизы nginx - это стабильные релизы. А четные - это просто замороженные версии с возрастом от 0 до года.
У нас такой нужды в legacy-ветке нет, т.к. большинство популярных сторонних модулей мы собираем сами в своем репозитории под практически все мало-мальски популярные дистрибутивы и, при необходимости, сами их патчим.
Придерживаемся.
Ошибки - это всегда неприятно и требуют исправления. К сожалению, не все ошибки в nginx можно легко исправить, некоторые из них имеют архитектурную природу. Но благо, как правило, такого рода ошибки не являются критичными.
У Netflix-а около 18 000 серверов. У вас все расчеты имеют очень мало отношения к практике. Поэтому тут даже обсуждать нечего - всё это какие-то теоретические рассуждения исходя из того, что вам выдал чатгпт.
Вы что-то путаете. Финальная версия спецификации HTTP/2 появилась в мае 2015 году, а первый черновик в 2012.
QUIC стали придумывать ровно после того, как стала понятна неэффективность HTTP/2. Первый черновик спецификации на QUIC появился в в конце 2016, а финальная версия в 2021.
Стоимость шифрования упала, а объем HTTP-трафика также вырос в разы.
10 ГБ/с и 10 тыс. хендшейков это довольно мало для крупных сервисов. Вы очень странно пересчитали это в пользователей - оно разумеется не так и столько пользователей вы с такой низкой производительностью не обслужите.
Для сравнения, Netflix на своих серверах вынужден добиваться пиковой производительности до 800 Гб/c и таких серверов у них более десяти тысяч по всему миру.
Всего мировой трафик измеряется десятками эксабайт в день и немалую его часть составляет HTTP. Речь идет о протоколе, который будет использоваться отнюдь не на одном сервере, а во всей глобальной сети интернет. И тут стоит задуматься о том, какой вклад протокол вносит уже в энергопотребление всего человечества. По некоторым подсчетам: "20% of the world’s total electricity consumption may be used by the Internet by 2025" - в этот процент конечно входят затраты не только на передачу данных, но все равно она впечатляет и думать об энергоэффективности протокола имеет смысл.
Это один момент. А второй момент, заметная часть HTTP-клиентов - это мобильные устройства, где вопрос энергоэффективности также один из краеугольных сам по себе.
P.S. И спустя 10 лет можно с уверенностью сказать, что мистер Камп оказался во многом прав. Протокол HTTP/2 показал себя с не лучшей стороны, уязвимости в нем и вектора для DoS атак продолжают находить пачками по сей день. Пресловутый инновационный "server push" все браузеры повыкидывали, наигравшись и признав, что от этой технологии больше вреда нежели пользы, а работоспособность самого протокола в реальном мире оказалась местами хуже HTTP/1.1, что спешно начали изобретать замену в виде HTTP/3. Т.е. HTTP/2 не просуществовал и нескольких лет до того момента, как потребовалось создавать ему преемника.
man-pages - это не утилита. Это просто проект по документированию интерфейсов Linux-ядра и glibc (набор документации в формате понятном для утилиты man).
Отдельно есть утилита man и странички man по другим разделам, проектам, командам и т.д. - их разработкой и сопровождением занимаются другие люди.
Так воспользуйтесь man, чтобы узнать кто же автор man/man-db. Не путать их с man-pages. Или хотя бы зайдите в репозиторий, чтобы посмотреть, кто же контрибьютер: https://gitlab.com/man-db/man-db/-/graphs/main?ref_type=heads - не сложно понять, что упомянутый Алехандро не имеет к самой утилите man никакого отношения.
Непонятно, почему Керриск назван предыдущим сопровождающим.
Он никуда и не уходил.
https://www.kernel.org/doc/man-pages/maintaining.html
The current man-pages maintainer is (since 2004) Michael Kerrisk (mtk.manpages@gmail.com; blog); starting in 2020, Alejandro Colomar (alx.manpages@gmail.com) has joined as comaintainer.
И похоже автор новости путает man-pages с man-db и утилитой man. Разрабочтик утилиты man с 2001 года и по сей день - Колин Ватсон.
График "Available burst tokens" на картинке "rate=2, burst=2" - неверен. На самом деле он должен быть таким же, как на последней картинке с nodelay.
Само наличие или отсутствие параметра nodelay никак не влияет на burst. При обработке запросов, которые попали в burst и отмечены желтым на картинке - доступные burst-токены должны прибавляться.
Для начала у всех комментаторов пишущих про "срубить бабла с государства" хочется спросить, хотя бы просто для расширения своего кругозора, а как это сделать? Расскажите, если у вас такой опыт имеется и видите сразу сходу такую перспективу. Отдельно интересно, как это сделать на OSS версии и зачем в таком случае вообще выпускать какую-то OSS версию? Есть у меня подозрения, что среди пишущих подобные комментарии нет никого, кто сам бы пытался вот так прийти и продать что-то в госкомпанию, либо получить какой-то грант от государства. Если коротко, это не секрет полишинеля, что хуже и труднее заказчика, чем госзаказчик для частного бизнеса - придумать сложно. Для компаний с участием государства возможно всё иначе, но я в таких не работал, не знаю.
А второй момент в том, что независимо от того, заинтересуются ли какие-нибудь госы нашим продуктом или нет - хочется продолжать разрабатывать достаточно хороший и проверенный временем веб-сервер, продолжать успешно применять свой опыт и знания в той сфере и в том продукте, где есть наибольшие компетенции. Если бы можно было продолжать разрабатывать nginx, мы бы сидели и спокойно продолжали его разрабатывать, никто бы и пальцем не пошевелил, никакого Angie не возникло. Но это вообще не наше решение. Это решение компании, которая владеет сейчас nginx, и довольно очевидно, что это её решение было принято не ради импортозамещения в России.
> Angie (и ещё тысячи “российских” продуктов из известного реестра т.н.
“отечественного ПО”) вряд ли бы появился, кабы не принятый закон об
импортозамещении (сослагательное наклонение призвано вполне недвусмысленно показать, что я этого не утверждаю, а лишь предполагаю/допускаю).
А Angie в реестре и не присутствует. В нем только Angie PRO.
Ссылаясь на этот закон, компании прекрасно используют nginx. Для OSS присутствие в реестре не дает примерно ничего, поэтому Angie OSS в реестре и не присутствует. Для не OSS пока тоже особо не дает, при наличии OSS аналога. Зато если не присутствуешь, то на твою коммерческую версию даже смотреть не будут.
Исходя из этого, по факту реестр отечественного ПО не особо работает, тем более в нашем случае.
Но мне интересно, почему вы написали определенные слова и в кавычках? Присутствие в данном реестре - это не какая-то формальность, из него и исключить могут. Это не означает, что все строчки кода ПО, которое там находится - были написаны в России, хотя для nginx это даже на 99% именно так. Но это означает прежде всего, что есть некая компания, некое юр.лицо в российской юрисдикции, которое может понести вполне себе не "ответственность", а ОТВЕТСТВЕННОСТЬ по всей строгости, если вдруг что. Как на мой взгляд, это вполне себе в духе отечества, чтобы не писать это слово в кавычках применительно к реестру. Готовы на себя такую ответственность за какой-нибудь продукт взять просто так?
Поднятие бабла с госов и военки в США с некоторых пор стало совсем невозможно совместить с наличием офиса в России. Поэтому проще всех уволить и закрыть офис, что и предопределило появление Angie.
Готово: https://angie.software/configuration/modules/http_acme/
Потому, что это ближе по концепции к LTS. Т.е. каждый mainline релиз является стабильным, просто некоторые из них получают продленный на год срок поддержки и исправления критических ошибок.
А зачем для этого open-source делать?
И если у кого-то ещё остаются какие-то сомнения по поводу стабильности и позиционирования mainline ветки, то отдельно обращу внимание на то, как появляется очередная stable ветка: раз в год, обычно весной, текущая mainline ветка превращается в очередную stable ветку, при этом не имеет никакого значения, что какие-то функции и модули там уже почти год, а какие-то были добавлены за месяц до того. И ничего другого не происходит, никакой стабилизации кода, никаких дополнительных тестов - это просто ежегодное чисто формальное мероприятие от которого код не становится каким-то магическим образом более стабилен, чем был до того.
И "экспериментальность" отдельных модулей и функций - тут тоже совершенно ортогональная история. От переименования mainline ветки в очередную stable - "экспериментальные" модули и функции не перестают быть экспериментальными. Так, например, perl-модуль является экспериментальным с момента своего появления (в версии 0.3.21, выпущенной ещё в 2006 году) и по сей день. Т.е. этот "экспериментальный" модуль входит во все stable ветки за последние 18 лет.