[
https://issues.apache.org/jira/browse/HTTPCLIENT-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822084#comment-17822084
]
Oleg Kalnichevski commented on HTTPCLIENT-2323:
-----------------------------------------------
[~winstonwaite] HttpClient version 4 and version 5 have been intentionally
designed so that HttpClient instances need to be created very rarely, most once
per application lifetime and then repeatedly re-used. Pretty much _each_ and
_every_ aspect of the library can be overwritten either on a per route
(connection manager level) or on a per request (HttpContext level) with a very
few notable exceptions. Do note though that not every parameter makes sense at
the request level. For instance, connect timeout is applicable to the route
level only. It is not applicable at the request level. Socket timeout _can_ be
overwritten at the request level via HttpContext.
What you are doing is _wasteful_ and _inefficient_ per design and a tweak to
the library is not going to change that.
Oleg
> When using HttpClientBuilder without setting a user agent an expensive
> operation seems to be used
> -------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2323
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2323
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient (classic)
> Affects Versions: 4.5.12, 5.3.1
> Environment: Docker image using maven:3.9.1-eclipse-temurin-17-focal
> running in kubernetes. Spring boot 2.7.x.
> Reporter: Rob
> Priority: Minor
> Attachments: Screenshot 2024-02-28 at 12.51.41 PM.png
>
>
> We have an application that has a fairly high outbound http call rate using
> Apache Http Client. We have been profiling it recently using the async
> profiler and I noticed that almost 10% of our cpu time is spent in
> VersionInfo.getUserAgent.
> We use HttpClientBuilder for each call (this seems the correct way to be able
> to use different connection pools and settings).
> I am guessing because we do not explicitly set the user agent that the client
> will go determine the client version and java version and use this... the
> automatically generated user agent in our case looks like:
> {code:java}
> User-Agent: Apache-HttpClient/4.5.12 (Java/17.0.7){code}
> I have attached the profiler flame graph. I would imagine something like this
> could be checked once and used for any further calls. I have not tested it
> yet but I am hoping a workaround would be to make sure to set a user agent
> and then none of this classloader stuff would need to happen for each call.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
