Re: Nginx + Windows = Дружба? Время пришло!

Пт Дек 16 06:22:53 UTC 2016

Увидел много слов о том, что теперь на Windows можно Highload, но нн увидел
ни одного слова о том, что на Windows стали делать Highload. Есть какие-то
отчеты, которые показывают, что доля этой ОС на web-серверах начала расти и
ей срочно нужно уделять больше времени?

пт, 16 дек. 2016 г., 7:21 Илья Шипицин <chipitsine на gmail.com>:

>
>
> 16 декабря 2016 г., 8:23 пользователь sofiamay <
> nginx-forum на forum.nginx.org> написал:
>
> Оксюморон? Возможно. Но хотелось бы изменить ваше мнение :-) Я серьёзно.
>
> Maxim Dounin, мне кажется пришло время сделать шаг навстречу Windows.
> Осталось то всего ничего!
>
> Давайте просто посмотрим на ситуацию с Winodws с точки зрения сложившегося
> в
> IT обществе мнения. Windows долгие годы была в аутсайдерах и не принималась
> всерьез, имела много проблем с производительностью, безопасностью и в целом
> мало подходила для полноценного продакшен сервера под высокую нагрузку. Для
> многих HighLoad и Windows это несовместимые понятия и, как известно, сами
> разработчики Nginx уделяют очень мало внимания этой платформе.
>
> Но давайте разберемся, а что же сейчас происходит на самом деле.
> Современная
> Windows Server это производительная, безопасная и надёжная платформа, а
> NTFS
> не сильно хуже EXT4. Уже давно появились SSD, тюнинг реестра для поддержки
> огромного числа соединений делается не сильно сложнее тюнинга
> /etc/sysctl.conf и в целом Windows уже давно позволяет создавать
> высокопроизводительные решения. Я не буду говорить о профессиональном
> HighLoad сегменте, тут конечно Linux вне конкуренции.
>
> Теперь давайте разберемся с Nginx. Что долгое время мешает ему стать
> сервером номер 1 для Windows? Список проблем БЫЛ довольно скромный и
> большинство из этих проблем уже решены!
>
> 1. Хоть и возможен запуск нескольких рабочих процессов, только один из них
> реально работает. Это происходит потому, что для обработки соединений
> используется медленный select. Необходимо реализовать использование портов
> завершения ввода-вывода (I/O completion ports) в качестве метода обработки
> соединений и реализовать использование нескольких рабочих нитей внутри
> одного рабочего процесса.
>
> Пока не реализовано.
>
> 2. Рабочий процесс может обслуживать не более 1024 одновременных
> соединений.
>
> Решено: FD_SETSIZE (неизвестно с какой версии)
>
> 3. Кэш и другие модули, требующие поддержки разделяемой памяти, не работают
> под Windows Vista и более поздними версиями.
>
> Решено: ASLR (с версии 1.9.0)
>
> 4. Работают все модули, кроме UDP проксирования, XSLT-фильтра, фильтра
> изображений, модуля GeoIP и встроенного языка Perl.
>
> Можно считать что почти решено: фильтр изображений и GeoIP собираются если
> захотеть, просто предварительно нужно собрать libgd и libmaxminddb (GeoIP
> 2)
> которые требуются для сборки. Perl уже никто не пользуется, под Windows
> легко собираются LUAJIT модуль с кучей lua-resty расширений, включая
> non-blocking работу с Mysql, Redis, Memcached, Postgres и т.д. Ну а без
> проксирования UDP и XSLT-фильтра как нибудь проживем, сомневаюсь что вообще
> этим кто-либо пользуется.
>
> 5. Правильная работа с FAST-CGI PHP (ввиду отсутствия PHP-FPM для Windows)
> которая заключается в ограничении кол-ва соединений равным одному на каждый
> запущенный поток PHP ([max_conns=1] в upstream) и помещение всех других
> соединений в очередь ([queue число timeout=время] в upstream). Без этих
> двух
> настроек работа с PHP под мало-мальской нагрузкой невозможна.
>
> Частично решено: сначала разработчики не хотели открыть эти опции. Но...
> Прошел год и вот это свершилось. Я уже было открыл шампанское, пригласил
> коллег, но отметить это событие мы так и не смогли, потому что разработчики
> почему-то открыли опции не до конца. Пользователям стала доступна опция
> max_conns с версии 1.11.5, Но она бесполезна без возможности настройки
> очереди ([queue число timeout=время] в upstream) поскольку при
> использовании
> max_conns=1 сервер отдаёт 502 при превышении одновременных подключений над
> числом FAST-CGI потоков.Запросы к FAST-CGI должны помещаться в очередь, по
> крайне мере до изобретения PHP-FPM для Windows. Уже не раз говорил и
> просил,
> откройте эти две настройки, без них на Windows никак. Увы открыли только
> одну.
>
> Максим, а теперь давайте подведём итоги. Вашими стараниями и стараниями
> других разработчиков Nginx постепенно обретает полноценную поддержку
> Windows, в то время как сама Windows давно готова и прямо-таки ждёт Nginx с
> распростёртыми объятиями. Большинство проблем Nginx под Windows практически
> решены, осталось всего две:
>
> 1. Перейти на использование IOCP/Multiple-Thread чтобы избавиться от select
> для connections и "только 1 процесс работает".
> 2. Открыть для использования PHP вторую жизненно важную опцию (очередь к
> upstream).
>
> И всё. В буквальном смысле. Т.е. Nginx и Windows уже влюблены друг в друга.
> Теперь осталось решить пару вопросов и можно подавать заявление в загс.
>
> Если посмотреть в исходники, то пробный модуль IOCP был написан в 2012 и
> потом заброшен. Понятно что рано или поздно кто-нибудь допишет этот модуль.
> Понятно, что рано или поздно будет реализована Multiple-Thread модель. 5
> лет
> ждём, еще столько же подождем. Но второй вопрос можно легко решить уже
> сейчас.
>
> Максим, хотелось бы попросить вас и всех других разработчиков, кому не
> безразлична эта тема. Помогите решить хотя бы одну из оставшихся двух
> проблем. Я не знаю, как в круге разработчиков решаются подобные вопросы, но
>
>
> подобные вопросы решаются написанием патчей
>
>
> пожалуйста, помогите повлиять на открытие второй необходимой для Windows
> опции (я говорю об очереди к upstream).
>
> Если открыть эту вторую опцию, то уже сейчас можно будет прекрасно работать
> на windows с 50k одновременных подключений к PHP. Применив оптимизации
> (патч
> GetLongPathNameW, исправление времени запуска с ssl и FD_SETSIZE) Nginx
> будет летать как самолёт (конечно не принимая во внимание select). Это
> подойдёт для большинства проектов, многие смогут перейти на Windows VPS, им
> не придётся изучать Linux. Это огромный шаг вперёд.
>
> Пусть с одним рабочим процессом и select для connections но это будет
> нормально работать. И пока пользователи будут осваивать Nginx под Windows
> через года подоспеет IOCP/Multiple-Thread.
>
> Так что работа в полную силу под Windows не такой уж и оксюморон, не так ли
> :-) Надеюсь я вас переубедил. Возможно нет.
> Ну и поводу помощи со второй опцией, Максим или другие разработчики,
> помогите если можете. Если нет то нет, будет еще ждать годами :-)
>
> Всех с наступающим! ))))))))))))))
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,271476,271578#msg-271578
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20161216/36418954/attachment-0001.html>