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


Вы меня все-таки тут путаете...


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

Это сообщение отредактировал(а) drug007 - 15.11.2011, 13:36

Вполне возможно что именно так......
Они разнесены во времени......

Попробую уточнить свое понимание понятия асинхронности:
события в event driven архитектуре всегда наступают асинхронно по определению — мы никогда не знаем, когда произойдет то или иное событие.
Если получив событие, мы его тут же обрабатываем и пока не обработаем текущий поток не возвращает управление, то у нас синхронная обработка.
Если получив событие, текущий поток тут же возвращает управление, а обработка выполняется ядром или в отдельном потоке/процессе, то у нас асинхронная обработка.

т. е. имея асинхронные события, мы можем реагировать на них синхронно или асинхронно. Правильно?

Возвращаясь к выбору архитектуры, я быстренько накидал простенькую модель асинхронной и синхронной на базе потоков. У меня получилось, что время работы у этих архитектур следующее:
    Ttotal async  = N * 2 * Tsyscall  + N * Tprocessing
    Ttotal thread = (N - 1) * Tcontextswitch + N * Tprocessing, 

    где  Ttotal async – время обработки данных в асинхронной архитектуре,
    Ttotal thread – время обработки данных в потоковой модели
    N – количество событий, подлежащих обработке (т. е. соединений),  
    Tsyscall – время системного вызова (двойка т. к. вызовов два на одно событие), 
    Tcontextswitch – время переключения контекста (N-1 т. к. между 2мя событиями 1 переключение, между 3мя — 2 и т.д.),
    Tprocessing — время обработки события, в обоих вариантах одинаковое. 

Первое слагаемое время работы системы ввода/вывода, второе слагаемое время работы бизнес-логики, считаем, что второе слагаемое одинаковое. Отсюда если Tsyscall меньше чем (примерно) 0.5* Tcontextswitch, выигрыш у асинхронной архитектуры, т. к. (Tcontextswitch – 2*Tsyscall) > 0.
Однако при Tprocessing >> (Tcontextswitch - 2*Tsyscall), выигрыш потеряет значение на фоне общей вычислительной нагрузки, при этом модель thread pool проще в разработке и сопровождении, также формулы не учитывают скорость поступления событий или степень нагрузки цпу, что то же самое.
Если же Tprocessing того же порядка или меньше чем (Tcontextswitch – 2*Tsyscall), то выбор за асинхронной архитектурой.
Мои выводы верны? Если да, то продолжу =)

да.


да.


да.


на мой взгляд - да.

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

Это сообщение отредактировал(а) drug007 - 17.11.2011, 14:23

получается так.
но мое ИМХО - мне как-то логически привычней асинхронные реализации.

Добавлено @ 14:10
я пытаюсь отделить ввод/вывод от логики используя disruptor. это позволит абстрагировать логику от ввода/вывода и даст более гибкую и расширяемую структуру.

Это сообщение отредактировал(а) boostcoder - 17.11.2011, 14:22

Ок, буду считать, что с понятием асинхронности я определился.

Тогда опять по выбору архитектуры. Немного повторю предпоследний свой пост, правда.
Получается, что в общем случае мы имеем на входе N событий (это может быть как получение/передача данных, так и соединение/завершение соединения). На обработку каждого события ЦПУ тратит Tprocessing времени. Плюс время на обработку события системой ввода/вывода. Общие затраты времени на обработку N событий равны равны сумме затрат на обработку событий системой ввода/вывода и бизнес-логикой, которые для асинхронной архитектуры складываются из:
Ttotal async = N *2 * Tsyscall + N*Tprocessing,
т. е. затраты будут складываться из стоимости двух системных вызовов (начало и завершение асинхронной операции) на каждое событие плюс время на обработку события бизнес-логикой.
для синхронной:
Ttotal sync = (N-1)*P*Tcontext switch + N*Tprocessing
где P - вероятность переключения контекста, зависит от скорости поступления событий М, времени обработки Tprocessing и числа потоков в пуле k:
    P = 0; при M < 1/Tprocessing - все события обрабатываются одним потоком, нет переключений контекста
    P = M*Tprocessing/k; при M > 1/Tprocessing и M < k/Tprocessing - задействована часть потоков пула, периодически происходит переключение контекста
    P = 1; при M > k/Tprocessing - задействованы все потоки из пула, переключение контекста происходит каждое событие
