hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1213) performance issue with CachingHttpClient
Date Thu, 05 Jul 2012 14:13:34 GMT

    [ 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.

> 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,
> There are a couple callers to "getCorrectedAgeSecs":
> CacheValidityPolicy.isResponseFresh(HttpCacheEntry, Date)
>   CachedResponseSuitabilityChecker.isFreshEnough(HttpCacheEntry, HttpRequest, Date)
>     CachedResponseSuitabilityChecker.canCachedResponseBeUsed(HttpHost, HttpRequest, HttpCacheEntry,
>       CachingHttpClient.handleCacheHit(HttpHost, HttpRequest, HttpContext, HttpCacheEntry)
> CachedHttpResponseGenerator.generateResponse(HttpCacheEntry)
>   CachingHttpClient.generateCachedResponse(HttpRequest, HttpContext, HttpCacheEntry,
>     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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message