Здравствуйте, netch80, Вы писали:

N>Про "нормальную технологию", если уж вдаваться в эти детали — kqueue и epoll представляют собой полный аналог IOCP
Это хорошо. Только почему их так неохотно используют? "Линус Торвальдс его необоснованно не любит." Почитал по твоей ссылке — ну полный же бардак. Настоящая демократия

N>Только по сравнению с Windows, у kqueue и вообще построения работы с файловыми объектами в Unix есть существенное преимущество: нет принудительного неустранимого навязывания асинхронного стиля при открытии; независимо от того, откуда и как ты получил дескриптор — ты можешь, если хочешь, работать по старинке блокирующими вызовами, можешь — через полное AIO, можешь — через общий мультиплексор типа select. В Windows такой гибкости нет.
Оно, может, и полезно, но с наскоку придумать применение сложно. Ни разу не требовалось. Но согласен, лучше иметь возможность, чем не иметь.

N>Смутное преимущество виндовых IOCP состоит в том, что, если верить MSDN, поместить в них сообщение может каждый, а не только ядро. Но не думаю, что кому-то есть смысл делать из IOCP очередь сообщений уровня userland.
Ты про PostQueuedCompletionStatus? Это очень (очень) полезный функционал, используется постоянно.

N>Ну а здоровье и душевное равновесие мы успешно получаем применением библиотек, которые в зависимости от возможностей платформы сами выбирают адекватное средство. С учётом того, что платформа вообще более спокойна (меньше странностей, неизвестных средств с отвратительной документацией и недокументированными особенностями), мне кажется, что моё, как программиста под Unix, душевное равновесие куда стабильнее, чем у среднего коллеги под Windows
С библиотеками оно, конечно, понятно. Но если кто-то захочет узнать как оно внутри, то, пройдя по твоей ссылке, впадет в уныние
То ли дело под виндой!

Здравствуйте, Gomes, Вы писали:

N>>Про "нормальную технологию", если уж вдаваться в эти детали — kqueue и epoll представляют собой полный аналог IOCP
G>Это хорошо. Только почему их так неохотно используют? "Линус Торвальдс его необоснованно не любит." Почитал по твоей ссылке — ну полный же бардак. Настоящая демократия :)

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

Насчёт "неохотно используют" — используют как раз охотно, там, где есть, потому что действительно удобно. И средства достаточно неплохие есть: например, в линуксе, где AIO не может сигнализировать в порт типа kqueue, можно вместо этого попросить посылать сигнал. Но и в BSD можно его попросить послать сигнал (посылка сигнала требуется по Posix), так что в результате всё равно есть общая база для реализации.

N>>Только по сравнению с Windows, у kqueue и вообще построения работы с файловыми объектами в Unix есть существенное преимущество: нет принудительного неустранимого навязывания асинхронного стиля при открытии; независимо от того, откуда и как ты получил дескриптор — ты можешь, если хочешь, работать по старинке блокирующими вызовами, можешь — через полное AIO, можешь — через общий мультиплексор типа select. В Windows такой гибкости нет.
G>Оно, может, и полезно, но с наскоку придумать применение сложно. Ни разу не требовалось. Но согласен, лучше иметь возможность, чем не иметь.

Применение как раз тривиально, если знать Unix. Есть масса ситуаций, когда процесс запускается имея на stdin и stdout предварительно открытые файлы (последовательного типа — пайпы или сокеты): например, вызов из-под inetd. Нужно, чтобы это работало независимо от того, будет ли он работать с ними просто синхронно, асинхронно через мультиплексор или асинхронно через IOCP.

N>>Смутное преимущество виндовых IOCP состоит в том, что, если верить MSDN, поместить в них сообщение может каждый, а не только ядро. Но не думаю, что кому-то есть смысл делать из IOCP очередь сообщений уровня userland.
G>Ты про PostQueuedCompletionStatus? Это очень (очень) полезный функционал, используется постоянно.

Например, зачем? И в чём преимущество по сравнению с просто очередью, учитывая то, что в PostQueuedCompletionStatus надо изображать из себя файловый объект и соответственно маскировать данные?

N>>Ну а здоровье и душевное равновесие мы успешно получаем применением библиотек, которые в зависимости от возможностей платформы сами выбирают адекватное средство. С учётом того, что платформа вообще более спокойна (меньше странностей, неизвестных средств с отвратительной документацией и недокументированными особенностями), мне кажется, что моё, как программиста под Unix, душевное равновесие куда стабильнее, чем у среднего коллеги под Windows:)
G>С библиотеками оно, конечно, понятно. Но если кто-то захочет узнать как оно внутри, то, пройдя по твоей ссылке, впадет в уныние ;)
G>То ли дело под виндой! :)) :beer:

