Немного про nginx

но ведь nginx работает достаточно эффективно и с отключенным sendfile и отключенным aio.

netwind добавил 29.10.2011 в 19:46

да не в отладке дело

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

зачем ? в nginx каждый процесс полностью независим и на всех остальных плевал.

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

чтобы понять глубину продукта надо посвятить минимум несколько суток в изучении кода. причем не у каждого еще это получится...

Какой еще обмен данными между потоками? Такие нити должны работают с одной кучей.

Синхронизация конечно нужна, как и в любой паралелльной системе, но имхо такая синхронизация требует минимальных накладных расходов ввиду разной функциональности нитей...

вот возьмем это утверждение

логично где? в десктопных приложениях с интерфейсной и рабочей частью ?

ничего логичного. это у вас типичный шаблон десктопного разработчика сработал.

netwind добавил 29.10.2011 в 19:55

а в nginx не нужна. фокус !

Да, дейтсвительно спорить тут бесполезно, тем более о том почему кто-то что-то сделал или не сделал.

Просто имхо мнение что "так однозначно эффективней чем Вы предлагаете" это не конструктив...

Кому интересно, тот посмотрит код, а остальным и не надо :)

babnicks добавил 29.10.2011 в 19:58

Да причем тут десктопы-то??? Вы о чем вообще? С точки зрения программирования логично.

Просто логично что если процессы можно выполнить параллельно их надо выполнять параллельно, без фанатизма конечно, но все-же...

Никто не говорит о расплождении процессов по кол-ву коннектов, но возьмите Вы блин любой сервер БД или еще что-то, да там с десяток нитей наберется. А Вы про десктоп вспоминаете...

Зачем гнать-то уже конкретно?

И что? А какие расходы на синхронизацию в описываемом мной подходе? Вы их считали?

И вообще Вы понимаете что если уже подходить чисто формально, то nginx распралеливает обработку коннектов, только делает это не сам, а отдает другим процессам через проксирование.

Это чем отличается от создания внутри nginx'а хотя-бы отдельных нитей для разных проксируемых приложений и работы со статикой?

Также есть вариант создание нитей для каждого из описываемых location'ов, тоже возможно дало-бы свои +

Я не спорю с тем, что nginx хороший продукт, но у Вас какая-то странная иллюзия что nginx не нуждается в доработках, что это идеальный продукт :)

если можно создать себе дополнительных сложностей - их нужно создать.

офигеть как логично.

netwind добавил 29.10.2011 в 20:11

это то, что полностью скрыто от десктопного программиста разнообразными абстракциями и библиотеками.

не могут две нити просто так обменяться данными. каждая должна убедиться , что другая не ведет запись или чтение одну и ту же область памяти для обмена. тут и получается, что одна нить ожидает другой. при сложном взаимодействии подобные инциденты накапливаются и потери времени на ожидание становятся ощутимыми.

нет обмена данными - нет ожидания, есть nginx.

😂😂😂 Все, я спорить больше с Вами не собираюсь, Вы перешли в режим "веры" и внушения мне чаго я знаю и понимаю, а чаго нет, такое не лечится...

Исходя из Вашей логики вообще паралельное программирование это зло и нужно только для декстопов... имхо Вы перешли грань добра и зла в своих утверждениях :)

занавес... 😂 аплодисменты...

вы из него и не выходили, если считаете параллельное программирование необходимой вещью и пытаетесь придумать где бы его можно еще использовать.

Я считаю что во всем нужна мера, и процессы которые действительно параллельны надо выполнять параллельно, если это не приводит к непомерным расходом на их диспетчеризацию, именно для этого создаются многопроцессорные ЭВМ и многоядерные процессоры ;)

В разумных пределах параллельное программирование действительно необходимость, такова природа вещей, как бы Вам не хотелось обратного ;)

babnicks, Ну вот.

теперь следующий тезис : в задачах для которых создан nginx, число клиентов ЗНАЧИТЕЛЬНО превосходит количество процессоров ( по крайней мере, значительней чем обычно в субд/вебсерверах/десктопных программах), а значит расходы на обмен и диспетчеризацию тоже будут значительными.

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