здесь затраты складываются из времени на переключение контекста плюс время обработки бизнес-логикой. При этом количество переключений контекста меньше чем количество событий минимум на единицу, т. к. необходимость переключения контекста может возникнуть не раньше второго события. Если события поступают со скоростью, позволяющей все события обрабатывать в одном потоке, то количество переключений контекста будет равно нулю. Т.е. если в 1 секунду мы получаем M событий, такое что M <= 1/Tprocessing, то Tcontext switch = 0 (мы понимаем, что цена вызова функции recv и send не зависит от архитектуры, поэтому здесь их не учитываем). Если мы получаем события со скоростью, не позволяющей их обрабатывать одним потоком, то возникают переключения контекста и если мы получаем за 1 секунду М событий, такое, что M > k/Tprocessing, где k – количество потоков в пуле синхронной архитектуры, то контекст будет переключатся N-1 раз на каждые N событий (т.е. начиная со второго события). При M на интервале от 1/Tprocessing до k/Tprocessing вероятность переключения контекста будет соответственно от 0 до 1 (в формуле я взял линейное распределение вероятности для простоты, все равно грубая модель, отражает только мгновенное значение, по идее надо интегрировать, но понятия не имею как  ). 

Отсюда у меня получилось, что:
1) чем больше событий, тем выгоднее асинхронная архитектура, при малом количестве выигрыш синхронной значителен.
2) время обработки в асинхронной не зависит от скорости поступления событий, как в синхронной, поэтому чем выше скорость поступления событий, тем выгоднее асинхронная архитектура (либо увеличивать число потоков в синхронной)
3) чем больше время обработки, тем больше асинхронная архитектура теряет свои позиции
4) и т. д.
Тут бы графики показать, нагляднее было бы... Как это лучше сделать? Мне кажется, получилось бы хорошее дополнение к вопросу о производительности различных архитектур сервера.



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

Это сообщение отредактировал(а) drug007 - 17.11.2011, 14:31

по этому я и решил отделить ввод/вывод от логики при помощи disruptor.

Добавлено через 4 минуты и 6 секунд

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

вот - http://evgeny-lazin.blogspot.com/2011/11/t...ent-driven.html
навеяно в том числе и этим топиком

Добавлено @ 21:57
бесстыдный само-пиар!   

Это сообщение отредактировал(а) Lazin - 17.11.2011, 21:57

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

Добавлено через 9 минут и 2 секунды

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

нужны конечно, просто пост итак большим получился, к тому же, большинству эти уточнения читать было-бы не интересно, они довольно очевидны 


Этому матаппарату в обед сто лет, в смысле ничего я не подгонял и все там достаточно прозрачно. Если не понятно почему именно так и откуда такие выводы, могу объяснить 

Выкладки, учитывающие время переключения контекста и длительность системных вызовов, на мой взгляд, вообще бесполезны, так как не учитывают главного. Допустим мы пишем под windows и используем IOCP. Вызов GetQueuedCompletionStatus действительно не будет приводить к переключению контекста, но, когда мы вытащим из него очередной completion packet, нам нужно будет восстановить контекст выполнения. Это можно сделать, например прочитав значение указателя на функцию обработчик из OVERLAPPED структуры и вызвав ее с нужными параметрами. Так вот этот overhead тоже нужно учитывать. В случае многопоточного сервера это делать не нужно, так как поток это и есть контекст выполнения и им не нужно явно управлять, адрес обработчика уже находится в IP регистре, а все нужные переменные уже находятся в стеке 
Помимо этого, event based сервер может быть многопоточным, в этом случае completion packet может быть обработан на любом ядре, что приведет к кэш промаху, а потоки обычно бывают привязаны к одному ядру.
Вообще, на мой взгляд, event based подход к созданию сереверов это костыль. Если подумать, то используя IOCP, epool или kqueue программист создает свои потоки, сам таскает контекст, сам управляет переключением этих контекстов. Все из-за того что потоки плохо масштабируются, в своей текущей реализации.

Объясните.    Например я категорически несогласен когда вы описываете, что производительность многопоточного сервера T = M/(I+C), а производительность асинхронного T = N/C. ИМХО первая формула является частным случаем второй, т.к. вторая описывает производительность идеального сервера с идеальной подсистемой ввода/вывода, а первая описывает идеальный сервер с неидеальной подсистемой ввода/вывода. Ибо знаменатели в них равны, т.к. в любом случае производительность потоков никогда не будет больше, чем производительность ЦПУ. Поэтому сравнение некорректное, а выводы в принципе правильные. 




