[
https://issues.apache.org/jira/browse/HTTPCLIENT-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407150#comment-13407150
]
Oleg Kalnichevski commented on HTTPCLIENT-1213:
-----------------------------------------------
Ideally we should preserve full binary compatibility with the 4.2.x line, so
the protected method in question should be deprecated, not removed.
You can use 'mvn:clirr check' command to make sure your private copy is still
fully compatible with the 4.2 GA release.
Oleg
> performance issue with CachingHttpClient
> ----------------------------------------
>
> Key: HTTPCLIENT-1213
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1213
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Affects Versions: 4.2 Final
> Reporter: Sam Perman
> Fix For: 4.3 Final
>
> Attachments: httpclient-1213.patch
>
>
> We're using the CachingHttpClient and are seeing a spike in CPU usage when it
> is enabled. We've profiled our application and see that most of the time is
> being spent parsing dates. Specifically, it is trying to get the age of a
> cache entry on a cache hit by parsing the "Date" header on the
> HttpCacheEntry. I had a couple questions:
> 1) Why can't this use the responseDate value that lives on HttpCacheEntry?
> (This would avoid the overhead of parsing)
> 2) If it needs to parse, is it possible to remember the result on the
> HttpCacheEntry so it doesn't need to be parsed every time?
> We are using version 4.2
> Here is the full backtrace we are seeing:
> org.apache.http.impl.cookie.DateUtils.parseDate(String)
>
> org.apache.http.impl.client.cache.CacheValidityPolicy.getDateValue(HttpCacheEntry)
>
> org.apache.http.impl.client.cache.CacheValidityPolicy.getApparentAgeSecs(HttpCacheEntry)
>
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCorrectedReceivedAgeSecs(HttpCacheEntry)
>
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCorrectedInitialAgeSecs(HttpCacheEntry)
>
> org.apache.http.impl.client.cache.CacheValidityPolicy.getCurrentAgeSecs(HttpCacheEntry,
> Date)
> There are a couple callers to "getCorrectedAgeSecs":
> CacheValidityPolicy.isResponseFresh(HttpCacheEntry, Date)
> CachedResponseSuitabilityChecker.isFreshEnough(HttpCacheEntry, HttpRequest,
> Date)
> CachedResponseSuitabilityChecker.canCachedResponseBeUsed(HttpHost,
> HttpRequest, HttpCacheEntry, Date)
> CachingHttpClient.handleCacheHit(HttpHost, HttpRequest, HttpContext,
> HttpCacheEntry)
> CachedHttpResponseGenerator.generateResponse(HttpCacheEntry)
> CachingHttpClient.generateCachedResponse(HttpRequest, HttpContext,
> HttpCacheEntry, Date)
> CachingHttpClient.handleCacheHit(HttpHost, HttpRequest, HttpContext,
> HttpCacheEntry)
> Looking at the code, it looks like this section from
> CachingHttpClient.handleCacheHit will result in parsing the date twice
> (apologies if I'm misreading this)
> if (suitabilityChecker.canCachedResponseBeUsed(target, request, entry, now)) {
> return generateCachedResponse(request, context, entry, now);
> }
> Both the call to "canCachedResponseBeUsed" and the call to
> "generatedCachedResponse" will ultimately call "getCurrentAgeSecs" and parse
> the Date header.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
