Почему Windows. Все просто, в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа. И от этих требований к платформе, например в ультимативной форме озвученных клиентом, никуда не денешься.
И раз уж имеем Windows, но
Хотя нужно заметить, что даже с этими ограничениями, 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…
Соответственно без того чтобы переписать весь функционал, работающий с pointer внутри shared mem в nginx — есть единственный вариант,
Начало дискуссии про это можно почитать здесь. Максим, кстати починил упущенную мной проблему (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 соединений и т.д. и т.п.).Ну и как без
Тест сделан на 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.
Комментарии (77)
TijAY
11.06.2015 22:07+3Никогда не забуду, как в одном образовательном процессе попросили разобраться с некорректной работой nginx под Windows. На виртуалке. На Mac Pro… Автору похвала за проделанную работу.
AxisPod
11.06.2015 22:19Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.
Только это вина не Windows Vista и последующих версий, а вина архитектуры NGINX. Еще с древних времен писалось, что не стоит работать с абсолютными адресами в разделяемой памяти, только смещения и тут никаких проблем и не было бы даже.
sebres Автор
11.06.2015 22:30Кто-то где-то говорил обратное? Вопрос на самом деле филосовский, и я подозреваю, что оно даже реализуемо «смещениями», но вероятно с небольшой потерей производительности (просто поверьте) и многимя-многимя правлеными строчками кода (такой коммит-убийца, за который вам отдельное спасибо скажут владельцы кастомных сборок и разрабы foreign-модулей)… Как-то так.
Envek
11.06.2015 22:37Такой коммит-убийца — хороший кандидат на включение в версию 2.0, в которой, наконец-то, можно будет что-нибудь сломать, но сделать всё-таки правильно.
sebres Автор
11.06.2015 22:48наконец-то, можно будет что-нибудь сломать
Вам бы все чё-нибудь поломать… :)
А так-то да. Я вот как-то переписывал хэш-таблицу для работы на shared mem (с указателей на смещения) — сплошной позитив знаете ли в воспоминаниях.
datacompboy
12.06.2015 10:46Вообще, если используются smart pointers, то переделка вполне себе может крайне простой — заменой штатного на нештатный.
Интересно даже, а в бусте нет готового?
AxisPod
11.06.2015 22:45Есть как бы относительная адресация. Да и сравните скорость обращения к памяти и работу сети, тут разница настолько велика, что на потери при работе с памятью можно закрыть глаза.
khim
12.06.2015 08:55+6Да? Четыре 40GBit Ethernet'а дадут вам ~15ГБ/сек, а DDR4 даёт только ~30ГБ/сек. Не такая и большая разница, согласитесь? И 100GBit Ethernet уже на подходе…
Конечно это скорее не для NGINX'а задачки, а для всяких кластерных RPC, но про то, что «сеть — это что-то такое мееедленое-мееедленное» пора забывать. Задержки в сети — да, они чудовищные, тут природу не обманешь, а вот пропускная способность — совсем другое дело, за этим нужно очень и очень следить.
splav_asv
12.06.2015 11:25+230ГБ/c это один канал, соответственно для 4х каналов 120. Пока еще порядок разница.
khim
12.06.2015 12:27Это правда, конечно, но вот только просрать разницу «в порядок» накрутив пяток уровней абстракции можно с лёгкостью неимоверной.
А так да — запас ещё есть. Иначе бы и со 100GBit Ethernet'ом заморачиваться бы не стоило :-)
lexore
12.06.2015 18:18Четыре 40GBit Ethernet'а…
… на винде? :)
Тут даже под linux начнутся муки раскидывания прерываний по ядрам.khim
12.06.2015 20:10На винде — не видел, врать не буду. На Linux — бывает вполне реально в кластерах. Для раздачи статики подобную конфигурацию, понятно, никто использовать не будет.
AxisPod
12.06.2015 23:02Гениально сравнили, а вот если загрузить грузовик самыми большими хардами и отправить проехать 5 метров, скорость будет еще выше. Вообще при чём тут скорость работы памяти и скорость работы контроллера памяти и тем более процессора? Относительной адресацией занимается процессор, а никак не память.
mayorovp
12.06.2015 09:06+1На *NIX, где в качестве основного способа порождения дочернего процесса используется fork(), копирующий все адресное пространство — абсолютные адреса в разделяемой памяти являются совершенно нормальным явлением.
Вам не кажется, что обвинять *nix-сервер в том, что его изначально не подготовили для работы под виндой — несколько странно?
kekekeks
11.06.2015 22:49На самом деле это не правда, вернее не совсем правда — nginx с незапамятных времен можно было собрать под Windows без этого ограничения — нужно было просто на этапе сборки определить FD_SETSIZE равным нужному вам количеству соединений.
То есть с IOCP он работать не умеет, может только косплеить слоупока работая через select?sebres Автор
11.06.2015 22:54По моим последним данным (возможно устарело) — It's incomplete and doesn't work.
Если все-таки да, то вероятно это будет следующее за что возьмусь, если (когда) будет много время (улыбаясь сквозь зубы)…
crea7or
11.06.2015 23:17+1Без IOCP это не особо и прорыв на мой вкус. Всё же IOCP это как раз high-performance networking который nginx`у как воздух нужен.
sebres Автор
12.06.2015 00:21Ну как бы в корпоративном секторе, да под win (ntlm и иже с ним), часто длинный keepalive — поэтому по поводу медленного select я не очень страдаю, главное что хоть все воркеры — наконец воркают…
Про прорыв же — что вы, я без каких либо претензий — фикс он фикс и есть.crea7or
12.06.2015 01:52Да я только за вообще. Хоть так.
Под IOCP придётся по другому делать. Он же с пулом потоков работает, значит количество воркеров будет количеством активных потоков в пуле. Всё остальное будет система делать.mayorovp
12.06.2015 09:10+1С каких пор IOCP работает с потоками пула? Он «работает» в том потоке, который вызвал GetQueuedCompletionStatus. Возможно, вы путаете поведение IOCP с поведением Overlapped IO без использования IOCP?
sebres Автор
12.06.2015 09:51Думаю crea7or имел ввиду, что IOCP больше для потоков (threads), чем для процессов (process). Что, не совсем «кошерная» технология для nginx, хотя… будем посмотреть.
mayorovp
12.06.2015 09:52И что же мешает применять эту технологию с процессами, а не с потоками? Ну да, будет не один порт создан, а по числу процессов. Ну так ведь и проблема распределения сокетов по процессам уже решена…
sebres Автор
12.06.2015 10:06+2На мой взгляд, достаточно сложно ответить на этот вопрос в целом, но подозреваю, что реальный выигрыш на windows будет только действительно на пуле потоков. Ну или комбинировано — N worker process x M worker threads.
Вероятно IocpPoller все-таки реально сварганить с наследованными сокетами, но боюсь overhead на проброс completion события в другой процесс может скушать часть профита. Интересно конечно насколько, вот поэтому и сложно ответить.mayorovp
12.06.2015 10:33Зачем пробрасывать? Можно же в каждом процессе создать свой порт, и связывать «свои» сокеты только с ним.
Проблема будет только с AcceptEx — но соеднинения все-таки устанавливаются не так часто, как через них передаются данные.sebres Автор
12.06.2015 10:45Зачем пробрасывать?
Так некто и не хочет…
Просто речь-то про пул потоков vs. пул процессов. Весь выигрыш completion port именно в асинхронном распределении по пулу (потоков).
(Например, один из важнейших управляющих параметров для эффективной работы IOCP — NumberOfConcurrentThreads.)
А то что я имел ввиду — как оно там внутри Windows будет «проброшено» до унаследованного сокета.mayorovp
12.06.2015 10:56В первую очередь преимущество IOCP — в отсутствии необходимости каждый раз сначала формировать FD_SET из 10240 элементов, потом внутри windows его еще и обходить — а после любого принятого байта начинать все заного.
Если сокеты уже распределились по пулу процессов — зачем их потом еще и по пулу потоков раскидывать? Понятно что общий пул потоков даст чуть более равномерную нагрузку на ядра, чем пул процессов с отдельными сокетами (но потребует чуть больше накладных расходов на синхронизацию) — но этот вопрос не имеет никакого отношения к IOCP. Это применимо и для select, и для epoll.
PS а NumberOfConcurrentThreads в nginx, очевидно, будет равен 1
crea7or
12.06.2015 13:22Всё равно переделывать много, так может сразу как надо под платформу соорудить? Работу с диском тоже на IOCP завести и вообще будет зашибись.
crea7or
12.06.2015 13:15Ну да, потоки в пуле будут обрабатывать завершение вв, но они же вместе работают с IOCP.
amarao
12.06.2015 00:03А как сделана поддержка SO_REUSEPORT?
crea7or
12.06.2015 01:54Так через IOCP всё надо делать и не нужны никакие REUSE.
amarao
12.06.2015 02:36Спасибо, почитал. Но, проблема в том, что IOCP рассчитано только на треды. SO_REUSEPORT позволяет работать в виде нескольких процессов. Я понимаю, что «а нефиг писать однопоточные приложения», но в существующем приложении с однопоточной обработкой прикрутить SO_REUSEPORT и запуск нескольких копий проще, чем переделывать всё приложение на треды.
crea7or
12.06.2015 03:17Переделывать конечно сложнее. Так IOCP не на это рассчитан, а чтобы сразу писали с его поддержкой. Это плохой вариант для портирования, но уж что есть. Опять же быстрее потоками, чем процессами (хоть и не так безопасно в свете текущей моды на процессы). Я сам не замерял, но вот тут с epoll сравнивают — всё же в ядре.
crea7or
12.06.2015 03:40Хотя конкретно с nginx может быстрее особо и не будет (потоки <> процессы). Там если через шаред память перекидывается, то не сильно и медленнее будет одного адресного пространства. Разве что меньше переключений контекста.
datacompboy
12.06.2015 10:44А ради интересу, до модификаций 1*5 и после 1*5 отличаются или нет?
sebres Автор
12.06.2015 10:49Вообще не заметно, т.е. все в рамках погрешности — раз чуть быстрее, раз чуть медленнее.
Иначе, я бы сразу это отключаемо сделал (или в случае 1 worker — по старому, без наследования)sebres Автор
12.06.2015 10:53+1Хотя может для совместимости все-таки будет лучше так и сделать (в случае только 1 worker).
datacompboy
12.06.2015 11:12Нет, не стоит так делать, ибо это сломает возможность «на лету» смены числа воркеров.
sebres Автор
12.06.2015 11:18Вовсе нет, при смене на лету — процессы перезагружаются, т.е. весь алгоритм, описанный в статье, повторяется сызнова…
sebres Автор
12.06.2015 13:58+1Прикрутил таки (проапдейтил на github и сбросил коммит changeset-ом в nginx-dev).
Теперь в случае «1 worker» все работает как раньше.
ArhMax
12.06.2015 13:20А как же сборка от 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 подсмотреть что и как сделано в этой сборке?sebres Автор
12.06.2015 13:25+2а вы спросите их за исходники…
ArhMax
12.06.2015 13:31Хм, исходников действительно нет, просто бесплатная сборка + платная поддержка кому нужно. В любом случае на месте разработчиков я бы связался с командой www.ecsystems.nl и выкупил все их коды и включил в основную ветку. Какой смысл изобретать велосипед и тратить человекоресурсы, если проще заплатить деньги за готовое. В любом случае огромное спасибо вам и за труды и за статью.
sebres Автор
12.06.2015 13:51+2это опенсорс детка ©а по делу — то что для вас «тратить человекоресурсы», для меня хобби — я это делаю с удовольствием.
А упомянутые вами люди для меня сродни ну например фирмы Apple — я лично просто не собираюсь иметь с ними дела. За nginx не скажу, это повторяю от меня лично.ArhMax
12.06.2015 14:00Еще раз спасибо за такое прекрасное хобби! Наконец-то в оригинальном Nginx за столько лет при полном безразличии разработчиков к Windows платформе можно увидеть реальные перемены в лучшую строну. Причём значительные перемены. Надеюсь ваш пул-реквест насчет воркеров очень скоро станет частью Nginx. Успехов!
sebres Автор
12.06.2015 14:10Всегда пожалуйста…
при полном безразличии разработчиков к Windows платформе
Ну как бы: раз — это совсем не правда, два — а они и необязаны.
А упомянутые вамиредискилюди… По мне как, весь смысл в nginx — только когда он опенсорсный, чтобы значит можно было тупо глянуть в исходники (если что-то где-то непонятно), или чтобы что-то где-то подкрутить, или пересобрать с другим модулем или вообще куском «ядра» и т.д. Да много чего можно.ArhMax
12.06.2015 14:31Ну как бы: раз — это совсем не правда
Ну тогда я не знаю как по другому объяснить многолетнее отсутствие подвижек в сторону Windows.
два — а они и необязаны.
А кто говорил что обязаны? Я лишь сказал что они безразличны к Windows платформе. Пусть вы и утверждаете обратное (поскольку более тесно с ними общаетесь), но слова это одно, а дело другое. На деле всё это висело мёртвым грузом много лет. Впрочем когда появилась сборка от nginx-win.ecsds.eu жить стало проще, жизнь стала веселей :-)
он опенсорсный, чтобы значит можно было тупо глянуть в исходники (если что-то где-то непонятно)
«Тупо глянуть в исходники» не получится, Nginx крайне тяжелый для понимания и редкий программист сможет разобраться в его коде и уж тем более сам что-то дописать. Это уже не раз обсуждалось и об этом все знают. Поэтому меня всегда умиляют ссылки на open source, мол если нужна поддержка Windows — возьмите и допишите.
Лично вам огромное спасибо, это бесспорно, вы это заслужили, а касательно разработчиков Nginx моё мнение никогда не поменяется — им следовало бы больше уделять внимания Windows платформе, точнее хотя бы просто — уделять. И никто не считает их «редисками», они тоже молодцы что создали и поддерживают такой замечательный софт и им тоже за это огромное спасибо, просто я выразил своё личное мнение касательно их отношения к поддержке Windows. Топик ведь о Nginx и Windows, не так ли.sebres Автор
12.06.2015 15:02+2И никто не считает их «редисками»
Я не люблю людей (по этой же причине например и фирмы как Apple), которые делают профит на базе чего-нибудь из opensource, при этом сами его не развивают или делают это в незначительной степени (тупо спрятав «исходники»). Ну как бы у меня на этой теме «когнитивный диссонанс» что-ли… и это дело принципа.
А вот вы лично, почему-то предъявили «претензии» разрабам nginx, да и мне или другим из коммюнити в том числе («не развивают nginx4win», «несколько человек делают дурную работу делая одно и тоже», «связался бы с командой» и т.д.), а почему-то не «команде» из ecsds.
Nginx крайне тяжелый для понимания и редкий программист сможет долететь до середины Днепра ...
Неправда ваша, я знаю очень много людей (не из команды nginx) легко могущих прочитать его исходники.
А даже если и не все могут — это ничего не меняет. Сам принцип важен… имхо.ArhMax
12.06.2015 15:22-3тупо спрятав «исходники»
Не хочу ничего утверждать, но я не уверен что они их прячут. Может с ними никто и никогда не связывался по этому поводу? Или они сами должны на блюде подать? Если даже и прячут, то всё это можно решить путем переговоров по передаче кода, ну или деловых переговоров о продаже если к этому пойдет.
А вот вы лично, почему-то предъявили «претензии» разрабам nginx, да и мне или другим из коммюнити в том числе («не развивают nginx4win», «несколько человек делают дурную работу делая одно и тоже», «связался бы с командой» и т.д.), а почему-то не «команде» из ecsds.
Простите великодушно, но где вы увидели претензии? Мне процитировать еще раз дословно чтоль свои же слова? Я лишь сказал о том, что на ИХ месте я бы постарался связаться с командой из ecsystems.nl и выкупить или просто получить эти исходники. Вдруг ребята из ecsystems.nl готовы отдать их просто так лишь бы они НЕ легли мёртвым грузом на много лет, а были реально включены в Nginx?
Если уж вы заговорили про команду ecsystems.nl, то хочу вам сказать что в группе рассылки Nginx сидит человек из этой команды и пытается общаться и на английском и на ломаном русском, видимо через Google Translate. Понятия не имею как всё обстоит на самом деле, но вы не предполагали, а может не от хорошей жизни ребята из ecsystems.nl начали сами допиливать Nginx?
Может именно потому что разработчики Nginx никак не развивали свой продукт в этом направлении эти ребята и приложили свои усилия к тому чтобы допилить Nginx до нормального рабочего состояния под Windows.
Ваши обвинения в адрес тех, которые делают профит на базе чего-нибудь из opensource, мне кажутся неуместными. Им наоборот нужно в ноги покланяться, что они допилили Ngixn и более того, всё это распространяется бесплатно, а профит, как вы говорите, они делают на поддержке. Простите, но техподдержкой в нашем мире никто бесплатно заниматься не будет, всем нужно на что-то жить и что-то кушать.sebres Автор
12.06.2015 15:54+3У вас на это своя точка зрения, у меня своя. Думайте как хотите, я вас переубеждать не собираюсь.
Не хочу ничего утверждать, но я не уверен что они их прячут
Зачем тогда нужно предлагать «сборку на заказ» (что они и делают)?
А во вторых, я специально не уточнял, на чем они делают профит. Поддержка — это хорошо, и деньги за это брать тоже не грех (хотя я лично занимаюсь этим в куче опенсорсных проектов совершенно бесплатно). Но это дело личное, конечно.
Я про-то, что «зарабатывая деньги» на опенсорсном продукте (не важно как) они его развивали только для себя, ну или для своих клиентов, если хотите. Мне очень не нравится сам этот факт. Я же это делаю для пользы всех, и своей в том числе…
Я вам пример приведу: есть опенсорсная финтифлюшка X (всем миром разрабатывающаяся), фирма F изменив в X чуть-чуть (пару процентов) сделала продукт X2, при этом даже периодически перенимая все изменения и новшества из X (каждый релиз).
Зарабатывая на X2 (а в моей реальности в большей степени на X), они никоим образом не поспособствовали развитию самого X (ну или в несоизмеримо малой степени). Имеют они на то право — возможно. Должен ли я их за это «уважать» — имхо, нет. Ну вот нет и все тут.
Хотя философствовать на эту тему я однозначно не собираюсь. По крайней мере, простите, с вами, и уж точно не в рамках этого поста.ArhMax
12.06.2015 16:25Да поймите же вы, они ничего не зарабатывают конкретно на 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).sebres Автор
12.06.2015 16:34Да и какой смысл их прятать, если бинарники и так бесплатные?
Это вам оно бессмысленно, мне и другим — вовсе нет.
Хотя, вы же сами выше писали, что дескать «делают двойную работу».
Adnako
12.06.2015 19:04Я не люблю людей (по этой же причине например и фирмы как Apple), которые делают профит на базе чего-нибудь из opensource, при этом сами его не развивают или делают это в незначительной степени (тупо спрятав «исходники»).
Ну раз уж зашел разговор про конкретные лица.
Насколько мне известно вот тут нелюбимая вами фруктовая компания выкладывает все наработки как «взятые из мира опенсорс», так и открытое ими самими.
И раз уж вы обвиняете — подскажите, пожалуйста, что именно вам известно, какой продукт эта самая фирма «не развивает» или от чего «прячет исходники»?
Очень любопытно. Спасибо.lexore
12.06.2015 23:16Можно подискутировать насчет наработок BSD.
До сих пор, если на Mac зайти в консоль, ощущение, что сидишь за FreeBSD — те же команды, вплоть до команды sockstat.
Хотя всегда можно сказать что-то типа «У BSD такая лицензия, когда можно взять и не открывать».
sebres Автор
12.06.2015 23:54Незачто, потому как я вам ничего не собираюсь доказывать… Кто ищет, тот всегда найдёт.
А что выкладывается — ну так когда от лицензии никуда не деться, приходится. Только это имхо, такая капля в море, при тех то доходах и возможностях.
Это дело почти личное — я же пропагандой ни за ни против не занимаюсь…
Ну вот скажите мне, почему каждая статья, какой бы технической не была, сваливается в глубокий холивар о «птичках»?
SneakyJoe
16.06.2015 10:18Автор, скажите пожалуйста — не появилась ли возможность использовать nginx на Windows в паре с ffmpeg без ручного запуска для перекодирования стримов под Windows в другое качество как это возможно под Linux?
sebres Автор
16.06.2015 14:53rtmp? Простите, не было нужды под виндой, так что без понятия. Однако не думаю, что оно сильно сложно проверить… например rtmp-модуль вроде под windows собирается. А как там ffmpeg прикручивается, чтобы на лету, я правда не пользовал…
kvas
16.06.2015 12:33-1Космические корабли уже много лет бороздят просторы и всё такое, но к сожалению немалая часть человечества продолжает мучаться с виндой и прочим майкрософтовским говнософтом. Когда же уже это закончится наконец?
Я не в том смысле, что автор не молодец. Автор молодец, конечно, но как подумаешь сколько времени и сил можно было бы сэкономить если бы не «в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа».
Wedmer
16.06.2015 13:55А у нас кроме проприетарной винды разве нет других систем с той же архитектурой?
mayorovp
16.06.2015 14:32C ReactOS мучаться придется еще больше.
sebres Автор
16.06.2015 15:00Кстати вот не пробовал… а интересно, правда. Время, будь оно неладно.
Если кто вдруг опередит, отпишитесь, плз…mayorovp
16.06.2015 19:11Я пытался использовать ReactOS, когда мне приходилось работать с каким-то уродским vpn-клиентом, и я искал способ вынести vpn-клиент на отдельный сетевой хост (доп. условия задачи: клиент работает только под виндой и у меня нет никакого дистрибутива винды, пусть даже с пробным периодом). Так вот, под Hyper-V у ReactOS попросту не нашлось драйверов для сетевой карты. С такими глупыми проблемами ReactOS еще долго не сможет считаться вариантом решения.
С другой стороны, скорость установки ReactOS и загрузки была такова, что я успел проверить обе возможные конфигурации железа и убедиться в несовместимости ReactOS с Hyper-V пока запускалась отладка нашего проекта. Так что какое-то будущее у ReactOS есть, после решения подобных глупых проблем.sebres Автор
16.06.2015 19:27Имел ввиду nginx 4 win on reactos…
Например, работает ли то же наследование listener, shmem и т.д.
kvas
16.06.2015 15:40Вроде есть, но зачем оно нам? Почему не использовать простой и понятный Unix, который в стопятьсот раз проще и не контролируется одной компанией с весьма сомнительными намерениями. Я понимаю люди делали всякие L4 и Plan9, двигали прогресс, но в случае с Windows, мне кажется что всему прогрессивному человечеству станет гораздо лучше когда мы пройдём этот печальный этап. Я не специалист по архитектуре Windows, и возможно где-то глубоко внутри неё и есть что-то разумное, доброе и вечное, но с точки зрения пользователя, администратора и разработчика я вижу сплошные проблемы и неудобства.
TimsTims
Попахивает мировым прорывом =) windows-админы будут годами благодарить автора
sebres Автор
Не знаю как там насчет «мирового прорыва», вы не представляете насколько я сам себе «благодарен» (а Игорю, Максу и всей команде nginx — за сам nginx под винду).
Не потому что не люблю например тот же IIS или апач, — я даже умею их готовить, а просто разница — все же небо и земля. Ну и потому-что — open source.
Ну а последний фикс позволяет мне делать например ту же балансировку без «всяких» линуксовых (VM) промеж, т.е. прямо в винде.
А вы попробуйте на досуге уговорить например того же корпоративного клиента, поставить где-нибудь линукс, если «у нас везде только виндовс» (причем врет ведь — знаю что врет) и его безопасник кричит «а как я на него антивирус поставлю», «а полиси» и т.д. и т.п.