[
https://issues.apache.org/jira/browse/HTTPCLIENT-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822021#comment-17822021
]
Rob edited comment on HTTPCLIENT-2323 at 2/29/24 9:13 AM:
----------------------------------------------------------
[~olegk]
Look at this line in the code you posted:
{code:java}
CloseableHttpClient httpclient =
HttpClients.custom().setConnectionManager(cm)...{code}
Do you think this should be called once per application run... or multiple
times? I am saying you need to call it multiple times in order to alter the
connection pool settings. Are you saying you can call that once and never call
it again while still altering the connection pool used?
I agree with you... i dont see what you are thinking is so clear. Maybe post
code that shows how you can do this with a singleton CloseableHttpClient? The
basic example you posted doesnt show that in any way.
Besides this particular point... is it truly the ideal design for the apache
http client to resort to the classloader to determine a default user agent? Can
this not be calculated once? Or in less resource-intensive way? Are we losing
something by rethinking this code?
was (Author: winstonwaite):
[~olegk]
Look at this line in the code you posted:
HttpClients.custom().setConnectionManager(cm)...
Do you think this should be called once per application run... or multiple
times? I am saying you need to call it multiple times in order to alter the
connection pool settings. Are you saying you can call that once and never call
it again while still altering the connection pool used?
I agree with you... i dont see what you are thinking is so clear. Maybe post
code that shows how you can do this with a singleton CloseableHttpClient? The
basic example you posted doesnt show that in any way.
Besides this particular point... is it truly the ideal design for the apache
http client to resort to the classloader to determine a default user agent? Can
this not be calculated once? Or in less resource-intensive way? Are we losing
something by rethinking this code?
> 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
