Проблема в том, что статистически рабочие процессы стоящие выше в очереди - загружены сильнее, чем те, кто в конце (добавили себя в список слушающих последними при запуске). Всё это приводит к росту задержек из-за того, что в итоге часть ядер процессора оказывается перегружены работой, а другие недогружены.
php-fpm загнулся со 100 рабочими процессами, где Unit справился всего с 16 и обошел его на порядок. Вы предлагаете накрутить аж 512 процессов, но это же просто костыль, который наглядно демонстрирует насколько php-fpm убогий. Так ведь и Unit-у можно 512 процессов накрутить, но зачем? На сервере всегда есть другие задачи, под которые лучше память выделить.
Согласен, что может быть не совсем удачный пример. Я не разбираюсь в игровой индустрии, просто новость на слуху.
Но вот F5, например, тоже чуть ли не каждый год покупает по 1-2 компании и тут речь об авторских правах точно не идет. Так из приобретений только за последние пару лет: Shape Security, Silverline, Volterra,Threat Stack.
Там же написано, почему предложенный патч работать правильно не будет. И если в ядре нет хорошего решения, то его нет.
Отдельно интересно услышать, а каким образом это "очень обидный баг", ибо по сути это настолько мирооптимизация, что даже на бенчмарках измерить разницу от точно выверенного выставления affinity и числа рабочих процессов не так уж просто.
Вы сейчас что хотите доказать? Что nginx нужен? Что надо им пользоваться ? Или что?
Вы озвучили в комментах некие претензии и я на них ответил. Я не вижу никакого смысла спорить. Это как спорить с человеком, который сидя в лесу и наблюдая несколько деревьев вокруг себя - считает, что весь остальной лес абсолютно такой же.
Если думаете, что я негативистки мыслю - нет. Просто точки зрения могут быть разные, а мир больших денег вообще особый.
Проблема в том, что наличие точки зрения не означает, что её нужно высказывать в любой удобный момент и по любому поводу.
Тут негативные комментарии про nginx есть не только от вас. Видимо все эти комментаторы считают, что данная новость о его авторе - это отличный повод, чтобы как-нибудь пнуть его детище, а не просто поблагодарить за работу и вклад, который он сделал. Или промолчать и пройти мимо, оставив свою точку зрения при себе.
ну, это же ничего не означает? Купи подписку редхат и попади в fortune 500 по скидке? Ну, не работает это так.
Проблема в том, что большинство тех самых крупных компаний, о которых вы писали, очень чувствительно и строго относятся к раскрытию поставщиков своих решений, а потому со стороны не видно кто и у кого что покупает.
На месте Audi я бы провел стандартную процедуру для крупной компании - рассылку заявок по потенциальным вендорам и сбор их результата. Дальше открытый конкурс на основе критериев от заказчика для выбора победителя.
Почему вы думаете, что они так не сделали, если по ссылке прямым текстом написано "After an initial vendor investigation process, there was only one security solution that ticked all the boxes".
ну, я про это и говорю, но с другой стороны. Для заказчика, который не готов заливать деньгами какого-нибудь конкретного подрядоса, пропихнуть какую-то свою фичу или баг в верх списка практически нереально.
Обычно речь идет о суммах, когда просто берут и покупают компанию целиком. И такое, кстати, тоже регулярно происходит. Вот как недавно с Activision Blizzard. Думаете у Microsoft нет компетенций для разработки таких же продуктов? Но зачем, если проще и быстрее купить готовую компанию.
Ну, и завсегда проблема - повторюсь, у крупных компаний типа редхат и vmware всегда есть куча багов в KB, которые не правятся годами
Равно как и у мелких. Какая-то банальщина. Багов нет только у тех продуктов, которыми никто не пользуется. Срок прошедший с момента обнаружения бага - это не критерий для приоритезации его исправления. Кто-то предпочитает заниматься исправлением багов в хронологическом порядке?
А ещё баги, как минимум, делятся на известные и неизвестные, и последние, как правило, хуже и неприятнее. Баг в KB - это уже более хороший баг.
Вот возьмем Lyft. Именно они разработали envoy. ... Ауди тоже могли бы разработать какую-нибудь полезную штуку и опенсурснуть ее в мир.
Если бы могли бы - разработали бы. Многое упирается в кадры, кадры помноженные на время. Если в Lyft нашлась команда людей, которые смогли придумать и реализовать на должном уровне, да ещё у них было на это время и бизнес-воля у менеджмента - они это сделали.
Я понимаю, что в комментариях каждый второй бы свой nginx без проблем написал и повторил бы историю успеха на раз-два, но только, как правило, времени нет, и поэтому больше трети интернета предпочитает запускать на фронтенде вполне конкретный nginx.
Среди клиентов полно компаний из списка Fortune 500, в том числе из верхушки.
но как показывает опыт - эти очень "богатые" компании вместо того, чтобы платить вендору почему-то пытаются выращивать свою внутреннюю компетенцию. Вот удивительно, да? Как думаете, почему?
Это видимо СНГ опыт? Мой опыт говорит о том, что большинство американских компаний стремяться аутсорсить по максимуму любой непрофильный бизнес. Набирать людей и выращивать свою экспертизу - это капиталовложения, это время, которое упущено, это риски.
Вот взять, например, нашу историю успеха с компанией Audi. Им нужно решить конкретную задачу, а вы бы на их месте наняли команду, чтобы потратить годы на разработку своего WAF решения с нуля?
А с другой стороны - там есть приоритизация фич, т.е. все равно никто не обязуется ее реализовать по вашему первому запросу. Может быть, если повезет.
А вы попробуйте просчитать экономику такого предложения. Допустим, что у вас есть десятки тысяч платящих клиентов. Сколько должен заплатить один клиент, чтобы вместо реализации каких-то фич, необходимых для сохранения существующей базы клиентов и её умножения, бросить ресурсы на хотелки этого одного клиента? При какой сумме это будет экономически выгодно разработчику?
Самая беда здесь, что коммерческий софт точно так же предоставляется по модели AS IS. Никто ни за что не отвечает.
Любая ответственность и гарантии в договоре будут умножать прайс на N.
Коллеги пользуются, например, энтерпрайз штуками а-ля RHEL и OpenShift - и там точно так же в баг трекере висят штуки годами, всем пофиг. А самое интересное, что действительно с этого корабля деваться некуда, потому что все продукты примерно одинаковы.
Если вы готовы платить ту самую сумму, умноженную на N, то на такой случай есть предложение: "Designated Engineer" - среди прочего, там "Roadmap visibility, prioritization of bug fixes, and prioritization of feature requests".
Но, например, нормальный тест конфига в nginx не завезли как будто до сих пор. В моем кейсе nginx -t хватал трафик с рабочего инстанса.
Как только о баге сообщили, так его и исправили: https://trac.nginx.org/nginx/ticket/1300 Между сообщением о баге и исправлением прошло несколько недель. Было это 5 лет назад. Как там, "ложечки нашлись, но осадочек остался"?
А как проверять конфиг без наличия ip на интерфейсе - очень интересный вопрос.
А в запуске nginx -t и нет необходимости. Если конфиг содержит ошибку, которую бы мог выявить nginx -t, то такой конфиг просто не будет применен и nginx продолжит работу со старым конфигом, сообщив об этом в лог.
Опция reuseport работает ровно так, как она работает в ядре.
Отдельная целая история - это модули, которые собраны по принципу - покупайте платный nginx, там все из коробки.
Все модули, которые были открытыми, так ими и остаются. Более того, постоянно прибавляют в функциональности и добавляются новые.
Модули N+ были написаны по многочисленным запросам от энтерпрайзных клиентов, которые готовы за них платить. Представьте себе, что если бы не эти модули, то не только их бы не было, но и не было множества другой, бесплатной функциональности, которую бы просто некому было писать. Разработчикам, которые работают полный рабочий день (а зачастую на самом деле даже больше) над одним проектом - тоже нужно кушать и кормить семью. Пожертвований, которые собирались до появления N+ - хватало только на оплату хостинга для сайта.
Грустно это все ))) опен сурс такой опен сурс
У вас есть и остается на выбор огромное количество бесплатных сторонних модулей, написанных и поддерживаемых энтузиастами - ни кто не запрещает продолжать ими пользоваться.
P.S. Любой написанный код - это чье-то время. Время человека имеет свою цену. Если человек пишет какой-то код в удовольствие, как хобби, то он просто сам неявно оплачивает это хобби из своего кармана. Чтобы иметь такую роскошь, оплачивать свое хобби, нужно уже иметь какой-то источник дохода. Странно, когда это нужно объяснять.
Вот только nginx там был совершенно не настроен на производительность и снижение задержек. В случае с Unit-ом можно было бы включить кэш keepalive соединений и выкрутить ручку в большое значение - это бы существенно снизило задержки без какого-либо негативного эффекта.
А в случае с PHP-FPM такое нормально работать не может, т.к. каждое keepalive соединение будет удерживать занятым один рабочий процесс c PHP постоянно и он будет простаивать, ожидая запроса конкретно в данном соединении. И если все его рабочие процессы будут заняты keepalive соединениями, то ни одно дополнительное соединение вообще не будет обработано и получим пресловутый "504 Gateway Timeout", как только число одновременных запросов превысит число рабочих процессов PHP-FPM.
Когда нет необходимости преобразовывать протокол, то не обязательно балансировку делать на уровне HTTP. И даже на уровне HTTP можно свести дополнительную задержку к паре миллисекунд. Но тут дело скорее в том, что PHP-FPM сам по себе медленный - там зачем-то делаются лишние сисколы, которых можно было бы избежать. При этом он в целом заброшен и не развивается. А его модель работы с соединениями и запросами - неизбежно вносит дополнительные задержки и успешно схлопывается под нагрузкой, что все и наблюдают при тестировании.
Мы уделяем большое внимание производительности и масштабируемости при разработке Unit-а, поэтому результаты не удивляют. Но, безусловно, есть ещё куда расти, т.к. не все идеи пока ещё реализованы и в будущем версиях показатели будут только улучшаться.
На самом деле наша (разработчиков Unit) цель - это довести его по функциональности до, как минимум, паритета с nginx, чтобы можно было без труда всегда выставлять его наружу. Сейчас его приходится ставить перед nginx в тех случаях, когда от nginx нужна некоторая дополнительная функциональность, которая пока ещё отсутствует в Unit.
Если бы в группе плацебо заболевали 100%, то общий показатель переболевших по стране составлял бы никак не 6,150 млн (по данным Яндекса - официальная статистика), а на порядок больше (с учетом плотности населения в регионах).
Вы же понимаете, что речь о числе заболевших в группе плацебо за время наблюдения, которое составляло всего пару месяцев. Почему вы это сравниваете с числом положительных ПЦР тестов по стране? Если время наблюдения устремить к бесконечности, то число заболевших в группе плацебо тоже будет стремиться к 100%.
Проблема в том, что статистически рабочие процессы стоящие выше в очереди - загружены сильнее, чем те, кто в конце (добавили себя в список слушающих последними при запуске). Всё это приводит к росту задержек из-за того, что в итоге часть ядер процессора оказывается перегружены работой, а другие недогружены.
Лимиты и `
worker_connections` то можно подкрутить. Но тогда зачем вообще другие рабочие процессы нужны, если все один обрабатывает.Как раз основная проблема - это неравномерное распределение нагрузки по рабочим процессам и, как следствие, ухудшение масштабируемости по ядрам.
php-fpm загнулся со 100 рабочими процессами, где Unit справился всего с 16 и обошел его на порядок. Вы предлагаете накрутить аж 512 процессов, но это же просто костыль, который наглядно демонстрирует насколько php-fpm убогий. Так ведь и Unit-у можно 512 процессов накрутить, но зачем? На сервере всегда есть другие задачи, под которые лучше память выделить.
Согласен, что может быть не совсем удачный пример. Я не разбираюсь в игровой индустрии, просто новость на слуху.
Но вот F5, например, тоже чуть ли не каждый год покупает по 1-2 компании и тут речь об авторских правах точно не идет. Так из приобретений только за последние пару лет: Shape Security, Silverline, Volterra,Threat Stack.
Там же написано, почему предложенный патч работать правильно не будет. И если в ядре нет хорошего решения, то его нет.
Отдельно интересно услышать, а каким образом это "очень обидный баг", ибо по сути это настолько мирооптимизация, что даже на бенчмарках измерить разницу от точно выверенного выставления affinity и числа рабочих процессов не так уж просто.
У Netflix действительно большая доля трафика благодаря CDN, которую им NGINX, Inc. помог построить с нуля. Заодно и FreeBSD подтянули.
Вы озвучили в комментах некие претензии и я на них ответил. Я не вижу никакого смысла спорить. Это как спорить с человеком, который сидя в лесу и наблюдая несколько деревьев вокруг себя - считает, что весь остальной лес абсолютно такой же.
Проблема в том, что наличие точки зрения не означает, что её нужно высказывать в любой удобный момент и по любому поводу.
Тут негативные комментарии про nginx есть не только от вас. Видимо все эти комментаторы считают, что данная новость о его авторе - это отличный повод, чтобы как-нибудь пнуть его детище, а не просто поблагодарить за работу и вклад, который он сделал. Или промолчать и пройти мимо, оставив свою точку зрения при себе.
Проблема в том, что большинство тех самых крупных компаний, о которых вы писали, очень чувствительно и строго относятся к раскрытию поставщиков своих решений, а потому со стороны не видно кто и у кого что покупает.
Почему вы думаете, что они так не сделали, если по ссылке прямым текстом написано "After an initial vendor investigation process, there was only one security solution that ticked all the boxes".
Обычно речь идет о суммах, когда просто берут и покупают компанию целиком. И такое, кстати, тоже регулярно происходит. Вот как недавно с Activision Blizzard. Думаете у Microsoft нет компетенций для разработки таких же продуктов? Но зачем, если проще и быстрее купить готовую компанию.
Равно как и у мелких. Какая-то банальщина. Багов нет только у тех продуктов, которыми никто не пользуется. Срок прошедший с момента обнаружения бага - это не критерий для приоритезации его исправления. Кто-то предпочитает заниматься исправлением багов в хронологическом порядке?
А ещё баги, как минимум, делятся на известные и неизвестные, и последние, как правило, хуже и неприятнее. Баг в KB - это уже более хороший баг.
Если бы могли бы - разработали бы. Многое упирается в кадры, кадры помноженные на время. Если в Lyft нашлась команда людей, которые смогли придумать и реализовать на должном уровне, да ещё у них было на это время и бизнес-воля у менеджмента - они это сделали.
Я понимаю, что в комментариях каждый второй бы свой nginx без проблем написал и повторил бы историю успеха на раз-два, но только, как правило, времени нет, и поэтому больше трети интернета предпочитает запускать на фронтенде вполне конкретный nginx.
Среди клиентов полно компаний из списка Fortune 500, в том числе из верхушки.
Это видимо СНГ опыт? Мой опыт говорит о том, что большинство американских компаний стремяться аутсорсить по максимуму любой непрофильный бизнес. Набирать людей и выращивать свою экспертизу - это капиталовложения, это время, которое упущено, это риски.
Вот взять, например, нашу историю успеха с компанией Audi. Им нужно решить конкретную задачу, а вы бы на их месте наняли команду, чтобы потратить годы на разработку своего WAF решения с нуля?
А вы попробуйте просчитать экономику такого предложения. Допустим, что у вас есть десятки тысяч платящих клиентов. Сколько должен заплатить один клиент, чтобы вместо реализации каких-то фич, необходимых для сохранения существующей базы клиентов и её умножения, бросить ресурсы на хотелки этого одного клиента? При какой сумме это будет экономически выгодно разработчику?
Любая ответственность и гарантии в договоре будут умножать прайс на N.
Если вы готовы платить ту самую сумму, умноженную на N, то на такой случай есть предложение: "Designated Engineer" - среди прочего, там "Roadmap visibility, prioritization of bug fixes, and prioritization of feature requests".
Как только о баге сообщили, так его и исправили: https://trac.nginx.org/nginx/ticket/1300
Между сообщением о баге и исправлением прошло несколько недель. Было это 5 лет назад. Как там, "ложечки нашлись, но осадочек остался"?
А в запуске nginx -t и нет необходимости. Если конфиг содержит ошибку, которую бы мог выявить nginx -t, то такой конфиг просто не будет применен и nginx продолжит работу со старым конфигом, сообщив об этом в лог.
Опция reuseport работает ровно так, как она работает в ядре.
Все модули, которые были открытыми, так ими и остаются. Более того, постоянно прибавляют в функциональности и добавляются новые.
Модули N+ были написаны по многочисленным запросам от энтерпрайзных клиентов, которые готовы за них платить. Представьте себе, что если бы не эти модули, то не только их бы не было, но и не было множества другой, бесплатной функциональности, которую бы просто некому было писать. Разработчикам, которые работают полный рабочий день (а зачастую на самом деле даже больше) над одним проектом - тоже нужно кушать и кормить семью. Пожертвований, которые собирались до появления N+ - хватало только на оплату хостинга для сайта.
У вас есть и остается на выбор огромное количество бесплатных сторонних модулей, написанных и поддерживаемых энтузиастами - ни кто не запрещает продолжать ими пользоваться.
P.S. Любой написанный код - это чье-то время. Время человека имеет свою цену. Если человек пишет какой-то код в удовольствие, как хобби, то он просто сам неявно оплачивает это хобби из своего кармана. Чтобы иметь такую роскошь, оплачивать свое хобби, нужно уже иметь какой-то источник дохода. Странно, когда это нужно объяснять.
Список обидных багов, которые wontfix?
Это Unit.
Раздача статики тут не влияет. А PHP-FPM настройкой nginx-а не исправить.
Вот только nginx там был совершенно не настроен на производительность и снижение задержек. В случае с Unit-ом можно было бы включить кэш keepalive соединений и выкрутить ручку в большое значение - это бы существенно снизило задержки без какого-либо негативного эффекта.
А в случае с PHP-FPM такое нормально работать не может, т.к. каждое keepalive соединение будет удерживать занятым один рабочий процесс c PHP постоянно и он будет простаивать, ожидая запроса конкретно в данном соединении. И если все его рабочие процессы будут заняты keepalive соединениями, то ни одно дополнительное соединение вообще не будет обработано и получим пресловутый "504 Gateway Timeout", как только число одновременных запросов превысит число рабочих процессов PHP-FPM.
Когда нет необходимости преобразовывать протокол, то не обязательно балансировку делать на уровне HTTP. И даже на уровне HTTP можно свести дополнительную задержку к паре миллисекунд. Но тут дело скорее в том, что PHP-FPM сам по себе медленный - там зачем-то делаются лишние сисколы, которых можно было бы избежать. При этом он в целом заброшен и не развивается. А его модель работы с соединениями и запросами - неизбежно вносит дополнительные задержки и успешно схлопывается под нагрузкой, что все и наблюдают при тестировании.
Мы уделяем большое внимание производительности и масштабируемости при разработке Unit-а, поэтому результаты не удивляют. Но, безусловно, есть ещё куда расти, т.к. не все идеи пока ещё реализованы и в будущем версиях показатели будут только улучшаться.
На самом деле наша (разработчиков Unit) цель - это довести его по функциональности до, как минимум, паритета с nginx, чтобы можно было без труда всегда выставлять его наружу. Сейчас его приходится ставить перед nginx в тех случаях, когда от nginx нужна некоторая дополнительная функциональность, которая пока ещё отсутствует в Unit.
Причем здесь февраль? Вы статью то читали вообще? Выборка с сентября по ноябрь 2020.
> И да, если устремить в бесконечность, то и в группе вакцинированных число заболевших возрастет.
Пропорционально рассчитанной эффективности.
Вы же понимаете, что речь о числе заболевших в группе плацебо за время наблюдения, которое составляло всего пару месяцев. Почему вы это сравниваете с числом положительных ПЦР тестов по стране? Если время наблюдения устремить к бесконечности, то число заболевших в группе плацебо тоже будет стремиться к 100%.