Ну да, под виндой он сразу повесится и проблема отпадёт сама собой:)

Здравствуйте, netch80, Вы писали:

N>Например, зачем? И в чём преимущество по сравнению с просто очередью, учитывая то, что в PostQueuedCompletionStatus надо изображать из себя файловый объект и соответственно маскировать данные?
Посылать свои, например, управляющие коды в очередь обработчика. Например, чтобы завершить потоки пула. И не надо из себя изображать ни файловый ни какой другой объект.

N>Ну да, под виндой он сразу повесится и проблема отпадёт сама собой
ХОЛИВАР!!!
Под виндой все проще и понятнее! Потому как тоталитаризьм!

Здравствуйте, Gomes, Вы писали:

N>>Например, зачем? И в чём преимущество по сравнению с просто очередью, учитывая то, что в PostQueuedCompletionStatus надо изображать из себя файловый объект и соответственно маскировать данные?
G>Посылать свои, например, управляющие коды в очередь обработчика. Например, чтобы завершить потоки пула. И не надо из себя изображать ни файловый ни какой другой объект.

Ну на kqueue это и так делается. А для остальных signal pipe достаточно дёшев:)

N>>Ну да, под виндой он сразу повесится и проблема отпадёт сама собой:)
G>ХОЛИВАР!!!
G>Под виндой все проще и понятнее! Потому как тоталитаризьм!

В *BSD тоже тоталитаризьма, но при этом можно всё увидеть простейшим образом:) Так что да, холивар:)

Здравствуйте, VladD2, Вы писали:
VD>И что в итоге выходит на одного активного клиента?
Трафик на него выходит, трафик
Пул потоков там очень маленький — порядка десятка потоков на одно ядро.
При этом "активных клиентов" могут быть десятки тысяч.

VD>>И что в итоге выходит на одного активного клиента?
S>Трафик на него выходит, трафик
S>Пул потоков там очень маленький — порядка десятка потоков на одно ядро.
S>При этом "активных клиентов" могут быть десятки тысяч.

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

Здравствуйте, VGn, Вы писали:
VGn>Имхо это сложное управление потоками, а не отсутствие управления потоками.
Я ничего не говорил про отсутствие управления потоками. Да, IOCP — достаточно сложная штука по сравнению с "простым" управлением потоками в стиле "1 поток на клиента".
VGn>То, что люди с потоками работать не умеют, не является причиной их стратегической нецелесообразности, тем более учитывая нынешнее развитие технологий.
Ну не знаю. Пока что мне непонятно, будут ли эти люди стратегически нецелесообразны, с учётом развития нынешних технологий.
Всё существенно зависит от стиля обучения. Пока люди думают о программировании как о задаче построения алгоритма, многопотоковость будет оставаться проблемой.
Потому что само определение алгоритма подразумевает единственного вычислителя, модифицирующего некое глобальное состояние. А если с самого начала обучать людей по-другому, то и результат будет другим.

G>>Под виндой все проще и понятнее! Потому как тоталитаризьм!

N>В *BSD тоже тоталитаризьма, но при этом можно всё увидеть простейшим образом Так что да, холивар

Рекомендую одеть кастрюли на головы и отправиться в Священные войны

Здравствуйте, Sinclair, Вы писали:

S>Пул потоков там очень маленький — порядка десятка потоков на одно ядро.
S>При этом "активных клиентов" могут быть десятки тысяч.

Издеваешься что ли? 10 потоков на проц это очень даже не мало. На большинстве сайтов 10 параллельных запросов — это уже много.
Потом, что будет если у нас пользователей больше чем 10, а проц один? Они пойдут в очередь? Офигительный параллелизм.

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

Здравствуйте, VladD2, Вы писали:
VD>Издеваешься что ли? 10 потоков на проц это очень даже не мало.
Нормально. В ASP.NET по умолчанию 25.
VD>На большинстве сайтов 10 параллельных запросов — это уже много.
VD>Потом, что будет если у нас пользователей больше чем 10, а проц один? Они пойдут в очередь? Офигительный параллелизм.
Совершенно верно — офигительный.
Потому что при IOCP потоки пула никогда не блокируются на вводе/выводе. Вместо этого они подхватывают следующий запрос и выполняют его.
Веб-сервер — это I/O Bound работа. Потому что латентность сети очень высока. Так что десять потоков могут окучить огромное количество одновременно открытых сокетов.

