[
https://issues.apache.org/jira/browse/HTTPCLIENT-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob updated HTTPCLIENT-2323:
----------------------------
Description:
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.
was:
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 stack trace. 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.
> 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
> Environment: Docker image using maven:3.9.1-eclipse-temurin-17-focal
> running in kubernetes
> 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
