На ваш пример у меня есть свой пример. Сюжет тот же, но только помочь надо остановить насильника или террориста. К чему эти фантазии?
Очевидно, что преступники и террористы пользуются шифрованными каналами связи для подготовки своих преступлений. В то же время бывают и обратные ситуации, когда злоупотребляют полномочиями не для тех целей, которым по идее должны служить. Мир не состоит из черного и белого.
Прекрасная подмена: один разработчик -> разработчики, они однажды ответил на вопросы пользователя из списка рассылки сообщества -> охотно помогали.
Процитирую начало сообщения, на которое вы ссылаетесь: > Мы состоим в реестре организаторов распространения информации и
поэтому обязаны предоставлять в надзорный орган ключи tls сессий.
Видимо если бы бывший коллега не подсказал, то озвученная обязанность пропала или автор не продолжил бы использовать Apache, с которым у него уже все работало без проблем. К разработчикам Apache тоже вопросы?
Без ключа сертификат в принципе невозможно было сгенерировать. Подозреваю, что либо вы его сами загружали в процессе заказа и не обратили на это внимание, либо reg.ru где-то в процессе заказа сгенерировал ключ для вас и просил его сохранить.
Если они оказались в одном процессе, это значит, что соединение 2 пришло после того, как соединение 1 обработалось. Т.е. что в одном процессе, что в разных никакой параллельности не будет, так как сами соединения приходят последовательно, а не одновременно — параллельно обрабатывать просто нечего.
Обработка одного соединения - это не одно событие. Первое событие - лишь о том, что у нас вообще есть новое соединение. Рабочий процесс получает уведомление об этом событии, делает на соединении accept(), добавляет дескриптор нового соединения в ядро для мониторинга и далее может ждать новых событий. С этого момента все события на этом соединении будут обрабатываться только в данном рабочем процессе. А событий таких может быть тысячи: получены новые данные - событие, освободился буфер отправки - событие, случилась ошибка - событие, закрыли соединение - событие.
Более того. Ядро одновременно сообщает о множестве событий. Т.е. одним вызовом рабочий процесс может получить сразу сотни новых событий.
Так работают асинхронные сервера. Один рабочий процесс nginx может обрабатывать события на миллионах соединений.
Вот если бы все 12 соединений пришли одновременно и все почему-то оказались в первом процессе… но с чего бы? Первый процесс заберет первое соединение и пойдет его обрабатывать, второе заберет второй и так далее.
Первый процесс может забрать все 12 соединений. Обработка соединения сводится к вызову accept(). Я даже не уверен, что ядро вообще разбудит другие процессы, если все 12 соединений были им приняты за один такт обработки сетевого трафика. Но это не точно.
В любом случае, любая приоритезация одних рабочих процессов над другими - создает перекос. Как я уже упомянул выше, чаще всего рабочие процессы заняты ожиданием новых событий.
А нынче с HTTP/2 и веб-сокетами у нас часто преобладают долгоживущие соединения. Поэтому событие установки нового соединение - это одно сравнительно редкое событие. Зато каждое такое соединение затем порождает тысячи событий в процессе его обслуживания.
Один рабочий процесс имеет один поток. Поэтому в один момент времени он может из очереди брать и обрабатывать только одно событие. А сколько событий будет в очереди - зависит от того, сколько вернуло их ядро в одном вызове epoll_wait(). По умолчанию один вызов может вернуть до 512 событий.
Скорее всего не ляжет, т.к. исходящий порт для каждого соединения будет выбираться разный. Иначе как идентифицировать какие TCP пакеты какому соединению принадлежат?
Речь не идет, когда сервер максимально загружен и работает на пределе своих возможностей (чаще всего это не так и какое-то количество ресурсов остается свободно). Вы рассматриваете процесс обработки нагрузки бинарно: справился или не справился, успел - не успел. Но все гораздо сложнее.
Попробую объяснить максимально просто. Представьте, что у вас есть 12 соединений, на которых случились события. Предположим, что все эти соединения оказались в одном процессе. Значит этот процесс будет обрабатывать эти события следующим образом: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 последовательно. В результате наибольшая задержка будет при обработке 12-го события и она будет равна суммарному времени затраченному на обработку всех предыдущих 11 событий.
А теперь представьте, что у нас есть 4 ядра и запущено 4 рабочих процесса и соединения были распределены равномерно по этим процессам (по 3 соединения на процесс).
Тогда для каждого из процессов обработка всех событий будет выглядеть так: CPU1: 1, 2, 3. CPU2: 1, 2, 3. CPU3: 1, 2, 3. CPU4: 1, 2, 3.
Очевидно, что в этом случае будет ниже как средняя задержка, так и максимальная. 4 ядра работают параллельно друг другу и одновременно обрабатывается до 4-х событий.
Сервер будет отвечать на запросы в среднем быстрее, т.к. в первом случае он задействует вычислительную мощность всего одного ядра, а во втором всех 4-х. Суммарная вычислительная мощность, используемая для обработки событий, во втором случае будет в 4 раза выше.
Erratum: коллеги поправили, там не round-robin, а хэш от ip и порта сервера и клиента. Что ещё хуже, т.к. теоретически можно попытаться умышленно обмануть механизм и упростить DoS-атаку, если всё это смотрит в интернет.
Как минимум потому, что у reuseport есть своя проблема с распределением нагрузки по рабочим процессам. Там соединения раскидываются просто в режими round-robin и это неплохо работает, когда все соединения абсолютно одинаковы и дают одинаковую нагрузку. В реальности же часто бывает так, что соединения и запросы пользователей в них могут быть сильно разными. Могут быть соединения в которых вообще нет никаких запросов - их браузер может открывать "про запас", а могут быть тяжелые соединения, создающие большую нагрузку на рабочий процесс. Одни соединения долгоживущие, а другие короткоживущие. В итоге процесс, которому попались тяжелые долгоживущие соединения - будет перегружен, а те, в которых больше легких и короткоживущих - недогружены.
Идеальная ситуация - это когда все процессы разбирают соединения из общей очереди по мере наличия у них свободных ресурсов для их обработки. А это невозможно с reuseport.
Проблема в том, что статистически рабочие процессы стоящие выше в очереди - загружены сильнее, чем те, кто в конце (добавили себя в список слушающих последними при запуске). Всё это приводит к росту задержек из-за того, что в итоге часть ядер процессора оказывается перегружены работой, а другие недогружены.
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 решения с нуля?
А с другой стороны - там есть приоритизация фич, т.е. все равно никто не обязуется ее реализовать по вашему первому запросу. Может быть, если повезет.
А вы попробуйте просчитать экономику такого предложения. Допустим, что у вас есть десятки тысяч платящих клиентов. Сколько должен заплатить один клиент, чтобы вместо реализации каких-то фич, необходимых для сохранения существующей базы клиентов и её умножения, бросить ресурсы на хотелки этого одного клиента? При какой сумме это будет экономически выгодно разработчику?
На ваш пример у меня есть свой пример. Сюжет тот же, но только помочь надо остановить насильника или террориста. К чему эти фантазии?
Очевидно, что преступники и террористы пользуются шифрованными каналами связи для подготовки своих преступлений. В то же время бывают и обратные ситуации, когда злоупотребляют полномочиями не для тех целей, которым по идее должны служить. Мир не состоит из черного и белого.
Прекрасная подмена:
один разработчик -> разработчики, они
однажды ответил на вопросы пользователя из списка рассылки сообщества -> охотно помогали.
Процитирую начало сообщения, на которое вы ссылаетесь:
> Мы состоим в реестре организаторов распространения информации и поэтому обязаны предоставлять в надзорный орган ключи tls сессий.
Видимо если бы бывший коллега не подсказал, то озвученная обязанность пропала или автор не продолжил бы использовать Apache, с которым у него уже все работало без проблем. К разработчикам Apache тоже вопросы?
Без ключа сертификат в принципе невозможно было сгенерировать. Подозреваю, что либо вы его сами загружали в процессе заказа и не обратили на это внимание, либо reg.ru где-то в процессе заказа сгенерировал ключ для вас и просил его сохранить.
Вас смущает, что Москва следует мировым тенденциям в том, что таких заводов в черте города быть не должно?
Обработка одного соединения - это не одно событие. Первое событие - лишь о том, что у нас вообще есть новое соединение. Рабочий процесс получает уведомление об этом событии, делает на соединении accept(), добавляет дескриптор нового соединения в ядро для мониторинга и далее может ждать новых событий. С этого момента все события на этом соединении будут обрабатываться только в данном рабочем процессе. А событий таких может быть тысячи: получены новые данные - событие, освободился буфер отправки - событие, случилась ошибка - событие, закрыли соединение - событие.
Более того. Ядро одновременно сообщает о множестве событий. Т.е. одним вызовом рабочий процесс может получить сразу сотни новых событий.
Так работают асинхронные сервера. Один рабочий процесс nginx может обрабатывать события на миллионах соединений.
Первый процесс может забрать все 12 соединений. Обработка соединения сводится к вызову accept(). Я даже не уверен, что ядро вообще разбудит другие процессы, если все 12 соединений были им приняты за один такт обработки сетевого трафика. Но это не точно.
В любом случае, любая приоритезация одних рабочих процессов над другими - создает перекос. Как я уже упомянул выше, чаще всего рабочие процессы заняты ожиданием новых событий.
А нынче с HTTP/2 и веб-сокетами у нас часто преобладают долгоживущие соединения. Поэтому событие установки нового соединение - это одно сравнительно редкое событие. Зато каждое такое соединение затем порождает тысячи событий в процессе его обслуживания.
Один рабочий процесс имеет один поток. Поэтому в один момент времени он может из очереди брать и обрабатывать только одно событие. А сколько событий будет в очереди - зависит от того, сколько вернуло их ядро в одном вызове epoll_wait(). По умолчанию один вызов может вернуть до 512 событий.
К моменту, когда эти шансы упадут заметно - нагрузка на воркер и задержки также возрастут заметно. А именно этого хотелось бы избежать.
Скорее всего не ляжет, т.к. исходящий порт для каждого соединения будет выбираться разный. Иначе как идентифицировать какие TCP пакеты какому соединению принадлежат?
Речь не идет, когда сервер максимально загружен и работает на пределе своих возможностей (чаще всего это не так и какое-то количество ресурсов остается свободно). Вы рассматриваете процесс обработки нагрузки бинарно: справился или не справился, успел - не успел. Но все гораздо сложнее.
Попробую объяснить максимально просто. Представьте, что у вас есть 12 соединений, на которых случились события. Предположим, что все эти соединения оказались в одном процессе. Значит этот процесс будет обрабатывать эти события следующим образом: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 последовательно. В результате наибольшая задержка будет при обработке 12-го события и она будет равна суммарному времени затраченному на обработку всех предыдущих 11 событий.
А теперь представьте, что у нас есть 4 ядра и запущено 4 рабочих процесса и соединения были распределены равномерно по этим процессам (по 3 соединения на процесс).
Тогда для каждого из процессов обработка всех событий будет выглядеть так:
CPU1: 1, 2, 3.
CPU2: 1, 2, 3.
CPU3: 1, 2, 3.
CPU4: 1, 2, 3.
Очевидно, что в этом случае будет ниже как средняя задержка, так и максимальная. 4 ядра работают параллельно друг другу и одновременно обрабатывается до 4-х событий.
Сервер будет отвечать на запросы в среднем быстрее, т.к. в первом случае он задействует вычислительную мощность всего одного ядра, а во втором всех 4-х. Суммарная вычислительная мощность, используемая для обработки событий, во втором случае будет в 4 раза выше.
Erratum: коллеги поправили, там не round-robin, а хэш от ip и порта сервера и клиента. Что ещё хуже, т.к. теоретически можно попытаться умышленно обмануть механизм и упростить DoS-атаку, если всё это смотрит в интернет.
Как минимум потому, что у reuseport есть своя проблема с распределением нагрузки по рабочим процессам. Там соединения раскидываются просто в режими round-robin и это неплохо работает, когда все соединения абсолютно одинаковы и дают одинаковую нагрузку. В реальности же часто бывает так, что соединения и запросы пользователей в них могут быть сильно разными. Могут быть соединения в которых вообще нет никаких запросов - их браузер может открывать "про запас", а могут быть тяжелые соединения, создающие большую нагрузку на рабочий процесс. Одни соединения долгоживущие, а другие короткоживущие. В итоге процесс, которому попались тяжелые долгоживущие соединения - будет перегружен, а те, в которых больше легких и короткоживущих - недогружены.
Идеальная ситуация - это когда все процессы разбирают соединения из общей очереди по мере наличия у них свободных ресурсов для их обработки. А это невозможно с reuseport.
Проблема в том, что статистически рабочие процессы стоящие выше в очереди - загружены сильнее, чем те, кто в конце (добавили себя в список слушающих последними при запуске). Всё это приводит к росту задержек из-за того, что в итоге часть ядер процессора оказывается перегружены работой, а другие недогружены.
Лимиты и `
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 решения с нуля?
А вы попробуйте просчитать экономику такого предложения. Допустим, что у вас есть десятки тысяч платящих клиентов. Сколько должен заплатить один клиент, чтобы вместо реализации каких-то фич, необходимых для сохранения существующей базы клиентов и её умножения, бросить ресурсы на хотелки этого одного клиента? При какой сумме это будет экономически выгодно разработчику?