Оксюморон? Возможно. Но хотелось бы изменить ваше мнение :-) Я серьёзно.
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 не такой уж и оксюморон, не так ли :-) Надеюсь я вас переубедил. Возможно нет.
Ну и поводу помощи со второй опцией, Максим или другие разработчики, помогите если можете. Если нет то нет, будет еще ждать годами :-)
Всех с наступающим! ))))))))))))))