Не то, чтобы главного, но многого они не учитывают, это да. Об этом я вчера вечером и подумал, отчего и огорчился немного.

З.Ы. ваша модель этого тоже не учитывает, кстати    

там есть оговорка по поводу того, что первая формула верна только до тех пор, пока процессор не будет загружен на 100%
для одного потока справедливо соотношение - время выполнения запроса = время выполнения синхронных операций ввода вывода + время обработки, это очевидно, ибо во время выполнения синхронного ввода/вывода поток простаивает
выглядит это как-то так:

красный график - I/O, зеленый - CPU
важное допущение, мы считаем что I/O подсистема у нас - идеальна, обладает бесконечной пропускной способностью и concurrency, а CPU - нет. Теперь, если мы запустим 2 потока, то I/O у нас сможет происходить параллельно, а обработка - нет (считаем что CPU - один)
то бишь, пропускная способность одного потока:
1/(I + C), I - время выполнения I/O операций запроса, С - время обработки, если запустить K потоков, то пропускная способность будет выше в K раз, но только если процессор не полностью загружен. если он загружен полностью, то добавление еще одного потока не приведет к увеличению пропускной способности. При таком K, при котором процессор загружен полностью, пропускная способность сервера максимальная, но при этом, пропускная способность сервера ограничена сверху. В результате зависимость T от K должна быть примерно такой (в реальности она такой будет только при сравнительно небольшом К - десятки, сотни потоков):


в случае асинхронного сервера, пропускная способность максимальна тогда, когда процессор загружен полностью, полностью он загружен тогда, когда непрерывно обрабатывает completion handler-ы от завершившихся операций ввода вывода, отсюда очевидна формула:
T = 1/C (для одного ядра)
можно сказать что С - время выполнения всех обработчиков, которые вызываются при обработке запроса. накладные расходы, связанные с работой ОС мы игнорируем, считаем что процессор целиком принадлежит нашему приложению (на самом деле это даст не такую уж и большую погрешность)

если теперь мы приравняем две эти пропускные способности, это можно сделать, ибо макс. пропускная способность сервера в случае идеальной I/O подсистемы с бесконечными ресурсами ограничивается только процессором, то получим:
1/C = K/(I + C), 
откуда можно получить K - число потоков при котором достигается пропускная способность, эквивалентная event driven серверу
если K - десятки/сотни, то возиться с событиями нет никакого смысла
естественно здесь есть погрешности, допущения и неточности, вот только это не мешает оценить порядок K, а именно порядок K нас и интересует

Добавлено через 6 минут и 4 секунды

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

Это сообщение отредактировал(а) Lazin - 18.11.2011, 11:54

Ну это как  сказать.
Надо все же отделить event driven, где каждый event loop (active object, actor) крутится в отдельном потоке ("thread-per-object-loop"), от event driven на базе пула потоков ("event driven with thread-pool").

В данном обсуждении под "event driven" понимается как раз "event driven with thread-pool", что, действительно, похоже на костыль. Хотя... все ресурсы ограничены. В любом случае где-то все равно должно быть сужение N (кол-во обслуживаемых клиентов) -> M (кол-во ядер процессора).

"thread-per-object-loop", кажется, исповедует Erlang. С теоретической точки зрения этот вариант лучше (естественней) описывает процесс "обслуживания" клиента. Ну и, конечно, природа event driven позволяет логике "thread-per-object-loop" плавно перетекать в "event driven with thread-pool" (простота переноса кода сильно зависит от языка/инструментария).

Мой предыдущий пост был как раз про то, что "thread-per-session" тоже "не сахар". Приходится аккуратно работать с shared data. Много логики остается в проверках флагов и синхронизации. Вообще, класс session архитектурно получается сильно связан с понятием thread. Приходится явно выделять shared data и обеспечивать отдельный доступ к этой части session. Так что, чем больше shared data, тем ближе оверкод "thread-per-session" к оверкоду "event-driven" ("thread-per-object-loop" или "event driven with thread-pool").

P.S. Автор темы все еще не определился с архитектурой?


Это сообщение отредактировал(а) mabrarov - 18.11.2011, 16:29

Определился - асинхронная.

Благодаря обсуждению, я пришел к выводу, что для текущих требований оптимальна будет архитектура thread-per-connection и по сложности и по быстродействию, но она плохо масштабируема, а требования могут поменяться и я решил остановится на асинхронной архитектуре, как более универсальной. У нее ИМХО один недостаток - сложность, но в данном случае он приемлем.