VD>Это свидетельствует только о том, что технологии не дотягивают.
Технологии дотягивают. Влад, я тебя уверяю — ты вспотеешь рвать IIS по производительности.

VD>По уму в веб-сервере должны поддерживаться легкие потоки (а-ля Эрланг) и на каждый запрос выделяться по такому клиенту, а уже они должны распределяться между процессорами.
Ты, наверное, не в курсе, что такое I/O Completion Port? Это и есть что-то типа лёгких потоков, только программировать их не так удобно.
Вот Рихтер придумал библиотечку для .Net, которая даёт улучшенный API к IOCP — по сравнению с ручным программированием коллбэков и протаскиванием состояния.

Здравствуйте, VGn, Вы писали:

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

Вот скажи, что заставляет высказывать подобное, абсолютно не разбираясь в теме? Лично я, если чуть в сторону от своей специализации — буду задавать вопросы и конспектировать. Так что, если что не понятно — спрашивай :)

S>>Пул потоков там очень маленький — порядка десятка потоков на одно ядро.
S>>При этом "активных клиентов" могут быть десятки тысяч.

VD>Издеваешься что ли? 10 потоков на проц это очень даже не мало. На большинстве сайтов 10 параллельных запросов — это уже много.
VD>Потом, что будет если у нас пользователей больше чем 10, а проц один? Они пойдут в очередь? Офигительный параллелизм.

Поддерживаю. Заглянул тут в менеджер задач.
76 процессов. 894 потока. на 2х ядрах
И ничего. Не напрягается. (хотя задачи конечно десктопные и большинство в ожидании, но не суть)

G>Вот скажи, что заставляет высказывать подобное, абсолютно не разбираясь в теме? Лично я, если чуть в сторону от своей специализации — буду задавать вопросы и конспектировать. Так что, если что не понятно — спрашивай

Это IT. Здесь теряешь часть квалификации и за время кофе-брейка. Так что имхо не стоит задирать нос.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, VladD2, Вы писали:
VD>>Издеваешься что ли? 10 потоков на проц это очень даже не мало.
S>Нормально. В ASP.NET по умолчанию 25.
VD>>На большинстве сайтов 10 параллельных запросов — это уже много.
VD>>Потом, что будет если у нас пользователей больше чем 10, а проц один? Они пойдут в очередь? Офигительный параллелизм.
S>Совершенно верно — офигительный.
S>Потому что при IOCP потоки пула никогда не блокируются на вводе/выводе. Вместо этого они подхватывают следующий запрос и выполняют его.
S>Веб-сервер — это I/O Bound работа. Потому что латентность сети очень высока. Так что десять потоков могут окучить огромное количество одновременно открытых сокетов.

У меня есть подозрение, что вы говорите немного о разном — о задаче "сформировать контент" (которая плохо ложится на событийно-коллбэковую организацию, требуюмую при IOCP) и "отдать уже сформированный контент" (которая как раз на него практически идеально ложится). Делать, чтобы они обе исполнялись в одной и той же подзадаче (нити, процессе) оказывается легко в написании, но неэффективно при существенной нагрузке: переключения контекстов подзадач слишком дороги.

В случае их разделения можно делать для отработки по сути функции — "стрелкИ" (в смысле, "получил команду — выстрелил — забыл"), а отдачу результата возложить уже на другой слой, которому организация на IOCP, poll/kqueue/etc. и прочих событийно-управляемых "по мелочи" движках прописана по определению.

В Unix мире это реализуется несколькими путями, к которым можно привести классические примеры:

1. Отдельно стоящий кэширующий и отдающий процесс-сервер, забирающий данные крупными порциями, обычно сейчас это nginx. У него событийно-управляемое построение и задачу "передать следующую порцию данных" он решает лучше сложного сервера. Дополнительно можно получить от этого несколько вкусностей: сокрытие внутренней сети, лёгкая отдача статического контента.

2. Accept filter в ядре (FreeBSD) и аналогичные средства других систем: HTTP accept filter на сокете не выдаёт результат accept() в userland до тех пор, пока не наберётся полный HTTP запрос (есть два варианта фильтра — только по заголовкам или по телу тоже), после чего процесс сервера может получить запрос за один вызов. На специфических задачах вроде того же прокси-фронтэнда ускорение от этого может быть в разы, на "обобщённых на все случаи" серверах вроде Apache — меньше, но тоже заметно.

Повторюсь — с использованием таких средств ситуация что "веб-сервер зависит от латентности сети" как-то уходит:)

Краем уха слышал, что в IIS применяются похожие подходы, но не буду давать даже треть зуба за это:)

