- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
там намного сложнее все. в моем понимании основная работа перекладывается на ОС, например для отдачи файлов используется sendfile, остается только следить за событиями.
но ведь nginx работает достаточно эффективно и с отключенным sendfile и отключенным aio.
netwind добавил 29.10.2011 в 19:46
Я думаю что эффект от создания такого функционального распараллеливания скорее всего был бы, но это усложнило бы и код и процесс отладки, а выйгрышь возможно был не более 5%
да не в отладке дело
ваша выдумка потребует обмена данными между потоками, а это в свою очередь требует строгой синхронизации и неизбежных накладных расходов на ожидания, переключения и тд.
зачем ? в nginx каждый процесс полностью независим и на всех остальных плевал.
но ведь nginx работает достаточно эффективно и с отключенным sendfile и отключенным aio.
я не спорю. не используется одно, значит используется другое, что также эффективно работает без создания потоков внутри процесса.
чтобы понять глубину продукта надо посвятить минимум несколько суток в изучении кода. причем не у каждого еще это получится...
ваша выдумка потребует обмена данными между потоками, а это в свою очередь требует строгой синхронизации и неизбежных накладных расходов на ожидания, переключения и тд.
зачем ? в nginx каждый процесс полностью независим и на всех остальных плевал.
Какой еще обмен данными между потоками? Такие нити должны работают с одной кучей.
Синхронизация конечно нужна, как и в любой паралелльной системе, но имхо такая синхронизация требует минимальных накладных расходов ввиду разной функциональности нитей...
и много чаго еще делает... Делать эти задачи в отдельных нитях весьма логично.
вот возьмем это утверждение
логично где? в десктопных приложениях с интерфейсной и рабочей частью ?
ничего логичного. это у вас типичный шаблон десктопного разработчика сработал.
netwind добавил 29.10.2011 в 19:55
Синхронизация конечно нужна, как и в любой паралелльной системе, но имхо такая синхронизация требует минимальных накладных расходов ввиду разной функциональности нитей...
а в nginx не нужна. фокус !
чтобы понять глубину продукта надо посвятить минимум несколько суток в изучении кода. причем не у каждого еще это получится...
Да, дейтсвительно спорить тут бесполезно, тем более о том почему кто-то что-то сделал или не сделал.
Просто имхо мнение что "так однозначно эффективней чем Вы предлагаете" это не конструктив...
Кому интересно, тот посмотрит код, а остальным и не надо :)
babnicks добавил 29.10.2011 в 19:58
вот возьмем это утверждение
логично где? в десктопных приложениях с интерфейсной и рабочей частью ?
Да причем тут десктопы-то??? Вы о чем вообще? С точки зрения программирования логично.
Просто логично что если процессы можно выполнить параллельно их надо выполнять параллельно, без фанатизма конечно, но все-же...
Никто не говорит о расплождении процессов по кол-ву коннектов, но возьмите Вы блин любой сервер БД или еще что-то, да там с десяток нитей наберется. А Вы про десктоп вспоминаете...
Зачем гнать-то уже конкретно?
а в nginx не нужна. фокус !
И что? А какие расходы на синхронизацию в описываемом мной подходе? Вы их считали?
И вообще Вы понимаете что если уже подходить чисто формально, то nginx распралеливает обработку коннектов, только делает это не сам, а отдает другим процессам через проксирование.
Это чем отличается от создания внутри nginx'а хотя-бы отдельных нитей для разных проксируемых приложений и работы со статикой?
Также есть вариант создание нитей для каждого из описываемых location'ов, тоже возможно дало-бы свои +
Я не спорю с тем, что nginx хороший продукт, но у Вас какая-то странная иллюзия что nginx не нуждается в доработках, что это идеальный продукт :)
если можно создать себе дополнительных сложностей - их нужно создать.
офигеть как логично.
netwind добавил 29.10.2011 в 20:11
И что? А какие расходы на синхронизацию в описываемом мной подходе? Вы их считали?
это то, что полностью скрыто от десктопного программиста разнообразными абстракциями и библиотеками.
не могут две нити просто так обменяться данными. каждая должна убедиться , что другая не ведет запись или чтение одну и ту же область памяти для обмена. тут и получается, что одна нить ожидает другой. при сложном взаимодействии подобные инциденты накапливаются и потери времени на ожидание становятся ощутимыми.
нет обмена данными - нет ожидания, есть nginx.
если можно создать себе дополнительных сложностей - их нужно создать. офигеть как логично.
😂😂😂 Все, я спорить больше с Вами не собираюсь, Вы перешли в режим "веры" и внушения мне чаго я знаю и понимаю, а чаго нет, такое не лечится...
Исходя из Вашей логики вообще паралельное программирование это зло и нужно только для декстопов... имхо Вы перешли грань добра и зла в своих утверждениях :)
занавес... 😂 аплодисменты...
Вы перешли в режим "веры"
вы из него и не выходили, если считаете параллельное программирование необходимой вещью и пытаетесь придумать где бы его можно еще использовать.
вы из него и не выходили, если считаете параллельное программирование необходимой вещью и пытаетесь придумать где бы его можно еще использовать.
Я считаю что во всем нужна мера, и процессы которые действительно параллельны надо выполнять параллельно, если это не приводит к непомерным расходом на их диспетчеризацию, именно для этого создаются многопроцессорные ЭВМ и многоядерные процессоры ;)
В разумных пределах параллельное программирование действительно необходимость, такова природа вещей, как бы Вам не хотелось обратного ;)
babnicks, Ну вот.
теперь следующий тезис : в задачах для которых создан nginx, число клиентов ЗНАЧИТЕЛЬНО превосходит количество процессоров ( по крайней мере, значительней чем обычно в субд/вебсерверах/десктопных программах), а значит расходы на обмен и диспетчеризацию тоже будут значительными.
Тут не надо пытаться распараллелить, чтобы нагрузить второй процессор - он и так нагружен другими клиентами.