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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

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

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

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

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

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