Обрабатывать большое количество традиционных синхронных / блокирующих запросов клиентов HTTP с помощью нескольких потоков Java?

Question

Обрабатывать большое количество традиционных синхронных / блокирующих запросов клиентов HTTP с помощью нескольких потоков Java?

\b является границей слов.

Итак, \b аналогичен [^a-zA-Z0-9_], т. е. \b будет проверять что-либо, кроме word

. Вы можете вместо этого используйте это регулярное выражение

(?<=\s|^)[a-zA-Z]+(?=\s|$)
-------- --------- ------
   |         |       |->match only if the pattern is followed by a space(\s) or end of string/line($)
   |         |->pattern
   |->match only if the pattern is preceded by space(\s) or start of string\line(^)

-2

java spring multithreading http asynchronous

задан Zeruno 24 February 2019 в 02:43

1 ответ

Другие вопросы по тегам:

java spring multithreading http asynchronous

Похожие вопросы:

score 0 · Answer 1

Использование асинхронного HTTP-клиента недоступно - я не могу изменить свою клиентскую библиотеку HTTP.

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

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

Но оборотная сторона заключается в том, что запуск слишком большого количества одновременных HTTP-запросов может привести к перегрузке целевых служб и / или клиентских или серверных сетевых соединений. С этой точки зрения ограничение скорости на стороне клиента может быть хорошим .
Предположим, у меня есть 1000 запросов, которые будут отправлены прямо сейчас, каждый будет длиться 3-4 секунды, но только 4-5 доступных потоков выполнения для их отправки. Я хотел бы отправить их все одновременно, но это невозможно; если мне удастся отправить их ВСЕ в пределах 0,5 с или менее и обработать их запросы с помощью какого-либо обратного вызова или чего-то подобного, я бы посчитал это отличным решением. Но я не могу переключиться на асинхронный HTTP-клиент.

Единственный способ выполнить> N запросов одновременно с N потоками - это использовать асинхронный клиент. Период.

И "... обратный вызов или что-то в этом роде ..." . Эту функцию вы получите только с асинхронным клиентом. (Точнее, реальное асинхронное поведение можно получить только с помощью обратных вызовов, если под капотом есть настоящая асинхронная клиентская библиотека.)
Таким образом, решение похоже на отправку HTTP-запросов в ошеломляющий способ, то есть некоторая задержка между одним запросом и другим, где каждая задержка ограничена количеством доступных потоков? Если задержка между каждым запросом незначительна, я могу посчитать это приемлемым, но я предполагаю, что это будет довольно большая задержка между временем выполнения каждого потока, так как каждый поток должен ждать завершения друг друга (3-4 с) ? В таком случае это не то, что я хочу.

С моим предложенным обходным путем трудно определить задержку между любыми двумя запросами. Однако если вы одновременно пытаетесь отправить большое количество запросов и ждете всех ответов, задержка между отдельными запросами не имеет значения. Для этого сценария соответствующей мерой является время, необходимое для выполнения всех запросов. Если предположить, что больше ничего не отправляется исполнителю, время, необходимое для выполнения запросов, будет примерно равно:
 nos_requests * average_request_time / nos_worker_threads
Еще одна вещь, которую стоит отметить, - это то, что, если вам действительно удалось отправить огромное количество запросов одновременно, задержка сервера 3-4 с на запрос может увеличиваться . Сервер будет иметь возможность обрабатывать только определенное количество запросов в секунду. Если эта емкость будет превышена, запросы будут либо отложены, либо отброшены.

Но если нет других вариантов.

Полагаю, вы могли бы подумать об изменении API своего сервера, чтобы можно было отправлять несколько «запросов» в одном HTTP-запросе.

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

И с этим определенно есть проблема:

Другой разработчик программного обеспечения предоставил мне свой код, выполняющий синхронные вызовы HTTP, и отвечает за его обслуживание - он использует com.google.api.client. .http. Обновление его кода для использования асинхронного HTTP-клиента с обратным вызовом недоступно, и я не могу связаться с разработчиком, чтобы внести в него изменения.

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

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