Аналогичная история. Разумеется никакую симку не менял и в Т-Мобайл отрицают то, что какую-либо информацию об этом направляли.
В итоге в Альфе по телефону стояли на своем и сказали приходить с паспортом в отделение. Но обновил страницу в интернет-банке и там появилась вверху плашка "В банк поступила информация о смене сим карты... бла-бла необходимо подтвердить" и кнопка "Подтвердить". Нажал кнопку - появилась табличка "Подтверждения не требуется" и все заработало.
Мое понимание заключается в том, что nginx из коробки не должен проигрывать haproxy в разы. Указанное число RPS для сервера с 32 CPU - это вообще крайне мало... и выглядит очень подозрительно.
Жаль, если вы не хотите разобраться в причинах наблюдаемого явления. Даже если я попрошу воспроизвести коллег, то с большой вероятностью у нас не получатся такие же цифры, т.к. не получится точно повторить указанный стенд.
Вопрос, у вас HTTPS соединения keepalive или на каждый запрос новое? А если на каждый запрос новое соединение, то используется ли возобновление TLS-сессий и каким механизмом? Полный хендшейк - это весьма CPU-нагруженная операция, и лишь разница в настройках TLS-сессий может полностью перевернуть картину между серверами. Опять же, каждая настройка хороша под конкретный стенд, поэтому выравнивать сервера по настройкам, тем более таким критичным, как TLS - необходимо, иначе будет просто необъективный результат, который применим только к конкретному стенду, а на другом стенде будет совсем другим. Так вы протестировали сервера на то, как их настройки по умолчанию подходят для вашего стенда и это будет иметь мало общего с производительностью в реальности, даже на тех же настройках - просто в силу того, что клиенты обычно не ведут себя как отдельно взятый тестовый стенд.
У haproxy, кстати, по умолчанию включен кэш SSL-сессий, а у nginx он выключен. И если клиент, например, не умеет в сессионные тикеты, то вот и разница - тогда в одном случае вы считаете полные хендшейки, а в другом возобновления сессий.
Какие ошибки в логах? Во всех тестах, что мы проводили на моей памяти, haproxy оказывался чуть хуже nginx, да в общем-то неоткуда там разнице особой взяться, тем более в разы - архитектура очень похожа. Поэтому есть все основания полагать, что что-то фундаментально не так с конкретной установкой nginx. Что все же в логах ошибок? И сам nginx, кстати, откуда? Из официального репозитория на `nginx.org`?
И кстати, ни один из серверов сам не обрабатывает TLS - эту задачу решают TLS-библиотеки. Учитывая, как изменились результаты с настройкой ssl_ciphers, возможно вы на самом деле протестировали производительность сборок конкретных библиотек. Для равноценного теста с участием TLS - сервера должны быть собраны с одной и той же библиотекой.
Если интересно все же разобрать в причинах, я бы предложил попробовать повторить тест без TLS в принципе. Если результаты nginx и haproxy окажутся в этом случае близки, то дальше нужно будет разбираться, а что не так с TLS.
И обращаю также внимание на то, что у nginx по умолчанию включен `access_log`, а у того же haproxy, насколько я помню, его нужно включать принудительно.
> Затем и включили, что без него только хуже)
По вашим данным с выключенным multi_accept число успешных запросов больше:
checks_succeeded...................: 30.91% 312910 out of 1012194 checks_failed......................: 69.08% 699284 out of 1012194
против с включенным:
checks_succeeded...................: 25.90% 244664 out of 944528 checks_failed......................: 74.09% 699864 out of 944528
или я неправильно интерпертирую данные?
Но должно быть вообще 100%. То, что nginx теряет запросы - это что-то ненормальное, в error_log должны быть причины этому.
Если проект перестанет делать заявления, от которых откажется буквально через пару месяцев, то я с радостью попытаюсь придумать где взять деньги.(видите, это в обе стороны может работать)
Перестанет и заявления во множественном числе предполагает, что мы их продолжаем делать. Можете указать пожалуйста, какие ещё заявления мы делали? Это важно, т.к. я не в курсе этого и меня это беспокоит.
Иван Полуянов давно уже больше не является представителем компании и у нас не работает. Могу лишь принести за него извинения от себя лично за его прошлую ошибку и введение в заблуждение. Это его собственное высказывание - откровенный бред, ибо PRO версия уже была и, в том числе, на момент конференции уже более 4 месяцев в репозитории PRO велась разработка довольно значительной фичи - конфигурационного Rest API для изменения списка проксируемых серверов, которая появилась в августе того же года в рамках 1.2.0.
У меня нет разумных объяснений почему он это сказал. Этого не было в его докладе, это не было согласовано с нами, он отвечал на вопрос из зала от себя. К сожалению, люди допускают ошибки.
Первая версия PRO вышла в феврале 2023: https://angie.software/angie/docs/pro_changes/#angie-pro-1-1-0 - а питерский хайлоад обычно летом проводят. Так что на тот момент PRO версия уже была, а на самом хайлоаде выступал Полуянов, которому, по его словам, на солнце и под светом софитов напекло голову, что он неправильно выразился - хотел сказать, что никакие фичи, которые есть уже в open source версии, не будут закрыты. И оно действительно так, мы не закрываем фичи. Про существование коммерческой версии уже как полгода на тот момент - он, очевидно, не мог не знать.
Если вы расскажите где взять деньги, чтобы платить людям зарплату, кормить семью и продолжать разрабатывать исключительно open source версию, то мы с радостью перенесем все фичи из PRO в open source.
Так называемого "удержания" фич нет - просто если бы никто не покупал PRO версию, то вообще никаких бы фич не было, ни новых релизов PRO, ни новых релизов open source версии. Чтобы в open source версии появились какие-то фичи, для начала, их кто-то должен там разработать. Почему-то бесплатно люди работать не хотят, это очень удивительно! Хотите чтобы было больше open source фич - приобретайте PRO лицензию, особенно если у вас коммерческая компания - это лучший способ поддержать разработчиков. Поддержку компании не особо горят покупать, а чтобы поддержка окупала бы разработку, то стоимость этой поддержки должна быть такой, что вообще никто бы не купил. Более того, нам прямым текстом говорили, что "зачем нам у вас что-то покупать, если мы можем вашу бесплатную версию взять, а с поддержкой и сами справимся". Добро пожаловать в реальный мир. Если вы считаете, что можно было зарабатывать только на поддержке, то вперед и с песней, делайте свой форк, успехов, все будут только рады, но эта модель не сработала с nginx, поэтому повяился nginx plus (где-то спустя три года после основания компании, после долгих неуспешных попыток заработать на поддержке и заказной разработке) и с тех пор ничего не изменилось.
Зачем включили multi_accept? Он выключен по умолчанию не просто так. Это лучший способ вызвать дисбаланс в бенчмарке. Скорее всего у вас большинство соединений в итоге приняли и обрабатывали всего несколько первых рабочих процессов. От того и такие результаты...
Что в логе ошибок было? nginx пишет обычно что пошло не так... возможно у вас закончились дескрипторы или уперлись в лимит как раз из-за multi_accept.
Перед тем, как тестировать, выровняли ли настройки TLS-шифрования? У nginx по умолчанию `ssl_ciphers HIGH:!aNULL:!MD5;`. У других серверов скорее всего шифрование использовалось более слабое и менее ресурсоемкое, так что CPU не стал для них бутылочным горлышком.
Одинаковы ли у серверов настройки логирования?
Крайне предвзятый тест, без попытки разобраться в причинах и изначально неравными настройками.
Моя гипотеза: из-за "multi_accept" соединения между рабочими процессами распределялись крайне неравномерно, а из-за тяжелой криптографии рабочие процессы, набрав соединения, заблокировались на CPU.
Такой вопрос: как организовали синхронизацию потоков при работе с WASM и с файловой системой в частности?
В примере с SQLite всё просто и без изысков: взяли лок на базу, поработали, отпустили. Разные рабочие процессы будут ждать на локе. Это всё-таки демонстрационный пример WASM-модуля, а не настоящая база данных.
P.S. В недостатках WASIp1 сказано "нет сокетов", но в WASIp1 есть файловые сокеты.
Оно не сильно помогает с точки зрения установления соединений с кем-то в сети.
Когда то ковырялся в системе плагинов envoy, так же thread local storage хоста кладете экземпляры wasm-движка и из-за этого имеете повышенное потребление памяти?
У нас рабочие процессы однопоточные, так что thread local storage в принципе не используется. Движок один, а виртуальные машины могут быть на каждый запрос или по одной на все запросы внутри каждого рабочего процесса - как настроите.
Не появились пропозалы, позволяющие не копировать память?
Нет. Это архитектурная проблема nginx, которую невозможно исправить не сломав обратную совместимость тотально. Там нет как такового публичного обособленного интерфейса для разработчиков модулей, а просто выставлены внутренние кишки наружу, как есть, и способ сборки с ними.
В итоге понятие API для модулей размыто: практически всё является публичным API и даже то, во что авторы не предполагали, что модулям следует лезть. Поэтому любая доработка или исправление бага потенциально может что-то сломать в чужом коде.
Это с одной стороны дает мощь и гибкость: в модулях можно реализовать практически что угодно, а с другой создает множество проблем в плане поддержки всего этого хозяйства.
nginx пытался решать это с помощью njs, агитируя писать расширения в рамках встроенного движка JavaScript.
Любой сторонний модуль на Си в nginx и любом его форке - это потенциальная головная боль, мина замедленного действия. Никаких гарантий совместимости API даже между минорными версиями у nginx нет. В любой момент, после очередного обновления, модуль может начать подтекать, либо вызывать ещё какие-то проблемы, совершенно неожиданные. И обычно первое же, что мы просим при жалобе на любой баг - это попробовать воспроизвести без сторонних модулей, ибо статистика по ним печальная.
Поэтому если можно лишний раз не использовать какой-то сторонний модуль, то лучше и не использовать.
К тому же в официальных репозиториях nginx, например, никакого fancyindex модуля нет. Т.е. если вы его используете, то видимо собирали самостоятельно, либо nginx у вас установлен не из официального репозитория. Качество пакета nginx в сторонних репозиториях, в том числе репозиториях дистрибутивов, оставляет желать лучшего. Там обычно пакетами занимаются плохо разбирающиеся в нюансах nginx мейнтейнеры. Как результат, сборщики в Debian умудрялись долгое время собирать пакет с серьезной уязвимостью - очень наглядный прецедент. Да и версии пакетов зачастую в других репозиториях отстают, из-за чего серьезные и важные исправления порой сильно запаздывают.
я акцентировал внимание на том, что "у нас" почему-то принято сразу получать прибыль, а не инвестировать, иногда реально долго, прежде чем получать доход
Это же не зависит от нашего желания или нежелания. Это вопрос доступности долгих денег. И в текущих экономических реалиях (ставку ЦБ РФ знаете же, а как часто у нас постоянно какие-то потрясения...) вполне понятно почему мало кто готов вкладывать немалые деньги на десятки лет вперед. Таковы реалии, к сожалению.
Некоторые и не меняют, а просто делают симлинк angie -> nginx, вот живой пример: https://habr.com/ru/articles/869204/ - в чем обман то? И так тоже можно. =)
У нас в пакетах пути отличаются специально, чтобы не конфликтовать с пакетами nginx и дать возможность поставить в систему одновременно оба сервера, протестировать, плавно переехать. Тут уж кому как удобнее.
Я не считаю пользователей бесплатной версии какими-то не такими. Просто есть такая пословица "дареному коню в зубы не смотрят". Вы рассуждаете, что вот сделали бы мы активные проверки в бесплатной версии - тогда бы больше было пользователей и нам было бы лучше. Но весь практический опыт говорит ровно об обратном. Есть пользователи, которые купили PRO благодаря активным проверкам и это позволило расширить команду, сделать больше фич в том числе в бесплатной версии и, например, не закрыться.
Я вот в nginx пришел практически с момента основания компании, в 2011. Тогда никто о платной версии nginx plus даже не помышлял. Имея долю на рынке веб-серверов более 5% во всем мире, сколько nginx собирал пожертвований, знаете? Ровно столько, что хватало исключительно только на оплату хостинга для `nginx.org`. Разработчики просто проедали деньги западных инвесторов, которые разумеется хотели их приумножить рано или поздно (что потом и случилось в момент продажи в F5).
И это были реалии, когда западные инвесторы с интересом смотрели на стартапы с офисами в Москве и можно было рассчитывать на венчур, долгие деньги. Если кто-то считает, что мы жадные и что-то не так делаем, то пожалуйста: лицензия BSD позволяет, делайте ещё форк, делайте лучше - тут никто ж не мешает. Наш коллега, Максим Дунин так и поступил, взял сделал freenginx - никакой коммерческой версии у него нет, никакого конфликта интересов. Много там нового за год то появилось? То-то и оно.
На счет личности не согласен, лишь ответил на то, что звучало как обвинение в том числе в мой адрес: "а вы все также продолжаете урезать функционал".
А по поводу наличия желания конкурировать все очень просто. Одного желания недостаточно. Ещё ресурсы нужны.
одного включения в реестр "отечественного" ПО недостаточно. Нужны реальные преимущества относительно ванильного nginx.
Как лихо обнулили многие сотни часов разработчиков, потраченные на более десятка различных функциональных возможностей относительно ванильного nginx, часть из которых, например, перечислена тут: https://angie.software/angie/docs/#index-features-oss
Есть же функции, нужные реально только Энтерпрайзу, а базовые вещи вроде балансирования должны быть во всех версиях.
Извините, но кому должны? Завтра вызывает начальник и говорит, а вот эту работу вы должны делать бесплатно, а почему спросите? А потому, что вот Иван Иваныч из соседнего отдела - это бесплатно сделал.
Если вы готовы работать бесплатно - то напишите на `hr@wbsrv.ru`. Честно скажу, пока ни одного такого сотрудника не встречал.
Правда же в том, что бесплатного ничего не бывает, а то, что вы бесплатно получаете на самом деле просто оплатил кто-то другой прямо или косвенно (в том числе это относится и к haproxy и вообще любому написанному коду - кто-то потратил свое время, поработал над кодом). Не секрет, что nginx всю дорогу был убыточной компанией - итог всем известен. Про наши приключения есть отдельная статья.
Лучшее, что вы можете сделать - это убедить начальство закупить Angie PRO, чтобы поддержать разработку в том числе опенсорс версии (предполагаю, что у вас компания не бесплатно работает и выручка есть?). А без этого не будет никакой версии и никаких новых фич, только если не найдутся люди, готовые работать бесплатно столько же, сколько они используют бесплатного ПО.
Когда разработчиков и их семьи начнут бесплатно кормить и бесплатно предоставлять жилье - тогда начнем программировать все в бесплатной версии. А пока суровый оскал капитализма заставляет искать возможности для существования.
Вообще это довольно востребованная функциональность. Как простой пример, php-fpm не может вместить в себя бесконечное количество параллельно обрабатываемых запросов - просто память закончится. Поэтому число рабочих процессов ограничено сверху. И вместо того, чтобы пытаться наливать запросы сверх этого числа - более разумной стратегией будет выставить ограничение на балансировщике, чтобы тот не пытался наливать больше, чем позволяет ёмкость бекенда, тогда лишние запросы можно либо отсекать, либо складывать во временную очередь и далее направлять на первый освободившийся сервер (что и делает "queue").
Всё это верно в той или иной степени относительно любого балансируемого бекенда. Ресурсы бекендов не безграничны, в том числе поэтому их разворачивают несколько и горизонтально пытаются масштабировать.
> Думается, что если бы это было нужной многим фичей, то оно было бы в разных проксях доступно.
Оно доступно во многих серьезных балансировщиков крупных вендоров и появилось не на пустом месте.
А в тексте вроде это указано в конце соответствующих абзацев про эти модули: "Модуль "queue" создаёт .. Модуль существует для HTTP подсистемы и доступен в составе коммерческих продуктов Angie." и "Модуль активных проверок называется "upstream_probe" и доступен в составе коммерческих продуктов Angie.".
С точки зрения возможностей запуска процессов приложений - да. Производительность предполагается даже выше чем Unit отдельно и заметно выше, чем связка nginx+unit или любая другая комбинация с ним.
Аналогичная история. Разумеется никакую симку не менял и в Т-Мобайл отрицают то, что какую-либо информацию об этом направляли.
В итоге в Альфе по телефону стояли на своем и сказали приходить с паспортом в отделение. Но обновил страницу в интернет-банке и там появилась вверху плашка "В банк поступила информация о смене сим карты... бла-бла необходимо подтвердить" и кнопка "Подтвердить". Нажал кнопку - появилась табличка "Подтверждения не требуется" и все заработало.
Какой-то у них сбой.
Мое понимание заключается в том, что nginx из коробки не должен проигрывать haproxy в разы. Указанное число RPS для сервера с 32 CPU - это вообще крайне мало... и выглядит очень подозрительно.
Жаль, если вы не хотите разобраться в причинах наблюдаемого явления. Даже если я попрошу воспроизвести коллег, то с большой вероятностью у нас не получатся такие же цифры, т.к. не получится точно повторить указанный стенд.
Вопрос, у вас HTTPS соединения keepalive или на каждый запрос новое? А если на каждый запрос новое соединение, то используется ли возобновление TLS-сессий и каким механизмом? Полный хендшейк - это весьма CPU-нагруженная операция, и лишь разница в настройках TLS-сессий может полностью перевернуть картину между серверами. Опять же, каждая настройка хороша под конкретный стенд, поэтому выравнивать сервера по настройкам, тем более таким критичным, как TLS - необходимо, иначе будет просто необъективный результат, который применим только к конкретному стенду, а на другом стенде будет совсем другим. Так вы протестировали сервера на то, как их настройки по умолчанию подходят для вашего стенда и это будет иметь мало общего с производительностью в реальности, даже на тех же настройках - просто в силу того, что клиенты обычно не ведут себя как отдельно взятый тестовый стенд.
У haproxy, кстати, по умолчанию включен кэш SSL-сессий, а у nginx он выключен. И если клиент, например, не умеет в сессионные тикеты, то вот и разница - тогда в одном случае вы считаете полные хендшейки, а в другом возобновления сессий.
50k RPS для nginx - это вообще пустяки, но вот криптография, которой занимается TLS-библиотека - она может стать лимитирующим фактором. К примеру, вот такой sizing guide для nginx plus: https://www.f5.com/pdf/deployment-guide/Sizing-Guide-for-Deploying-NGINX-Plus-on-Bare-Metal-Servers-2019-11-09.pdf - он уже старенький, ещё от 2019 года, но можно заметить, что на 32 CPU легко может быть 1 000 000 RPS, но всего около 50к полных хендшейков.
Какие ошибки в логах? Во всех тестах, что мы проводили на моей памяти, haproxy оказывался чуть хуже nginx, да в общем-то неоткуда там разнице особой взяться, тем более в разы - архитектура очень похожа. Поэтому есть все основания полагать, что что-то фундаментально не так с конкретной установкой nginx. Что все же в логах ошибок? И сам nginx, кстати, откуда? Из официального репозитория на `nginx.org`?
И кстати, ни один из серверов сам не обрабатывает TLS - эту задачу решают TLS-библиотеки. Учитывая, как изменились результаты с настройкой
ssl_ciphers, возможно вы на самом деле протестировали производительность сборок конкретных библиотек. Для равноценного теста с участием TLS - сервера должны быть собраны с одной и той же библиотекой.Если интересно все же разобрать в причинах, я бы предложил попробовать повторить тест без TLS в принципе. Если результаты nginx и haproxy окажутся в этом случае близки, то дальше нужно будет разбираться, а что не так с TLS.
И обращаю также внимание на то, что у nginx по умолчанию включен `access_log`, а у того же haproxy, насколько я помню, его нужно включать принудительно.
> Затем и включили, что без него только хуже)
По вашим данным с выключенным multi_accept число успешных запросов больше:
checks_succeeded...................: 30.91% 312910 out of 1012194 checks_failed......................: 69.08% 699284 out of 1012194против с включенным:
checks_succeeded...................: 25.90% 244664 out of 944528 checks_failed......................: 74.09% 699864 out of 944528или я неправильно интерпертирую данные?
Но должно быть вообще 100%. То, что nginx теряет запросы - это что-то ненормальное, в error_log должны быть причины этому.
Перестанет и заявления во множественном числе предполагает, что мы их продолжаем делать. Можете указать пожалуйста, какие ещё заявления мы делали? Это важно, т.к. я не в курсе этого и меня это беспокоит.
Иван Полуянов давно уже больше не является представителем компании и у нас не работает. Могу лишь принести за него извинения от себя лично за его прошлую ошибку и введение в заблуждение. Это его собственное высказывание - откровенный бред, ибо PRO версия уже была и, в том числе, на момент конференции уже более 4 месяцев в репозитории PRO велась разработка довольно значительной фичи - конфигурационного Rest API для изменения списка проксируемых серверов, которая появилась в августе того же года в рамках 1.2.0.
У меня нет разумных объяснений почему он это сказал. Этого не было в его докладе, это не было согласовано с нами, он отвечал на вопрос из зала от себя. К сожалению, люди допускают ошибки.
Меня не было на Saint Highload 2023.
Первая версия PRO вышла в феврале 2023: https://angie.software/angie/docs/pro_changes/#angie-pro-1-1-0 - а питерский хайлоад обычно летом проводят. Так что на тот момент PRO версия уже была, а на самом хайлоаде выступал Полуянов, которому, по его словам, на солнце и под светом софитов напекло голову, что он неправильно выразился - хотел сказать, что никакие фичи, которые есть уже в open source версии, не будут закрыты. И оно действительно так, мы не закрываем фичи. Про существование коммерческой версии уже как полгода на тот момент - он, очевидно, не мог не знать.
Если вы расскажите где взять деньги, чтобы платить людям зарплату, кормить семью и продолжать разрабатывать исключительно open source версию, то мы с радостью перенесем все фичи из PRO в open source.
Так называемого "удержания" фич нет - просто если бы никто не покупал PRO версию, то вообще никаких бы фич не было, ни новых релизов PRO, ни новых релизов open source версии. Чтобы в open source версии появились какие-то фичи, для начала, их кто-то должен там разработать. Почему-то бесплатно люди работать не хотят, это очень удивительно! Хотите чтобы было больше open source фич - приобретайте PRO лицензию, особенно если у вас коммерческая компания - это лучший способ поддержать разработчиков. Поддержку компании не особо горят покупать, а чтобы поддержка окупала бы разработку, то стоимость этой поддержки должна быть такой, что вообще никто бы не купил. Более того, нам прямым текстом говорили, что "зачем нам у вас что-то покупать, если мы можем вашу бесплатную версию взять, а с поддержкой и сами справимся". Добро пожаловать в реальный мир. Если вы считаете, что можно было зарабатывать только на поддержке, то вперед и с песней, делайте свой форк, успехов, все будут только рады, но эта модель не сработала с nginx, поэтому повяился nginx plus (где-то спустя три года после основания компании, после долгих неуспешных попыток заработать на поддержке и заказной разработке) и с тех пор ничего не изменилось.
Все модули есть в репозиториях: https://angie.software/angie/docs/installation/external-modules/
Существующий сторонний модуль не подходит?
Зачем включили multi_accept? Он выключен по умолчанию не просто так. Это лучший способ вызвать дисбаланс в бенчмарке. Скорее всего у вас большинство соединений в итоге приняли и обрабатывали всего несколько первых рабочих процессов. От того и такие результаты...
Что в логе ошибок было? nginx пишет обычно что пошло не так... возможно у вас закончились дескрипторы или уперлись в лимит как раз из-за multi_accept.
Перед тем, как тестировать, выровняли ли настройки TLS-шифрования? У nginx по умолчанию `ssl_ciphers HIGH:!aNULL:!MD5;`. У других серверов скорее всего шифрование использовалось более слабое и менее ресурсоемкое, так что CPU не стал для них бутылочным горлышком.
Одинаковы ли у серверов настройки логирования?
Крайне предвзятый тест, без попытки разобраться в причинах и изначально неравными настройками.
Моя гипотеза: из-за "multi_accept" соединения между рабочими процессами распределялись крайне неравномерно, а из-за тяжелой криптографии рабочие процессы, набрав соединения, заблокировались на CPU.
В примере с SQLite всё просто и без изысков: взяли лок на базу, поработали, отпустили. Разные рабочие процессы будут ждать на локе. Это всё-таки демонстрационный пример WASM-модуля, а не настоящая база данных.
Оно не сильно помогает с точки зрения установления соединений с кем-то в сети.
У нас рабочие процессы однопоточные, так что thread local storage в принципе не используется. Движок один, а виртуальные машины могут быть на каждый запрос или по одной на все запросы внутри каждого рабочего процесса - как настроите.
Не встречались.
Нет. Это архитектурная проблема nginx, которую невозможно исправить не сломав обратную совместимость тотально. Там нет как такового публичного обособленного интерфейса для разработчиков модулей, а просто выставлены внутренние кишки наружу, как есть, и способ сборки с ними.
В итоге понятие API для модулей размыто: практически всё является публичным API и даже то, во что авторы не предполагали, что модулям следует лезть. Поэтому любая доработка или исправление бага потенциально может что-то сломать в чужом коде.
Это с одной стороны дает мощь и гибкость: в модулях можно реализовать практически что угодно, а с другой создает множество проблем в плане поддержки всего этого хозяйства.
nginx пытался решать это с помощью njs, агитируя писать расширения в рамках встроенного движка JavaScript.
Мы в Angie ещё добавили возможность делать это на WASM: https://angie.software/angie/docs/configuration/modules/wasm/
В общем-то основные минусы в статье упомянуты.
Любой сторонний модуль на Си в nginx и любом его форке - это потенциальная головная боль, мина замедленного действия. Никаких гарантий совместимости API даже между минорными версиями у nginx нет. В любой момент, после очередного обновления, модуль может начать подтекать, либо вызывать ещё какие-то проблемы, совершенно неожиданные. И обычно первое же, что мы просим при жалобе на любой баг - это попробовать воспроизвести без сторонних модулей, ибо статистика по ним печальная.
Поэтому если можно лишний раз не использовать какой-то сторонний модуль, то лучше и не использовать.
К тому же в официальных репозиториях nginx, например, никакого fancyindex модуля нет. Т.е. если вы его используете, то видимо собирали самостоятельно, либо nginx у вас установлен не из официального репозитория. Качество пакета nginx в сторонних репозиториях, в том числе репозиториях дистрибутивов, оставляет желать лучшего. Там обычно пакетами занимаются плохо разбирающиеся в нюансах nginx мейнтейнеры. Как результат, сборщики в Debian умудрялись долгое время собирать пакет с серьезной уязвимостью - очень наглядный прецедент. Да и версии пакетов зачастую в других репозиториях отстают, из-за чего серьезные и важные исправления порой сильно запаздывают.
Это же не зависит от нашего желания или нежелания. Это вопрос доступности долгих денег. И в текущих экономических реалиях (ставку ЦБ РФ знаете же, а как часто у нас постоянно какие-то потрясения...) вполне понятно почему мало кто готов вкладывать немалые деньги на десятки лет вперед. Таковы реалии, к сожалению.
Некоторые и не меняют, а просто делают симлинк angie -> nginx, вот живой пример: https://habr.com/ru/articles/869204/ - в чем обман то? И так тоже можно. =)
У нас в пакетах пути отличаются специально, чтобы не конфликтовать с пакетами nginx и дать возможность поставить в систему одновременно оба сервера, протестировать, плавно переехать. Тут уж кому как удобнее.
Я не считаю пользователей бесплатной версии какими-то не такими. Просто есть такая пословица "дареному коню в зубы не смотрят". Вы рассуждаете, что вот сделали бы мы активные проверки в бесплатной версии - тогда бы больше было пользователей и нам было бы лучше. Но весь практический опыт говорит ровно об обратном. Есть пользователи, которые купили PRO благодаря активным проверкам и это позволило расширить команду, сделать больше фич в том числе в бесплатной версии и, например, не закрыться.
Я вот в nginx пришел практически с момента основания компании, в 2011. Тогда никто о платной версии nginx plus даже не помышлял. Имея долю на рынке веб-серверов более 5% во всем мире, сколько nginx собирал пожертвований, знаете? Ровно столько, что хватало исключительно только на оплату хостинга для `nginx.org`. Разработчики просто проедали деньги западных инвесторов, которые разумеется хотели их приумножить рано или поздно (что потом и случилось в момент продажи в F5).
И это были реалии, когда западные инвесторы с интересом смотрели на стартапы с офисами в Москве и можно было рассчитывать на венчур, долгие деньги. Если кто-то считает, что мы жадные и что-то не так делаем, то пожалуйста: лицензия BSD позволяет, делайте ещё форк, делайте лучше - тут никто ж не мешает. Наш коллега, Максим Дунин так и поступил, взял сделал freenginx - никакой коммерческой версии у него нет, никакого конфликта интересов. Много там нового за год то появилось? То-то и оно.
На счет личности не согласен, лишь ответил на то, что звучало как обвинение в том числе в мой адрес: "а вы все также продолжаете урезать функционал".
А по поводу наличия желания конкурировать все очень просто. Одного желания недостаточно. Ещё ресурсы нужны.
Как лихо обнулили многие сотни часов разработчиков, потраченные на более десятка различных функциональных возможностей относительно ванильного nginx, часть из которых, например, перечислена тут: https://angie.software/angie/docs/#index-features-oss
Извините, но кому должны? Завтра вызывает начальник и говорит, а вот эту работу вы должны делать бесплатно, а почему спросите? А потому, что вот Иван Иваныч из соседнего отдела - это бесплатно сделал.
Если вы готовы работать бесплатно - то напишите на `hr@wbsrv.ru`. Честно скажу, пока ни одного такого сотрудника не встречал.
Правда же в том, что бесплатного ничего не бывает, а то, что вы бесплатно получаете на самом деле просто оплатил кто-то другой прямо или косвенно (в том числе это относится и к haproxy и вообще любому написанному коду - кто-то потратил свое время, поработал над кодом). Не секрет, что nginx всю дорогу был убыточной компанией - итог всем известен. Про наши приключения есть отдельная статья.
Лучшее, что вы можете сделать - это убедить начальство закупить Angie PRO, чтобы поддержать разработку в том числе опенсорс версии (предполагаю, что у вас компания не бесплатно работает и выручка есть?). А без этого не будет никакой версии и никаких новых фич, только если не найдутся люди, готовые работать бесплатно столько же, сколько они используют бесплатного ПО.
Когда разработчиков и их семьи начнут бесплатно кормить и бесплатно предоставлять жилье - тогда начнем программировать все в бесплатной версии. А пока суровый оскал капитализма заставляет искать возможности для существования.
Вообще это довольно востребованная функциональность. Как простой пример, php-fpm не может вместить в себя бесконечное количество параллельно обрабатываемых запросов - просто память закончится. Поэтому число рабочих процессов ограничено сверху. И вместо того, чтобы пытаться наливать запросы сверх этого числа - более разумной стратегией будет выставить ограничение на балансировщике, чтобы тот не пытался наливать больше, чем позволяет ёмкость бекенда, тогда лишние запросы можно либо отсекать, либо складывать во временную очередь и далее направлять на первый освободившийся сервер (что и делает "queue").
Всё это верно в той или иной степени относительно любого балансируемого бекенда. Ресурсы бекендов не безграничны, в том числе поэтому их разворачивают несколько и горизонтально пытаются масштабировать.
> Думается, что если бы это было нужной многим фичей, то оно было бы в разных проксях доступно.
Оно доступно во многих серьезных балансировщиков крупных вендоров и появилось не на пустом месте.
А в тексте вроде это указано в конце соответствующих абзацев про эти модули: "Модуль "queue" создаёт .. Модуль существует для HTTP подсистемы и доступен в составе коммерческих продуктов Angie." и "Модуль активных проверок называется "upstream_probe" и доступен в составе коммерческих продуктов Angie.".
error_logв режимеdebugбыл всегда. Или что вы имеете в виду?С точки зрения возможностей запуска процессов приложений - да. Производительность предполагается даже выше чем Unit отдельно и заметно выше, чем связка nginx+unit или любая другая комбинация с ним.