У нас есть приложение asp.net webapi, которое должно совершать множество звонков другим веб-приложениям (это в основном обратный прокси-сервер).Для этого мы используем асинхронные методы HttpClient.
Да, мы видели подсказки об использовании только одного экземпляра HttpClient, а не о его утилизации.
Да, мы виделисоветы по настройке значений конфигурации, особенно проблема с тайм-аутом аренды.В настоящее время мы устанавливаем ConnectionLimit = CPU * 12, ConnectionLeaseTimeout = 5 минут и MaxIdleTime = 30 с.
Мы можем видеть, что соединения ведут себя как нужно.Пропускная способность в нагрузочном тесте также была очень хорошей.Однако мы сталкиваемся с проблемами, когда иногда перестают работать соединения.Похоже, это происходит, когда поступает много запросов (и, будучи обратным прокси-сервером, вызывает новые запросы), и это происходит в основном (но не только) с самым медленным из всех серверных приложений.В таком случае поведение завершает запросы к этой конечной точке вечно, или они просто заканчиваются тайм-аутом.
IISReset сервера, на котором размещено наше приложение обратного прокси-сервера, устраняет проблемы (на некоторое время).
Мы уже исследовали несколько областей:
- Проблемы производительности удаленного веб-приложения: хотя он ведет себя именно так, как и в случае, если производительность хорошая, когда одни и те же запросы выдаются локальнона удаленном сервере.Кроме того, значения для ЦП / сети и т. Д. Являются низкими.
- Проблемы с сетью (пропускная способность, маршрутизатор, брандмауэр, балансировщики нагрузки): возможны, но довольно маловероятны, поскольку все остальное работает стабильно и наш анализатор также участвует в анализе.
- Истощение пула потоков: не невозможно, а скорее теоретически - конечно, у нас много асинхронных вызовов, но разве это не поможет в этом вопросе?
- HttpCompletionOption.ResponseHeadersRead: Не проблема сама по себе, но, возможно,одна часть головоломки?
Лучшее объяснение на данный момент сфокусировано на ConnectionLimit: мы начали устанавливать значения, упомянутые выше, только недавно, и это, кажется, вызвало проблемы.Но с чего бы это?Разве не должно быть улучшением повторное использование соединений вместо открытия нового для каждого запроса?И значения, которые мы устанавливаем, кажутся довольно консервативными?
Мы начали экспериментировать с этими значениями в последнее время, чтобы увидеть их влияние на производство.Тем не менее, нам до сих пор неясно, является ли это единственной причиной.И мы были бы признательны за более простой подход к анализу.К сожалению, дамп памяти и распечатки netstat больше не помогли.
Некоторые предложения о том, как анализировать или подсказки о возможных причинах, будут высоко оценены.
***** РЕДАКТИРОВАТЬ *****
Установка предела соединения на 1000 решает проблему!Таким образом, остается вопрос: почему это так?Из того, что мы знаем, ограничение по умолчанию составляет 2 в не-сети и 1000 в веб-приложении.MS предлагает значение по умолчанию CPU * 12 (но они не реализовали его таким образом ?!), поэтому наше изменение должно было в основном перейти с 1000 на 48. Тем не менее мы можем видеть, что открыты только несколько соединений.Есть ли кто-нибудь, кто может пролить свет на это?Каково точное поведение при открытии новых соединений, повторном использовании существующих, конвейерной обработке и т. Д.?Есть ли для этого источник информации?