NGINX — История перерождения под Windows

    Раз уж тут у нас «неделя» nginx, например тут или тут, то попробую и я внести свою, так сказать, лепту. Речь пойдет про nginx 4 windows, а именно про более-менее официальную сборку для этой пропритарной, некоторыми не очень любимой платформы.

    Почему Windows. Все просто, в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа. И от этих требований к платформе, например в ультимативной форме озвученных клиентом, никуда не денешься.
    И раз уж имеем Windows, но не хочется мучиться с IIS, apache и иже с ними, если хочется использовать любимые инструменты, а nginx однозначно к ним относится, то приходится иногда мириться даже с некоторыми ограничениями на этой платформе. Вернее приходилось…

    Хотя нужно заметить, что даже с этими ограничениями, nginx даст фору практически любому веб-серверу под windows по многим факторам, в том числе по стабильности, потреблению памяти, а главное производительности.

    Спешу сразу поделится хорошей новостью — больше ограничений, критичных к высокой производительности, при использовании nginx под windows практически не существует, и последнее из критичных, с высокой долей вероятности, тоже скоро отпадет. Но по порядку…

    Здесь описаны известные проблемы nginx 4 windows, а именно:

    • Рабочий процесс может обслуживать не более 1024 одновременных соединений.
    • Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.
    • Хоть и возможен запуск нескольких рабочих процессов, только один из них реально работает.

    Я немного изменил порядок, т.к. именно в такой последовательности я разбирался с этими ограничениями, так сказать отсортировано «исторически».

    1024 одновременных соединений


    На самом деле это не правда, вернее не совсем правда — nginx с незапамятных времен можно было собрать под Windows без этого ограничения — нужно было просто на этапе сборки определить FD_SETSIZE равным нужному вам количеству соединений.
    Например для VS добавив директиву --with-cc-opt=-DFD_SETSIZE=10240, воркер nginx сможет управляться с 10K одновременными соединениями, если в конфигурации вы укажете worker_connections 10240;.

    Кэш и другие модули, требующие поддержки разделяемой памяти


    Все эти функции и модули до недавнего времени действительно не работали под Windows, начиная с версии x64 или там где по умолчанию вся система работает с включенным ASLR.
    Причем отключение ASLR для nginx ничего не меняет, т.к. функции для работы с shared memory зашиты глубоко в kernel, т.е. ASLR (а с ним вероятно и DEP, с ним почему-то не получалось) нужно отключать для всей системы.

    Это на самом деле довольно не маленький список функционала: Кэш, любые зоны, соответственно и limit_req и т.д. и т.п. Кстати без поддержки разделяемой памяти гораздо труднее было бы убрать 3-е ограничение, т.е. реализовать поддержку multiple workers под windows.

    Не буду утомлять читателя как я с этим боролся, но совместно с Максом (спасибо mdounin) мы таки допилили это до релизной версии. Немного об этом, кому интересно см. под спойлером или в исходниках hg.nginx.org или github
    Немного теории...
    Сама разделяемая память может быть использована и с рандомизацией адресного пространства. Одно другому как бы не мешает, просто при включенном ASLR вы в другом процессе практически гарантировано получите указатель на «ту же память», но под другим адресом. Это на самом деле не критично, пока содержимое этого пространства само не содержит прямых указателей, aka pointer. Т.е. указатели-смещения относительно начального адреса shmem допустимы, но не прямые указатели как они есть.
    Соответственно без того чтобы переписать весь функционал, работающий с pointer внутри shared mem в nginx — есть единственный вариант, обмануть заставить таки windows выдать ссылку на shmem под постоянным для всех рабочих процессов, адресом. Ну а далее все не очень сложно, на самом деле.
    Начало дискуссии про это можно почитать здесь. Максим, кстати починил упущенную мной проблему (remapping), иногда возникающую после перезагрузки воркеров (reload налету).
    Viva open source!

    Т.е. официально это ограничение больше не действует с Release 1.9.0 от 28 Apr 2015:
    Feature: shared memory can now be used on Windows versions with 
    address space layout randomization.
    

    Только один рабочий процесс реально работает.


    В nginx есть процесс мастер и дочерние процессы, называемые рабочими или worker.
    Под windows у nginx может быть запущено несколько рабочих процессов, т.е. указав в конфигурации "worker_processes 4;", вы заставите мастера запустить четыре дочерних рабочих процесса. Проблема состоит в том, что только один из них, «украв» listener-соединение у мастера (используя SO_REUSEADDR) будет действительно слушать этот сокет, т.е. делать accept входящих соединений. В результате же у других воркеров — нет входящих соединений — нет работы.
    Это ограничение связано с технической реализацией winsock, и единственный способ получить распределенное listener-соединение для всех рабочих процессов в Windows — это клонировать сокет из мастер-процесса, т.е. использовать inherited handle от сокета из него.
    Кому интересны подробности реализации, могут посмотреть их под спойлером или в исходниках, пока только у меня на гитхаб.
    Подробнее...
    Начнем с того, что даже если запускать дочерние процессы (CreateProcess), используя bInheritHandle=TRUE, и установив SECURITY_ATTRIBUTES::bInheritHandle при создании сокета тоже равным TRUE, скорее всего у вас ничего не выйдет, т.е. в рабочем процессе используя этот handle, вы получите «failed (10022: An invalid argument was supplied)». А «успешно» продублировав этот сокет с помощью DuplicateHandle, дублированный handle тоже не примет ни одна функция работающая с сокетами (вероятно с ошибкой 10038 — WSAENOTSOCK).
    Почему так происходит приоткрывает одна цитата из MSDN — DuplicateHandle:
    Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object. To duplicate a socket handle, use the WSADuplicateSocket function.
    Проблема в том, что для дублирования handle с помощью WSADuplicateSocket, необходимо заранее знать pid процесса, т.е. это нельзя сделать до того как процесс был бы запущен.
    В результате, чтобы сообщить дочернему процессу информацию полученную мастером от WSADuplicateSocket, необходимую для создания сокета-клона в рабочем процессе — имеем два варианта, либо использовать что-нибудь вида IPC, например как это описано в MSDN — WSADuplicateSocket, либо передать это через shared memory (благо мы уже это выше починили).
    Я решил использовать второй вариант, т.к. считаю, что это наименее трудоемкий из двух и наиболее быстрый способ реализации наследования соединения.
    Ниже изменения в алгоритме запуска рабочих процессов под windows (помечены *):
    • Мастер-процесс создает все listener-сокеты;
    • [cycle] Мастер-процесс создает рабочий процесс;
    • * [win32] мастер вызывает новую функцию ngx_share_listening_sockets: для каждого listener-сокет опрашивается информация (для наследования) конкретно для этого нового воркера, («клонированная» через WSADuplicateSocket для pid), которая будет сохранена в shared memory — shinfo (protocol structure);
    • Мастер-процесс ждет пока worker установит событие о готовности — event «worker_nnn»;
    • * [win32] Рабочий процесс выполняет новую функцию ngx_get_listening_share_info для получения информации наследования shinfo, которая будет использоваться для создания нового дескриптора сокета для shared listener-сокета мастер-процесса;
    • * [win32] Рабочий процесс создает все listener-сокеты, используя информацию shinfo от мастер-процесса;
    • Рабочий процесс устанавливает событие — event «worker_nnn»;
    • Мастер-процесс прекращает ожидание, и создает следующий рабочий процесс, повторяя [cycle].

    Если нужно, здесь ссылка на дискуссию о фиксе, дабы она будет.

    В результате, nginx под windows запускает теперь N «полноценных», с точки зрения «прослушивания», а главное установления соединения, рабочих процессов, которые обрабатывают входящие соединения действительно параллельно.

    Этот фикс правда еще лежит «пул-реквестом» (я отправил changeset в nginx-dev), но его уже можно попробовать например скачав с моего github и самостоятельно собрав под windows. Если будут желающие выложу куда-нибудь бинарник.

    Я довольно долго истязал свое железо, гоняя это тестами и под нагрузочными «скриптами» — результат, все воркеры нагружены более-менее равномерно и действительно работают параллельно. Также я пробовал на лету (reload-ом) перезагружать nginx и случайным образом «убивал» некоторых воркеров имитируя «crash» последних — все работает без малейшего нарекания.
    Пока проявился единственный «недостаток», имхо — если запустить
    netstat /abo | grep LISTEN
    
    то вы увидите только мастер-процесс в списке «слушателей», хотя в реальности как раз он никогда не устанавливает соединение, только его дочерние рабочие процессы.

    Кстати, мой опыт пока говорит, что accept_mutex для windows-платформы вероятно нужно отключать "accept_mutex off;", т.к. по крайней мере на моих тестовых системах, с включенным accept_mutex они работали ощутимо медленнее, чем с выключенным. Но это думаю каждый должен проверять экспериментально (т.к. зависит от кучи параметров, типа количество ядер, воркеров, keep-alive соединений и т.д. и т.п.).

    Ну и как без красивых табличек с числами сравнения производительности, до (первый столбец помечен **NF) и после.
    Тест сделан на Windows7 — i5-2400 cpu @ 3.10GHz (4 core).
    Request: статика, 452 байта (+ header) — маленькие gif-иконки.
    Workers x Concur. 1 x 5 **NF 2 x 5 4 x 5 4 x 15
    Transactions 5624 hits 11048 hits 16319 hits 16732 hits
    Availability 100.00 % 100.00 % 100.00 % 100.00 %
    Elapsed time 2.97 secs 2.97 secs 2.97 secs 2.96 secs
    Data transferred 2.42 MB 4.76 MB 7.03 MB 7.21 MB
    Response time 0.00 secs 0.00 secs 0.00 secs 0.00 secs
    Transaction rate 1893.60 trans/sec 3719.87 trans/sec 5496.46 trans/sec 5645.07 trans/sec
    Throughput 0.82 MB/sec 1.60 MB/sec 2.37 MB/sec 2.43 MB/sec
    Concurrency 4.99 4.99 4.99 14.92
    Successful transactions 5624 11048 16319 16732
    Failed transactions 0 0 0 0
    Longest transaction 0.11 0.11 0.11 0.11
    Shortest transaction 0.00 0.00 0.00 0.00

    И да пребудет с вами nginx и под windows.
    Support the author
    Share post

    Similar posts

    Comments 81

      +8
      Попахивает мировым прорывом =) windows-админы будут годами благодарить автора
        +6
        Не знаю как там насчет «мирового прорыва», вы не представляете насколько я сам себе «благодарен» (а Игорю, Максу и всей команде nginx — за сам nginx под винду).
        Не потому что не люблю например тот же IIS или апач, — я даже умею их готовить, а просто разница — все же небо и земля. Ну и потому-что — open source.
        Ну а последний фикс позволяет мне делать например ту же балансировку без «всяких» линуксовых (VM) промеж, т.е. прямо в винде.
        А вы попробуйте на досуге уговорить например того же корпоративного клиента, поставить где-нибудь линукс, если «у нас везде только виндовс» (причем врет ведь — знаю что врет) и его безопасник кричит «а как я на него антивирус поставлю», «а полиси» и т.д. и т.п.
        +3
        Никогда не забуду, как в одном образовательном процессе попросили разобраться с некорректной работой nginx под Windows. На виртуалке. На Mac Pro… Автору похвала за проделанную работу.
          0
          Часом, не тесты Ideco?
            0
            если честно, то уже не помню. довольно давно было.
          0
          Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.

          Только это вина не Windows Vista и последующих версий, а вина архитектуры NGINX. Еще с древних времен писалось, что не стоит работать с абсолютными адресами в разделяемой памяти, только смещения и тут никаких проблем и не было бы даже.
            0
            Кто-то где-то говорил обратное? Вопрос на самом деле филосовский, и я подозреваю, что оно даже реализуемо «смещениями», но вероятно с небольшой потерей производительности (просто поверьте) и многимя-многимя правлеными строчками кода (такой коммит-убийца, за который вам отдельное спасибо скажут владельцы кастомных сборок и разрабы foreign-модулей)… Как-то так.
              0
              Такой коммит-убийца — хороший кандидат на включение в версию 2.0, в которой, наконец-то, можно будет что-нибудь сломать, но сделать всё-таки правильно.
                0
                наконец-то, можно будет что-нибудь сломать
                Вам бы все чё-нибудь поломать… :)

                А так-то да. Я вот как-то переписывал хэш-таблицу для работы на shared mem (с указателей на смещения) — сплошной позитив знаете ли в воспоминаниях.
                  0
                  Вообще, если используются smart pointers, то переделка вполне себе может крайне простой — заменой штатного на нештатный.
                  Интересно даже, а в бусте нет готового?
                0
                Есть как бы относительная адресация. Да и сравните скорость обращения к памяти и работу сети, тут разница настолько велика, что на потери при работе с памятью можно закрыть глаза.
                  +6
                  Да? Четыре 40GBit Ethernet'а дадут вам ~15ГБ/сек, а DDR4 даёт только ~30ГБ/сек. Не такая и большая разница, согласитесь? И 100GBit Ethernet уже на подходе…

                  Конечно это скорее не для NGINX'а задачки, а для всяких кластерных RPC, но про то, что «сеть — это что-то такое мееедленое-мееедленное» пора забывать. Задержки в сети — да, они чудовищные, тут природу не обманешь, а вот пропускная способность — совсем другое дело, за этим нужно очень и очень следить.

                    +2
                    30ГБ/c это один канал, соответственно для 4х каналов 120. Пока еще порядок разница.
                      0
                      Это правда, конечно, но вот только просрать разницу «в порядок» накрутив пяток уровней абстракции можно с лёгкостью неимоверной.

                      А так да — запас ещё есть. Иначе бы и со 100GBit Ethernet'ом заморачиваться бы не стоило :-)
                      0
                      Четыре 40GBit Ethernet'а…

                      … на винде? :)
                      Тут даже под linux начнутся муки раскидывания прерываний по ядрам.
                        0
                        На винде — не видел, врать не буду. На Linux — бывает вполне реально в кластерах. Для раздачи статики подобную конфигурацию, понятно, никто использовать не будет.

                          0
                          Очень даже можно, если правильно тюнить систему.
                          Вот неплохой пример отдачи статики на 80 Гбит/с.
                          Лично мне кажется, в windows на таком же железе результат будет меньше.
                          В том числе, из за только одного select в nginx под windows.
                        0
                        Гениально сравнили, а вот если загрузить грузовик самыми большими хардами и отправить проехать 5 метров, скорость будет еще выше. Вообще при чём тут скорость работы памяти и скорость работы контроллера памяти и тем более процессора? Относительной адресацией занимается процессор, а никак не память.
                    +1
                    На *NIX, где в качестве основного способа порождения дочернего процесса используется fork(), копирующий все адресное пространство — абсолютные адреса в разделяемой памяти являются совершенно нормальным явлением.

                    Вам не кажется, что обвинять *nix-сервер в том, что его изначально не подготовили для работы под виндой — несколько странно?
                    0
                    На самом деле это не правда, вернее не совсем правда — nginx с незапамятных времен можно было собрать под Windows без этого ограничения — нужно было просто на этапе сборки определить FD_SETSIZE равным нужному вам количеству соединений.
                    То есть с IOCP он работать не умеет, может только косплеить слоупока работая через select?
                      0
                      По моим последним данным (возможно устарело) — It's incomplete and doesn't work.
                      Если все-таки да, то вероятно это будет следующее за что возьмусь, если (когда) будет много время (улыбаясь сквозь зубы)…
                        +1
                        Без IOCP это не особо и прорыв на мой вкус. Всё же IOCP это как раз high-performance networking который nginx`у как воздух нужен.
                          0
                          Ну как бы в корпоративном секторе, да под win (ntlm и иже с ним), часто длинный keepalive — поэтому по поводу медленного select я не очень страдаю, главное что хоть все воркеры — наконец воркают…
                          Про прорыв же — что вы, я без каких либо претензий — фикс он фикс и есть.
                            0
                            Да я только за вообще. Хоть так.
                            Под IOCP придётся по другому делать. Он же с пулом потоков работает, значит количество воркеров будет количеством активных потоков в пуле. Всё остальное будет система делать.
                              +1
                              С каких пор IOCP работает с потоками пула? Он «работает» в том потоке, который вызвал GetQueuedCompletionStatus. Возможно, вы путаете поведение IOCP с поведением Overlapped IO без использования IOCP?
                                0
                                Думаю crea7or имел ввиду, что IOCP больше для потоков (threads), чем для процессов (process). Что, не совсем «кошерная» технология для nginx, хотя… будем посмотреть.
                                  0
                                  И что же мешает применять эту технологию с процессами, а не с потоками? Ну да, будет не один порт создан, а по числу процессов. Ну так ведь и проблема распределения сокетов по процессам уже решена…
                                    +2
                                    На мой взгляд, достаточно сложно ответить на этот вопрос в целом, но подозреваю, что реальный выигрыш на windows будет только действительно на пуле потоков. Ну или комбинировано — N worker process x M worker threads.
                                    Вероятно IocpPoller все-таки реально сварганить с наследованными сокетами, но боюсь overhead на проброс completion события в другой процесс может скушать часть профита. Интересно конечно насколько, вот поэтому и сложно ответить.
                                      0
                                      Зачем пробрасывать? Можно же в каждом процессе создать свой порт, и связывать «свои» сокеты только с ним.

                                      Проблема будет только с AcceptEx — но соеднинения все-таки устанавливаются не так часто, как через них передаются данные.
                                        0
                                        Зачем пробрасывать?
                                        Так некто и не хочет…
                                        Просто речь-то про пул потоков vs. пул процессов. Весь выигрыш completion port именно в асинхронном распределении по пулу (потоков).
                                        (Например, один из важнейших управляющих параметров для эффективной работы IOCP — NumberOfConcurrentThreads.)

                                        А то что я имел ввиду — как оно там внутри Windows будет «проброшено» до унаследованного сокета.
                                          0
                                          В первую очередь преимущество IOCP — в отсутствии необходимости каждый раз сначала формировать FD_SET из 10240 элементов, потом внутри windows его еще и обходить — а после любого принятого байта начинать все заного.

                                          Если сокеты уже распределились по пулу процессов — зачем их потом еще и по пулу потоков раскидывать? Понятно что общий пул потоков даст чуть более равномерную нагрузку на ядра, чем пул процессов с отдельными сокетами (но потребует чуть больше накладных расходов на синхронизацию) — но этот вопрос не имеет никакого отношения к IOCP. Это применимо и для select, и для epoll.

                                          PS а NumberOfConcurrentThreads в nginx, очевидно, будет равен 1
                                          0
                                          Всё равно переделывать много, так может сразу как надо под платформу соорудить? Работу с диском тоже на IOCP завести и вообще будет зашибись.
                                    0
                                    Ну да, потоки в пуле будут обрабатывать завершение вв, но они же вместе работают с IOCP.
                                      0
                                      Завершение ввода-вывода в случае использования IOCP обрабатывает программист, там где хочет.
                                        0
                                        Само собой, оно не само в пуле работает. Но по дизайну должно работать с пулом.
                                          0
                                          Кому должно?
                          0
                          А как сделана поддержка SO_REUSEPORT?
                            +1
                            А у винды такого нету… только REUSEADDR :(
                              0
                              Так через IOCP всё надо делать и не нужны никакие REUSE.
                                0
                                Спасибо, почитал. Но, проблема в том, что IOCP рассчитано только на треды. SO_REUSEPORT позволяет работать в виде нескольких процессов. Я понимаю, что «а нефиг писать однопоточные приложения», но в существующем приложении с однопоточной обработкой прикрутить SO_REUSEPORT и запуск нескольких копий проще, чем переделывать всё приложение на треды.
                                  0
                                  Переделывать конечно сложнее. Так IOCP не на это рассчитан, а чтобы сразу писали с его поддержкой. Это плохой вариант для портирования, но уж что есть. Опять же быстрее потоками, чем процессами (хоть и не так безопасно в свете текущей моды на процессы). Я сам не замерял, но вот тут с epoll сравнивают — всё же в ядре.
                                    0
                                    Хотя конкретно с nginx может быстрее особо и не будет (потоки <> процессы). Там если через шаред память перекидывается, то не сильно и медленнее будет одного адресного пространства. Разве что меньше переключений контекста.
                                0
                                А ради интересу, до модификаций 1*5 и после 1*5 отличаются или нет?
                                  0
                                  Вообще не заметно, т.е. все в рамках погрешности — раз чуть быстрее, раз чуть медленнее.
                                  Иначе, я бы сразу это отключаемо сделал (или в случае 1 worker — по старому, без наследования)
                                    +1
                                    Хотя может для совместимости все-таки будет лучше так и сделать (в случае только 1 worker).
                                      0
                                      Нет, не стоит так делать, ибо это сломает возможность «на лету» смены числа воркеров.
                                        0
                                        Вовсе нет, при смене на лету — процессы перезагружаются, т.е. весь алгоритм, описанный в статье, повторяется сызнова…
                                        +1
                                        Прикрутил таки (проапдейтил на github и сбросил коммит changeset-ом в nginx-dev).
                                        Теперь в случае «1 worker» все работает как раньше.
                                    0
                                    А как же сборка от nginx-win.ecsds.eu в которой и Fully ASLR and DEP compliant for shared memory и Select-boost и Multiple workers supported и FD_SETSIZE = 32768 и многое другое…

                                    Вот полный список возможностей этой сборки:

                                    • All current nginx features (see with nginx.exe -V) (subject to Windows compatibility)
                                    • Consistent with original nginx code (subject to Windows compatibility)
                                    • FD_SETSIZE = 32768 (modded kernel), allows one worker to handle c250k+ (with optimization registry file)
                                    • Multiple workers supported! use no more than 2 workers for 1 core (cpu)
                                    • SPDY 3.1
                                    • LuaJIT compiled in (lua-nginx-module)
                                    • Naxsi WAF — Web Application Firewall
                                    • Array-var-nginx-module
                                    • HttpSubsModule
                                    • echo-nginx-module
                                    • ngx_http_lower_upper_case
                                    • headers-more-nginx-module
                                    • set-misc-nginx-module
                                    • ngx_http_auth_ldap (experimental)
                                    • Additional custom 503 error handler via 513
                                    • lua-upstream-nginx-module (Manipulate upstream dynamically)
                                    • Select-boost
                                    • Fully ASLR and DEP compliant for shared memory
                                    • encrypted-session-nginx-module
                                    • Nginx-limit-traffic-rate-module
                                    • RDNS (reverse DNS lookup for incoming connection)
                                    • AJP — tomcat backend support
                                    • form-input-nginx-module
                                    • ngxLuaDB, the drizzle and dynamic loaded module solution
                                    • ngx_upstream_jdomain
                                    • cache_purge
                                    • nginx-http-concat
                                    • nginx-module-vts (Virtual host traffic status)


                                    Или несколько человек делают дурную работу делая одно и тоже… или я чего-то недогоняю? Может разработчикам Nginx подсмотреть что и как сделано в этой сборке?
                                      +2
                                      а вы спросите их за исходники…
                                        0
                                        Хм, исходников действительно нет, просто бесплатная сборка + платная поддержка кому нужно. В любом случае на месте разработчиков я бы связался с командой www.ecsystems.nl и выкупил все их коды и включил в основную ветку. Какой смысл изобретать велосипед и тратить человекоресурсы, если проще заплатить деньги за готовое. В любом случае огромное спасибо вам и за труды и за статью.
                                          +2
                                          это опенсорс детка © а по делу — то что для вас «тратить человекоресурсы», для меня хобби — я это делаю с удовольствием.
                                          А упомянутые вами люди для меня сродни ну например фирмы Apple — я лично просто не собираюсь иметь с ними дела. За nginx не скажу, это повторяю от меня лично.
                                            0
                                            Еще раз спасибо за такое прекрасное хобби! Наконец-то в оригинальном Nginx за столько лет при полном безразличии разработчиков к Windows платформе можно увидеть реальные перемены в лучшую строну. Причём значительные перемены. Надеюсь ваш пул-реквест насчет воркеров очень скоро станет частью Nginx. Успехов!
                                              0
                                              Всегда пожалуйста…
                                              при полном безразличии разработчиков к Windows платформе
                                              Ну как бы: раз — это совсем не правда, два — а они и необязаны.

                                              А упомянутые вами редиски люди… По мне как, весь смысл в nginx — только когда он опенсорсный, чтобы значит можно было тупо глянуть в исходники (если что-то где-то непонятно), или чтобы что-то где-то подкрутить, или пересобрать с другим модулем или вообще куском «ядра» и т.д. Да много чего можно.
                                                0
                                                Ну как бы: раз — это совсем не правда

                                                Ну тогда я не знаю как по другому объяснить многолетнее отсутствие подвижек в сторону Windows.

                                                два — а они и необязаны.

                                                А кто говорил что обязаны? Я лишь сказал что они безразличны к Windows платформе. Пусть вы и утверждаете обратное (поскольку более тесно с ними общаетесь), но слова это одно, а дело другое. На деле всё это висело мёртвым грузом много лет. Впрочем когда появилась сборка от nginx-win.ecsds.eu жить стало проще, жизнь стала веселей :-)

                                                он опенсорсный, чтобы значит можно было тупо глянуть в исходники (если что-то где-то непонятно)

                                                «Тупо глянуть в исходники» не получится, Nginx крайне тяжелый для понимания и редкий программист сможет разобраться в его коде и уж тем более сам что-то дописать. Это уже не раз обсуждалось и об этом все знают. Поэтому меня всегда умиляют ссылки на open source, мол если нужна поддержка Windows — возьмите и допишите.

                                                Лично вам огромное спасибо, это бесспорно, вы это заслужили, а касательно разработчиков Nginx моё мнение никогда не поменяется — им следовало бы больше уделять внимания Windows платформе, точнее хотя бы просто — уделять. И никто не считает их «редисками», они тоже молодцы что создали и поддерживают такой замечательный софт и им тоже за это огромное спасибо, просто я выразил своё личное мнение касательно их отношения к поддержке Windows. Топик ведь о Nginx и Windows, не так ли.
                                                  +2
                                                  И никто не считает их «редисками»
                                                  Я не люблю людей (по этой же причине например и фирмы как Apple), которые делают профит на базе чего-нибудь из opensource, при этом сами его не развивают или делают это в незначительной степени (тупо спрятав «исходники»). Ну как бы у меня на этой теме «когнитивный диссонанс» что-ли… и это дело принципа.

                                                  А вот вы лично, почему-то предъявили «претензии» разрабам nginx, да и мне или другим из коммюнити в том числе («не развивают nginx4win», «несколько человек делают дурную работу делая одно и тоже», «связался бы с командой» и т.д.), а почему-то не «команде» из ecsds.

                                                  Nginx крайне тяжелый для понимания и редкий программист сможет долететь до середины Днепра ...
                                                  Неправда ваша, я знаю очень много людей (не из команды nginx) легко могущих прочитать его исходники.
                                                  А даже если и не все могут — это ничего не меняет. Сам принцип важен… имхо.
                                                    –3
                                                    тупо спрятав «исходники»

                                                    Не хочу ничего утверждать, но я не уверен что они их прячут. Может с ними никто и никогда не связывался по этому поводу? Или они сами должны на блюде подать? Если даже и прячут, то всё это можно решить путем переговоров по передаче кода, ну или деловых переговоров о продаже если к этому пойдет.

                                                    А вот вы лично, почему-то предъявили «претензии» разрабам nginx, да и мне или другим из коммюнити в том числе («не развивают nginx4win», «несколько человек делают дурную работу делая одно и тоже», «связался бы с командой» и т.д.), а почему-то не «команде» из ecsds.

                                                    Простите великодушно, но где вы увидели претензии? Мне процитировать еще раз дословно чтоль свои же слова? Я лишь сказал о том, что на ИХ месте я бы постарался связаться с командой из ecsystems.nl и выкупить или просто получить эти исходники. Вдруг ребята из ecsystems.nl готовы отдать их просто так лишь бы они НЕ легли мёртвым грузом на много лет, а были реально включены в Nginx?

                                                    Если уж вы заговорили про команду ecsystems.nl, то хочу вам сказать что в группе рассылки Nginx сидит человек из этой команды и пытается общаться и на английском и на ломаном русском, видимо через Google Translate. Понятия не имею как всё обстоит на самом деле, но вы не предполагали, а может не от хорошей жизни ребята из ecsystems.nl начали сами допиливать Nginx?
                                                    Может именно потому что разработчики Nginx никак не развивали свой продукт в этом направлении эти ребята и приложили свои усилия к тому чтобы допилить Nginx до нормального рабочего состояния под Windows.

                                                    Ваши обвинения в адрес тех, которые делают профит на базе чего-нибудь из opensource, мне кажутся неуместными. Им наоборот нужно в ноги покланяться, что они допилили Ngixn и более того, всё это распространяется бесплатно, а профит, как вы говорите, они делают на поддержке. Простите, но техподдержкой в нашем мире никто бесплатно заниматься не будет, всем нужно на что-то жить и что-то кушать.
                                                      +3
                                                      У вас на это своя точка зрения, у меня своя. Думайте как хотите, я вас переубеждать не собираюсь.
                                                      Не хочу ничего утверждать, но я не уверен что они их прячут
                                                      Зачем тогда нужно предлагать «сборку на заказ» (что они и делают)?

                                                      А во вторых, я специально не уточнял, на чем они делают профит. Поддержка — это хорошо, и деньги за это брать тоже не грех (хотя я лично занимаюсь этим в куче опенсорсных проектов совершенно бесплатно). Но это дело личное, конечно.

                                                      Я про-то, что «зарабатывая деньги» на опенсорсном продукте (не важно как) они его развивали только для себя, ну или для своих клиентов, если хотите. Мне очень не нравится сам этот факт. Я же это делаю для пользы всех, и своей в том числе…

                                                      Я вам пример приведу: есть опенсорсная финтифлюшка X (всем миром разрабатывающаяся), фирма F изменив в X чуть-чуть (пару процентов) сделала продукт X2, при этом даже периодически перенимая все изменения и новшества из X (каждый релиз).
                                                      Зарабатывая на X2 (а в моей реальности в большей степени на X), они никоим образом не поспособствовали развитию самого X (ну или в несоизмеримо малой степени). Имеют они на то право — возможно. Должен ли я их за это «уважать» — имхо, нет. Ну вот нет и все тут.

                                                      Хотя философствовать на эту тему я однозначно не собираюсь. По крайней мере, простите, с вами, и уж точно не в рамках этого поста.
                                                        0
                                                        Да поймите же вы, они ничего не зарабатывают конкретно на opensource, они зарабатывают на поддержке. Не важно какой и не важно чего, просто на поддержке своих клиентов, обработке их тикетов, настройке их серверов и проч. Сделанные ими изменения в коде никакого профита им не приносят и бинарники распространяются бесплатно. С таким успехом можно обвинить любого хостера который использует бесплатный Mysql для своих клиентов (не важно с доработками или без) в зарабатывании денег. Ну бред же.

                                                        По факту ECSystems продает услуги по поддержке Windows серверов и сборке Nginx с нужными модулями и часть этих денег жертвует команде, которая и осуществляет доработку Nginx под Windows.

                                                        OK не будем спорить :-) Я понял что вы их не уважаете, потому что свой вклад в opensource они пока не внесли.

                                                        Но ведь это только пока? По поводу исходников у них в FAQ написано что пока не выкладывают, т.к. проект не готов. Да и какой смысл их прятать, если бинарники и так бесплатные? Т.е. как только будет доделано то что указано в TODO ниже, можно ожидать появления исходников. Будем надеяться…

                                                        Todo:

                                                        — ldap / ntlm
                                                        — allow multiple instances to run on the same machine
                                                        — More non-blocking Lua, event based DLL add-on’s like pagespeed, SharePoint, asp/dotnet.
                                                        — Full 64 bit builds.
                                                        — IO event and thread separation (60% completed).
                                                        — Distributed IO and CPU event processing (we have a working proto type).
                                                          0
                                                          Да и какой смысл их прятать, если бинарники и так бесплатные?
                                                          Это вам оно бессмысленно, мне и другим — вовсе нет.

                                                          Хотя, вы же сами выше писали, что дескать «делают двойную работу».
                                                      0
                                                      Я не люблю людей (по этой же причине например и фирмы как Apple), которые делают профит на базе чего-нибудь из opensource, при этом сами его не развивают или делают это в незначительной степени (тупо спрятав «исходники»).

                                                      Ну раз уж зашел разговор про конкретные лица.
                                                      Насколько мне известно вот тут нелюбимая вами фруктовая компания выкладывает все наработки как «взятые из мира опенсорс», так и открытое ими самими.
                                                      И раз уж вы обвиняете — подскажите, пожалуйста, что именно вам известно, какой продукт эта самая фирма «не развивает» или от чего «прячет исходники»?
                                                      Очень любопытно. Спасибо.
                                                        0
                                                        Можно подискутировать насчет наработок BSD.
                                                        До сих пор, если на Mac зайти в консоль, ощущение, что сидишь за FreeBSD — те же команды, вплоть до команды sockstat.
                                                        Хотя всегда можно сказать что-то типа «У BSD такая лицензия, когда можно взять и не открывать».
                                                          0
                                                          Вот тут лежит окружение взятое из BSD. Плюс свои драйвера и другие наработки типа вебкита.
                                                          Вы не можете скачать?
                                                          Я не понимаю в чём претензия.
                                                          0
                                                          Незачто, потому как я вам ничего не собираюсь доказывать… Кто ищет, тот всегда найдёт.
                                                          А что выкладывается — ну так когда от лицензии никуда не деться, приходится. Только это имхо, такая капля в море, при тех то доходах и возможностях.
                                                          Это дело почти личное — я же пропагандой ни за ни против не занимаюсь…
                                                          Ну вот скажите мне, почему каждая статья, какой бы технической не была, сваливается в глубокий холивар о «птичках»?
                                          0
                                          Интересно, а как в cygwin разобрались с ASLR? У них же вызов fork() работает!
                                            +3
                                            Он там так «работает», что лучше даже не упоминать.
                                            0
                                            Автор, скажите пожалуйста — не появилась ли возможность использовать nginx на Windows в паре с ffmpeg без ручного запуска для перекодирования стримов под Windows в другое качество как это возможно под Linux?
                                              0
                                              rtmp? Простите, не было нужды под виндой, так что без понятия. Однако не думаю, что оно сильно сложно проверить… например rtmp-модуль вроде под windows собирается. А как там ffmpeg прикручивается, чтобы на лету, я правда не пользовал…
                                              –1
                                              Космические корабли уже много лет бороздят просторы и всё такое, но к сожалению немалая часть человечества продолжает мучаться с виндой и прочим майкрософтовским говнософтом. Когда же уже это закончится наконец?

                                              Я не в том смысле, что автор не молодец. Автор молодец, конечно, но как подумаешь сколько времени и сил можно было бы сэкономить если бы не «в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа».
                                                0
                                                А у нас кроме проприетарной винды разве нет других систем с той же архитектурой?
                                                  0
                                                  C ReactOS мучаться придется еще больше.
                                                    0
                                                    Кстати вот не пробовал… а интересно, правда. Время, будь оно неладно.
                                                    Если кто вдруг опередит, отпишитесь, плз…
                                                      0
                                                      Я пытался использовать ReactOS, когда мне приходилось работать с каким-то уродским vpn-клиентом, и я искал способ вынести vpn-клиент на отдельный сетевой хост (доп. условия задачи: клиент работает только под виндой и у меня нет никакого дистрибутива винды, пусть даже с пробным периодом). Так вот, под Hyper-V у ReactOS попросту не нашлось драйверов для сетевой карты. С такими глупыми проблемами ReactOS еще долго не сможет считаться вариантом решения.

                                                      С другой стороны, скорость установки ReactOS и загрузки была такова, что я успел проверить обе возможные конфигурации железа и убедиться в несовместимости ReactOS с Hyper-V пока запускалась отладка нашего проекта. Так что какое-то будущее у ReactOS есть, после решения подобных глупых проблем.
                                                        0
                                                        Имел ввиду nginx 4 win on reactos…
                                                        Например, работает ли то же наследование listener, shmem и т.д.
                                                          0
                                                          Когда не работает сеть — уже не важно, работает ли наследование listener, shmem и т. д. :)
                                                            0
                                                            Виндовый родной драйвер подсунуть не пробовали? Возможно проблема с лицензиями, а самим писать еще руки не дошли.
                                                    0
                                                    Вроде есть, но зачем оно нам? Почему не использовать простой и понятный Unix, который в стопятьсот раз проще и не контролируется одной компанией с весьма сомнительными намерениями. Я понимаю люди делали всякие L4 и Plan9, двигали прогресс, но в случае с Windows, мне кажется что всему прогрессивному человечеству станет гораздо лучше когда мы пройдём этот печальный этап. Я не специалист по архитектуре Windows, и возможно где-то глубоко внутри неё и есть что-то разумное, доброе и вечное, но с точки зрения пользователя, администратора и разработчика я вижу сплошные проблемы и неудобства.
                                                  0
                                                  Будет работать в Nano Server?
                                                    0
                                                    Думаю — да, а в чем сомнения?
                                                    –1
                                                    Замечание:
                                                    On many file systems, a short file name contains a tilde (~) character. However, not all file systems follow this convention. Therefore, do not assume that you can skip calling GetLongPathName if the path does not contain a tilde (~) character.
                                                    msdn.microsoft.com/en-us/library/windows/desktop/aa364980(v=vs.85).aspx

                                                    И если посмотреть ещё раз на исходники:
                                                    github.com/sebres/nginx/commit/12fb136744bb4de3ec4568d6a458495cd97f1043#diff-04009b15c59ed35d0ef2738a46174307R746

                                                    То текущий вариант будет всегда работать, а новый можно взломать (теоретически).

                                                  Only users with full accounts can post comments. Log in, please.