Apache HttpClient и HttpConnection в многопоточном приложении

В настоящее время я использую один PoolingHttpClientConnectionManager и HttpClientBuilder.setConnectionManager(connectionManager).build() для каждого запроса.

Создание нового HttpClient для каждого запроса — огромная трата времени. Вы должны использовать HttpClient для каждой конфигурации (каждый клиент может иметь свой диспетчер соединений, максимальное количество одновременных запросов и т. д.) или для каждого независимого модуля вашего приложения (чтобы не создавать зависимости между независимыми модулями).

Также не забывайте, что .build() возвращает CloseableHttpClient, что означает, что вы должны вызывать httpClient.close(), когда закончите его использовать, иначе вы можете утечь ресурсы.

Обновление в ответ на комментарий от @Nati:

что будет "впустую"? Является ли HttpClient тяжелым объектом?

http://grepcode.com/file/repo1.maven.org/maven2/org.apache.httpcomponents/httpclient/4.3.1/org/apache/http/impl/client/HttpClientBuilder.java?av=f#693 Как вы можете видеть, это много кода, и его бессмысленно выполнять при каждом запросе. Это ненужное потребляет процессор и создает много мусора, который снижает производительность всего приложения. Чем меньше выделений вы сделаете - тем лучше! Другими словами, никаких преимуществ от создания нового клиента для каждого запроса — только недостатки.

имеет ли смысл хранить его как bean-компонент на протяжении всего срока службы приложения?

ИМХО да, если только не используется очень (очень) редко.

отношение между HttpConnection и HttpClient

Каждый http-клиент может выполнять несколько http-запросов. Каждый запрос выполняется в контексте клиента (его конфигурация - т.е. прокси, параллелизм, поддержка активности и т.д.) Каждый ответ на запрос должен быть закрыт (reset(), close(), точное название не помню ), чтобы освободить соединение, чтобы его можно было повторно использовать для другого запроса.

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

Я согласен с @Michael Gantman в том, что не исправлю это.

Я бы сказал, что исправление или неисправление зависит от вашего профиля нагрузки.

Сохранять или не поддерживать связи?

Например, если вы отправляете 300 запросов сразу на 10 серверов, а после этого в течение часа ничего не делаете, то с точки зрения ресурсов нет смысла держать какие-либо TCP/IP-соединения. открывается (из-за использования HTTP/1.1) на целый час.

Однако, если вы разговариваете с сервером каждые 5 секунд, вы можете оставить соединение открытым. Кроме того, если вы хотите свести к минимуму задержки, устраняя многократное установление соединения, вы можете рассмотреть возможность сохранения соединений открытыми.

Для этого вы должны использовать HTTP/1.1. Вы можете найти множество примеров, например. DefaultHttpClient поддерживает соединение при нескольких запросах

Сколько связей сохранить?

Опять же, зависит от вашего профиля нагрузки. Вы сказали, что у вас есть 10 серверов. Если вы отправляете данные для одного сервера последовательно, то одного http-соединения на сервер с http/1.1 вполне достаточно. Однако, если вы хотите сделать что-то более быстрое (например, загрузить два изображения параллельно), вы можете открыть несколько соединений с одним и тем же сервером. (Конечно, это означает, что ваше приложение действительно многопоточное.)

Заключение

Если это не критичное по времени приложение, проще всего ничего не объединять, а просто обращаться к серверам, когда у вас есть данные для отправки. Вы можете начать чрезмерно оптимизировать это и бороться за 10 мс улучшения ценой серьезной случайной сложности.

В заголовке HTTP 1.0 вашего клиентского запроса вам нужно

Connection: keep-alive

Однако это всего лишь запрос, и сервер, к которому вы подключаетесь, может в любом случае разорвать соединение.

HTTP 1.1 предоставляет эту функциональность по умолчанию, но время ожидания по умолчанию довольно короткое. Возможно, там есть какая-то конфигурация. В любом случае, если вы получите ответ с Connection: close в заголовке, вы должны закрыть соединение.

Дополнительные сведения см. в разделе rfc2616, особенно в разделе 8 "Постоянные подключения".

Таким образом, казалось бы, что правильно сделать, это обеспечить обработку HTTP 1.1 (соединения по умолчанию остаются открытыми с 1.1) и не делать ничего «особенного» с HttpClient. Согласно второму и третьему разделам главной страницы HttpClient, по умолчанию клиент будет удерживать постоянное соединение как можно дольше.

Мои рекомендации заключаются в том, чтобы (при добавлении подпрограммы/потока/контроллера на стороне клиентского соединения) все связанные подключения к определенному серверу/порту упорядочивались в одной и той же области (все в одном потоке или упорядочены в том же порядке), это вероятно, уменьшит вероятность того, что вы столкнетесь с логикой закрытия соединения; но вы не можете заставить соединение оставаться открытым (по очевидным причинам).