Могут ли высокие значения времени ожидания HTTP вызывать какие-либо проблемы - PullRequest
Новая
       85

Могут ли высокие значения времени ожидания HTTP вызывать какие-либо проблемы

1 голос
/ 05 мая 2020

У меня есть приложение SpringBoot, размещенное на OpenShift-Enterprise. У меня есть один запрос, обработка которого занимает значительно больше времени из-за интеграции с другими системами. Этот запрос начал получать ошибку 504 Gateway timeout в браузере ровно через 30 секунд.

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

defaults
    timeout connect 10s
    timeout client 30s
    timeout server 30s
    log global
    mode http
    option httplog
    maxconn 3000

Теперь мы исправили проблему, увеличив это значение до некоторого большого числа. Но DevOps опасается, что это может привести к проблеме устаревшего соединения. Я не нашел никаких ресурсов, подтверждающих, что большое значение тайм-аутов HTTP может привести к таким проблемам. Мы хотим перенести новую конфигурацию в рабочую среду.

Есть мысли?

1 Ответ

1 голос
/ 06 мая 2020

Что беспокоит вашу команду DevOps по поводу "Stale Connection"? По моему опыту, «устаревшее соединение» может возникать из-за проблемы переполнения одновременного сеанса на LB или точке входа (например, HAProxy), если в течение определенного вами настроенного тайм-аута осуществляется доступ к тонне запросов. Если ваша команда также обеспокоена этим риском, вам следует разделить путь доступа для определенного процесса, требующего длительного времени, если вы не исправите длительный процесс, чтобы он был более коротким.

Например, только один маршрут для длительный процесс может настроить указанный c тайм-аут с помощью аннотации "haproxy.router.openshift.io/timeout". См. " Route-specifici c Annotations для получения дополнительных сведений об аннотациях.

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

...