VD>>По уму в веб-сервере должны поддерживаться легкие потоки (а-ля Эрланг) и на каждый запрос выделяться по такому клиенту, а уже они должны распределяться между процессорами.
S>Ты, наверное, не в курсе, что такое I/O Completion Port? Это и есть что-то типа лёгких потоков, только программировать их не так удобно.

В данном случае "не так удобно" может вылиться в колоссальные недостатки, если сравнить необходимость рисования FSM с возможностью линейного написания действий в духе "получил A, передал B, получил ответ, отдал C".

S>Вот Рихтер придумал библиотечку для .Net, которая даёт улучшенный API к IOCP — по сравнению с ручным программированием коллбэков и протаскиванием состояния.

URL? Пределы возможностей?

Здравствуйте, Sinclair, Вы писали:

S>Потому что при IOCP потоки пула никогда не блокируются на вводе/выводе. Вместо этого они подхватывают следующий запрос и выполняют его.
S>Веб-сервер — это I/O Bound работа. Потому что латентность сети очень высока. Так что десять потоков могут окучить огромное количество одновременно открытых сокетов.

Про сокеты речи и не шало. Речь шла о праллельных запросах. И более 10 их окучить не удастся. При этом будет не хилый оверхэд на переключение контекста.

Почитай про эрланг. Для него (хотя язык интерпретатор) и 1000 праллельно работающих задач — это нормально.

VD>>Это свидетельствует только о том, что технологии не дотягивают.
S>Технологии дотягивают. Влад, я тебя уверяю — ты вспотеешь рвать IIS по производительности.

А меня и уверять не надо. Я и так заню, что подход фиговенький.

VD>>По уму в веб-сервере должны поддерживаться легкие потоки (а-ля Эрланг) и на каждый запрос выделяться по такому клиенту, а уже они должны распределяться между процессорами.
S>Ты, наверное, не в курсе, что такое I/O Completion Port? Это и есть что-то типа лёгких потоков, только программировать их не так удобно.

В курсе. Это не потоки, это фигня. Это способ асинхронной обработки IO.

S>Вот Рихтер придумал библиотечку для .Net, которая даёт улучшенный API к IOCP — по сравнению с ручным программированием коллбэков и протаскиванием состояния.

Это все козьи потягушки.

Здравствуйте, Gomes, Вы писали:

G>Вот скажи, что заставляет высказывать подобное, абсолютно не разбираясь в теме? Лично я, если чуть в сторону от своей специализации — буду задавать вопросы и конспектировать. Так что, если что не понятно — спрашивай

Не тебе судить о том в чем я разбираюсь. Ты никто и зовут тебя никак. Так что спрашивать тебя мне не о чем. Одью.

Здравствуйте, VladD2, Вы писали:
VD>Про сокеты речи и не шало. Речь шла о праллельных запросах.
Не очень понятно, что такое "запрос" в твоей интерпретации.
VD>И более 10 их окучить не удастся. При этом будет не хилый оверхэд на переключение контекста.
А кто тебе сказал, что будут вообще переключения контекста?
VD>Почитай про эрланг. Для него (хотя язык интерпретатор) и 1000 праллельно работающих задач — это нормально.
Ты намекаешь на то, что в эрланге низкая стоимость переключения контекста? Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.

VD>А меня и уверять не надо. Я и так заню, что подход фиговенький.
Ну, я не стану давать тебе советов, но лично я бы сначала ознакомился с предметом. А уже потом делал выводы.

Здравствуйте, netch80, Вы писали:

N>У меня есть подозрение, что вы говорите немного о разном — о задаче "сформировать контент" (которая плохо ложится на событийно-коллбэковую организацию, требуюмую при IOCP) и "отдать уже сформированный контент" (которая как раз на него практически идеально ложится).
Отличный поинт.
Давайте поймем, что такое "сформировать контент", и почему он так плохо ложится на событийную организацию.
Вообще говоря, современный динамический веб — это в 99% склеивание респонса из фрагментов. Как правило — строковых.
Само по себе склеивание определяется стоимостью строковых операций в использованной платформе.
А фрагменты берутся из файлов на диске, либо из СУБД. Иногда их тянут через сеть — к примеру, от внешнего SOAP/REST/etc сервиса.

Как видим, "формирование контента" — это лапша из некоторого количества IO-bound задач, которые склеиваются CPU-bound операциями конкатенации.
Еще 1% — это стуфф типа "ресайз картинок", в котором тоже значительная часть чистого времени уходит на собственно поднятие исходной картинки с диска.

Таким образом, из 1500 миллисекунд, которые нужны среднестатистическому хэндлеру на всё, он может проводить в летаргическом сне порядка 1000 миллисекунд — ожидая того или иного события. (Цифры — с потолка, для иллюстративных целей).

