Высокое время отклика по сравнению с очередями - PullRequest
1 голос
/ 12 апреля 2019

Скажем, у меня есть webserivce, который используется внутри других веб-сервисов со средним временем ответа 1 минута.Каковы плюсы и минусы такого сервиса с «синхронными» ответами по сравнению с тем, что сервис возвращает идентификатор запроса, обрабатывает его в фоновом режиме и заставляет клиентов опрашивать результаты?

Есть ли минусы в HTTPсоединения, которые остаются активными более одной минуты?Сохраняет ли значение TCP значение по умолчанию здесь?

Ответы [ 3 ]

0 голосов
/ 12 апреля 2019

Если вы заставляете пользователя ждать, пока ваше долгое задание выполняется на сервере, вы ожидаете установления ценного HTTP-соединения во время ожидания.

Рекомендуется с точки зрения RestFul отвечать HTTP 202 (Принят) и возвращать ответ со ссылкой на опрос.

Если вы хотите повесить клиент во время ожидания, вы должны установить тайм-аут запроса на стороне клиента.

Если между вами есть несколько брандмауэров, это может привести к разрыву соединений, если они какое-то время неактивны.

0 голосов
/ 14 апреля 2019

Более высокая скорость отклика

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

Больше памяти

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

Более устойчиво к сбою сервера

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

0 голосов
/ 12 апреля 2019

В зависимости от вашего приложения это может иметь значение. Несколько вещей, о которых стоит упомянуть:

Протокол HTTP синхронизируется

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

Гнезда

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

Сетевое подключение

Поддерживать HTTP-соединение в течение долгого времени не рекомендуется. Что если вы потеряете сеть частично или полностью? ваш http-запрос будет прерван, и вы вообще не будете знать его статус.

Имея в виду все эти вещи, лучше планировать долгосрочные задачи в фоновом режиме.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...