<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">16 декабря 2016 г., 8:23 пользователь sofiamay <span dir="ltr"><<a href="mailto:nginx-forum@forum.nginx.org" target="_blank">nginx-forum@forum.nginx.org</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Оксюморон? Возможно. Но хотелось бы изменить ваше мнение :-) Я серьёзно.<br>
<br>
Maxim Dounin, мне кажется пришло время сделать шаг навстречу Windows.<br>
Осталось то всего ничего!<br>
<br>
Давайте просто посмотрим на ситуацию с Winodws с точки зрения сложившегося в<br>
IT обществе мнения. Windows долгие годы была в аутсайдерах и не принималась<br>
всерьез, имела много проблем с производительностью, безопасностью и в целом<br>
мало подходила для полноценного продакшен сервера под высокую нагрузку. Для<br>
многих HighLoad и Windows это несовместимые понятия и, как известно, сами<br>
разработчики Nginx уделяют очень мало внимания этой платформе.<br>
<br>
Но давайте разберемся, а что же сейчас происходит на самом деле. Современная<br>
Windows Server это производительная, безопасная и надёжная платформа, а NTFS<br>
не сильно хуже EXT4. Уже давно появились SSD, тюнинг реестра для поддержки<br>
огромного числа соединений делается не сильно сложнее тюнинга<br>
/etc/sysctl.conf и в целом Windows уже давно позволяет создавать<br>
высокопроизводительные решения. Я не буду говорить о профессиональном<br>
HighLoad сегменте, тут конечно Linux вне конкуренции.<br>
<br>
Теперь давайте разберемся с Nginx. Что долгое время мешает ему стать<br>
сервером номер 1 для Windows? Список проблем БЫЛ довольно скромный и<br>
большинство из этих проблем уже решены!<br>
<br>
1. Хоть и возможен запуск нескольких рабочих процессов, только один из них<br>
реально работает. Это происходит потому, что для обработки соединений<br>
используется медленный select. Необходимо реализовать использование портов<br>
завершения ввода-вывода (I/O completion ports) в качестве метода обработки<br>
соединений и реализовать использование нескольких рабочих нитей внутри<br>
одного рабочего процесса.<br>
<br>
Пока не реализовано.<br>
<br>
2. Рабочий процесс может обслуживать не более 1024 одновременных<br>
соединений.<br>
<br>
Решено: FD_SETSIZE (неизвестно с какой версии)<br>
<br>
3. Кэш и другие модули, требующие поддержки разделяемой памяти, не работают<br>
под Windows Vista и более поздними версиями.<br>
<br>
Решено: ASLR (с версии 1.9.0)<br>
<br>
4. Работают все модули, кроме UDP проксирования, XSLT-фильтра, фильтра<br>
изображений, модуля GeoIP и встроенного языка Perl.<br>
<br>
Можно считать что почти решено: фильтр изображений и GeoIP собираются если<br>
захотеть, просто предварительно нужно собрать libgd и libmaxminddb (GeoIP 2)<br>
которые требуются для сборки. Perl уже никто не пользуется, под Windows<br>
легко собираются LUAJIT модуль с кучей lua-resty расширений, включая<br>
non-blocking работу с Mysql, Redis, Memcached, Postgres и т.д. Ну а без<br>
проксирования UDP и XSLT-фильтра как нибудь проживем, сомневаюсь что вообще<br>
этим кто-либо пользуется.<br>
<br>
5. Правильная работа с FAST-CGI PHP (ввиду отсутствия PHP-FPM для Windows)<br>
которая заключается в ограничении кол-ва соединений равным одному на каждый<br>
запущенный поток PHP ([max_conns=1] в upstream) и помещение всех других<br>
соединений в очередь ([queue число timeout=время] в upstream). Без этих двух<br>
настроек работа с PHP под мало-мальской нагрузкой невозможна.<br>
<br>
Частично решено: сначала разработчики не хотели открыть эти опции. Но...<br>
Прошел год и вот это свершилось. Я уже было открыл шампанское, пригласил<br>
коллег, но отметить это событие мы так и не смогли, потому что разработчики<br>
почему-то открыли опции не до конца. Пользователям стала доступна опция<br>
max_conns с версии 1.11.5, Но она бесполезна без возможности настройки<br>
очереди ([queue число timeout=время] в upstream) поскольку при использовании<br>
max_conns=1 сервер отдаёт 502 при превышении одновременных подключений над<br>
числом FAST-CGI потоков.Запросы к FAST-CGI должны помещаться в очередь, по<br>
крайне мере до изобретения PHP-FPM для Windows. Уже не раз говорил и просил,<br>
откройте эти две настройки, без них на Windows никак. Увы открыли только<br>
одну.<br>
<br>
Максим, а теперь давайте подведём итоги. Вашими стараниями и стараниями<br>
других разработчиков Nginx постепенно обретает полноценную поддержку<br>
Windows, в то время как сама Windows давно готова и прямо-таки ждёт Nginx с<br>
распростёртыми объятиями. Большинство проблем Nginx под Windows практически<br>
решены, осталось всего две:<br>
<br>
1. Перейти на использование IOCP/Multiple-Thread чтобы избавиться от select<br>
для connections и "только 1 процесс работает".<br>
2. Открыть для использования PHP вторую жизненно важную опцию (очередь к<br>
upstream).<br>
<br>
И всё. В буквальном смысле. Т.е. Nginx и Windows уже влюблены друг в друга.<br>
Теперь осталось решить пару вопросов и можно подавать заявление в загс.<br>
<br>
Если посмотреть в исходники, то пробный модуль IOCP был написан в 2012 и<br>
потом заброшен. Понятно что рано или поздно кто-нибудь допишет этот модуль.<br>
Понятно, что рано или поздно будет реализована Multiple-Thread модель. 5 лет<br>
ждём, еще столько же подождем. Но второй вопрос можно легко решить уже<br>
сейчас.<br>
<br>
Максим, хотелось бы попросить вас и всех других разработчиков, кому не<br>
безразлична эта тема. Помогите решить хотя бы одну из оставшихся двух<br>
проблем. Я не знаю, как в круге разработчиков решаются подобные вопросы, но<br></blockquote><div><br></div><div>подобные вопросы решаются написанием патчей<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
пожалуйста, помогите повлиять на открытие второй необходимой для Windows<br>
опции (я говорю об очереди к upstream).<br>
<br>
Если открыть эту вторую опцию, то уже сейчас можно будет прекрасно работать<br>
на windows с 50k одновременных подключений к PHP. Применив оптимизации (патч<br>
GetLongPathNameW, исправление времени запуска с ssl и FD_SETSIZE) Nginx<br>
будет летать как самолёт (конечно не принимая во внимание select). Это<br>
подойдёт для большинства проектов, многие смогут перейти на Windows VPS, им<br>
не придётся изучать Linux. Это огромный шаг вперёд.<br>
<br>
Пусть с одним рабочим процессом и select для connections но это будет<br>
нормально работать. И пока пользователи будут осваивать Nginx под Windows<br>
через года подоспеет IOCP/Multiple-Thread.<br>
<br>
Так что работа в полную силу под Windows не такой уж и оксюморон, не так ли<br>
:-) Надеюсь я вас переубедил. Возможно нет.<br>
Ну и поводу помощи со второй опцией, Максим или другие разработчики,<br>
помогите если можете. Если нет то нет, будет еще ждать годами :-)<br>
<br>
Всех с наступающим! ))))))))))))))<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?21,271476,271578#msg-271578" rel="noreferrer" target="_blank">https://forum.nginx.org/read.<wbr>php?21,271476,271578#msg-<wbr>271578</a><br>
<br>
______________________________<wbr>_________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-ru</a></blockquote></div><br></div></div>