Про "кнопочный телефон без браузера" посмотрите https://habr.com/ru/post/575626/. TL;DR: троянский код с управлением через интернет в подобные телефоны зачастую шьют прямо на заводе, отсутствие браузера - не помеха.
Да, имеется в виду потеря соединений при закрытии сокетов, и соответственно при уменьшении количества рабочих процессов. Как недавно выяснилось, это приводило также к потере соединений при тестировании конфигурации, но этот негативный эффект легко исправить (и уже).
Грузить динамически — точно нет. Собирать по умолчанию — возможно, в рамках оптимизации политики "что мы собираем по умолчанию", она сейчас получается сильно отличающейся от того, что мы же собираем в пакетах.
Лимит на число соединений при использовании select(), он же FD_SETSIZE, задаётся, к сожалению, только при компиляции. И при этом влияет на скорость любого вызова select(), т.к. битовые массивы соответствующего размера приходится копировать между приложением и ядром.
Значение по умолчанию для FD_SETSIZE на Windows — 64, что совсем смешно. При сборке бинарников, выкладываемых на nginx.org, мы ставим FD_SETSIZE в 1024, что выглядит разумным компромиссом между скорость и количеством возможных соединений. Особенно учитывая, что основная задача nginx/Windows — это тестирование.
Если этого мало — можно пересобрать из исходников с любым устраивающим вас значением (инструкция по самостоятельной сборке — тут). Или прислать патч, меняющие значение, используемое при стандартной сборке, как-то обосновав новое значение. Тут важно понимать, что лимит — всё равно будет, ибо select(). Вопрос только — какой именно, и что это будет означать с точки зрения производительности.
Про "кнопочный телефон без браузера" посмотрите https://habr.com/ru/post/575626/. TL;DR: троянский код с управлением через интернет в подобные телефоны зачастую шьют прямо на заводе, отсутствие браузера - не помеха.
А при чём тут strong_equivalence, и что именно вы понимаете под этими словами? Ведь не strong equivalence principle же?
Что такое идемпотентность — известно из математики, и явно описывается в стандарте HTTP. А чтобы не лазить в словарь, мы и в документации описали.
Да, имеется в виду потеря соединений при закрытии сокетов, и соответственно при уменьшении количества рабочих процессов. Как недавно выяснилось, это приводило также к потере соединений при тестировании конфигурации, но этот негативный эффект легко исправить (и уже).
Грузить динамически — точно нет. Собирать по умолчанию — возможно, в рамках оптимизации политики "что мы собираем по умолчанию", она сейчас получается сильно отличающейся от того, что мы же собираем в пакетах.
Лимит на число соединений при использовании select(), он же FD_SETSIZE, задаётся, к сожалению, только при компиляции. И при этом влияет на скорость любого вызова select(), т.к. битовые массивы соответствующего размера приходится копировать между приложением и ядром.
Значение по умолчанию для FD_SETSIZE на Windows — 64, что совсем смешно. При сборке бинарников, выкладываемых на nginx.org, мы ставим FD_SETSIZE в 1024, что выглядит разумным компромиссом между скорость и количеством возможных соединений. Особенно учитывая, что основная задача nginx/Windows — это тестирование.
Если этого мало — можно пересобрать из исходников с любым устраивающим вас значением (инструкция по самостоятельной сборке — тут). Или прислать патч, меняющие значение, используемое при стандартной сборке, как-то обосновав новое значение. Тут важно понимать, что лимит — всё равно будет, ибо select(). Вопрос только — какой именно, и что это будет означать с точки зрения производительности.