веб-клиент менее 3 секунд ответа или 45 секунд - PullRequest
Новая
       33

веб-клиент менее 3 секунд ответа или 45 секунд

1 голос
/ 17 марта 2020

У меня есть очень базовое c приложение с весенней загрузкой 2.2.4, которое запрашивает нижестоящую систему, используя веб-клиент с блокирующим вызовом. Я не делаю никакой настройки веб-клиента (установка тайм-аутов и т. Д. c.), Просто использую его «из коробки».

Я обнаружил, что время ответа на вызов веб-клиента либо ниже 3 секунд или точно 45 секунд , что я нахожу очень странным. Почему, если ответ медленный, это всегда 45 секунд?

Единственная ссылка на 45 секунд, которую я могу найти, содержится в документации Reactor Netty:

4,6. Пул подключений

По умолчанию клиент TCP использует «фиксированный» пул подключений, в котором максимальное число каналов составляет 500, а в качестве времени ожидания - 45 с. Это означает, что реализация создает новый канал, если кто-то пытается получить канал, но ни один не находится в пуле. Когда достигнуто максимальное количество каналов в пуле, новые попытки получить канал задерживаются до тех пор, пока канал не будет снова возвращен в пул. Реализация использует порядок FIFO для каналов в пуле. По умолчанию для каналов в пуле не указано время простоя.

Есть ли у кого-нибудь какие-либо предположения о том, почему мои медленные вызовы веб-клиента всегда выполняются за 45 секунд?

Ответы [ 3 ]

0 голосов
/ 17 марта 2020

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

  1. Вы пытаетесь соединиться с доменным именем, поэтому клиент сначала вызывает DNS получить адрес;
  2. DNS возвращает записи адресов как для IPv4, так и для IPv6
  3. Клиент сначала пытается IPv6, но IPv6 не настроен в сети должным образом, и после IPv6 происходит сбой время ожидания соединения , которое может находиться в диапазоне 45 с.
  4. Затем клиент пытается выполнить IPv4, что успешно.

То, произойдет ли это с вами, зависит от вашей ОС + версия, ваша java версия и конфигурация вашей сети.

Попробуйте подключиться с использованием IP-адреса IPv4, например http://192.168.10.1/the/rest. Если это всегда быстро, то у вас, вероятно, была проблема, как указано выше. К сожалению, вы обычно не можете подключиться таким образом с HTTPS, но в зависимости от вашей операционной системы вы можете попробовать ввести правильный адрес v4 в /etc/hosts.

Подробнее здесь: https://serverfault.com/questions/548777/how-to-prevent-delays-associated-with-ipv6-aaaa-records

0 голосов
/ 18 марта 2020

Я думаю, что это связано с проблемой нетто:

https://github.com/reactor/reactor-netty/issues/1012

Сейчас я сначала посмотрю на это.

Спасибо за все ответы!

0 голосов
/ 17 марта 2020

Это происходит из-за фиксированного размера пула, равного 500. Если все эти соединения (каналы) в настоящее время используются существующими запросами, новый запрос на соединение будет поставлен в очередь, пока одно из 500 соединений не станет свободным. Если WebClient не может установить соединение в течение 45 секунд для нового запроса (поскольку все 500 каналов по-прежнему заблокированы существующими запросами), происходит сбой с исключением AcquireTimeout. Я предполагаю, что те, которые закончили до 3 секунд, являются успешными, а 45 секунд - неудачными. В зависимости от пропускной способности вашего приложения вы можете соответствующим образом настроить размер пула.

...