N>Делать, чтобы они обе исполнялись в одной и той же подзадаче (нити, процессе) оказывается легко в написании, но неэффективно при существенной нагрузке: переключения контекстов подзадач слишком дороги.

N>В случае их разделения можно делать для отработки по сути функции — "стрелкИ" (в смысле, "получил команду — выстрелил — забыл"), а отдачу результата возложить уже на другой слой, которому организация на IOCP, poll/kqueue/etc. и прочих событийно-управляемых "по мелочи" движках прописана по определению.
Вообще-то в современных серверах это обычно так и делается. Прямого доступа к сокету веб-приложение не имеет; оно просто формирует некий буфер, а то, как именно этот буфер поедет клиенту, решает инфраструктура.

N>В Unix мире это реализуется несколькими путями, к которым можно привести классические примеры:

N>1. Отдельно стоящий кэширующий и отдающий процесс-сервер, забирающий данные крупными порциями, обычно сейчас это nginx. У него событийно-управляемое построение и задачу "передать следующую порцию данных" он решает лучше сложного сервера. Дополнительно можно получить от этого несколько вкусностей: сокрытие внутренней сети, лёгкая отдача статического контента.

N>2. Accept filter в ядре (FreeBSD) и аналогичные средства других систем: HTTP accept filter на сокете не выдаёт результат accept() в userland до тех пор, пока не наберётся полный HTTP запрос (есть два варианта фильтра — только по заголовкам или по телу тоже), после чего процесс сервера может получить запрос за один вызов. На специфических задачах вроде того же прокси-фронтэнда ускорение от этого может быть в разы, на "обобщённых на все случаи" серверах вроде Apache — меньше, но тоже заметно.

N>Повторюсь — с использованием таких средств ситуация что "веб-сервер зависит от латентности сети" как-то уходит

N>Краем уха слышал, что в IIS применяются похожие подходы, но не буду давать даже треть зуба за это
Да. Во-первых, в IIS применен драйвер ядра http.sys, который занимается взаимодействием с сокетами. Это позволяет решить несколько проблем — например, позволить нескольким процессам "висеть на 80м порту", разделяясь по URL. Но в основном это, конечно, производительность — предварительный разбор запроса, обработка кэша в режиме ядра, взаимодействие с файловой системой.
Но это всё — прозрачно для веб-приложения. С точки зрения, к примеру, ASP.NET, ядро IIS выступает в роли этакого "локального nginx".

N>В данном случае "не так удобно" может вылиться в колоссальные недостатки, если сравнить необходимость рисования FSM с возможностью линейного написания действий в духе "получил A, передал B, получил ответ, отдал C".
Совершенно верно. Именно в эту сторону сейчас копают ведущие собаководы.

S>>Вот Рихтер придумал библиотечку для .Net, которая даёт улучшенный API к IOCP — по сравнению с ручным программированием коллбэков и протаскиванием состояния.
N>URL? Пределы возможностей?
http://www.wintellect.com/PowerThreading.aspx
Вот его статья про это http://msdn.microsoft.com/en-us/magazine/cc163323.aspx
Ограничений — масса. В основном, конечно, это некрасивость записи по сравнению с линейным написанием. Но всё равно — встроенный в шарп генератор FSM достаточно мощен.
На немерле можно было бы вообще замутить всё еще круче, если только знать, что именно круче. Пока что лично мне неочевидно, какой именно синтаксис тут будет нужен. Мы это кратко обсуждали с Джеффри — я предлагал автоматически заменять в линейном коде блокирующие вызовы на "точки переключения" контекста лёгкого потока. В ответ Рихтер указал на то, что уже сейчас в Power Threading есть возможность указать N запросов для параллельного исполнения, что недостижимо при "обычном" синтаксисе.
Вот как-то так.

Здравствуйте, Sinclair, Вы писали:

S>На немерле можно было бы вообще замутить всё еще круче, если только знать, что именно круче. Пока что лично мне неочевидно, какой именно синтаксис тут будет нужен. Мы это кратко обсуждали с Джеффри — я предлагал автоматически заменять в линейном коде блокирующие вызовы на "точки переключения" контекста лёгкого потока. В ответ Рихтер указал на то, что уже сейчас в Power Threading есть возможность указать N запросов для параллельного исполнения, что недостижимо при "обычном" синтаксисе.

В axum есть возможность делать асинхронные вызовы, выглядяще как синхронные и запускать множество таких параллельно.
Причем средставми метапрограммирования имхо тоже самое достижимо будет и в nemerle.