Разница между шаблоном проактора и синхронной моделью в веб-сервере

Question

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

Между тем, асинхронная модель позволяет клиенту и серверу работать раздельно и независимо. Клиент отправляет запрос на установление соединения и что-то делает. Пока сервер обрабатывает запрос, клиент может делать что-то еще. После завершения операции событие завершения помещается в очередь в демультиплексоре событий, ожидая, когда Proactor (например, обработчик HTTP) отправит запрос назад и вызовет обработчик завершения (на клиенте). Эти термины используются в документе boost :: asio Шаблон проектирования Proactor: параллелизм без потоков .

Работая таким образом, асинхронная модель может принимать одновременные соединения без необходимости создания потока на соединение, что повышает общую производительность. Для достижения того же эффекта, что и в асинхронной модели, первая модель (синхронная) должна быть многопоточной. Для получения более подробной информации обратитесь к: Proactor Pattern (на самом деле я изучаю шаблон proactor, который используется для асинхронной модели из этого документа. Здесь приведено описание типичного веб-сервера синхронного ввода / вывода).

Правильно ли мое понимание предмета? Если это так, что означает, что асинхронный сервер может принимать запросы и возвращать результаты асинхронно (первый запрос на подключение, которому служба на веб-сервере не обязательно должна отвечать первым)? По сути, асинхронная модель не использует многопоточность (или многопоточность используется в отдельных компонентах, таких как компонент Proactor, Asynchronous Event Multiplexer (boost :: asio document)), а не при создании всего стека клиент-серверных приложений, который описан в многопоточной модели в документе Proactor Pattern, раздел 2.2 - Типичные ловушки и ловушки обычных моделей параллелизма ).

Answer 1

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

Абсолютные преимущества Proactor:

• Производительность повышена из-за задачи «аутсорсинг». Например, вы можете отправить запрос на разрешение в DNS и подождать 5 минут, пока ответ ничего не делает (Reactor) - или вы можете делать другие вещи во время ожидания (Proactor).

Абсолютные недостатки Proactor:

• Производительность снижается из-за переключения задач, что означает, что для одного сеанса вы выполняете больше кода (Proactor), чем должно быть (Reactor).

Но общая производительность обычно измеряется количеством «удовлетворенных» клиентов за период времени. Таким образом, преимущества Proactor по сравнению с Reactor зависят от ситуации. Вот несколько примеров.

1. HTTP-сервер . Клиент хочет увидеть что-то в своем окне браузера. Ему не нужно ждать, пока загрузится вся страница, чтобы увидеть первые фрагменты текста. Proactor эффективен, поскольку частичная загрузка страницы происходит быстрее, чем загрузка всей страницы. Тем не менее вся страница загружается примерно в то же время, что и в модели Reactor.

2. Игровой сервер с низкой задержкой . Клиент хочет получить полный результат своей команды как можно быстрее. Reactor эффективен, поскольку нет таких подзадач, как частичное чтение или запись - клиент ничего не увидит, пока не прочитает полный ответ. Таким образом, Reactor не будет делать дополнительных переключений между подзадачами, и в каждый момент он будет гарантировать, что какой-то клиент получит прогресс по его команде, в то время как Proactor заставит всех клиентов ждать друг друга в непредсказуемое время.

Многопоточность может дать вам линейное ускорение в обоих случаях.