On 12 October 2011 15:10, Jon Moore <[email protected]> wrote: > I think we are talking about the Via header that gets generated and > inserted by the caching layer, right?
Yes. > I think the proposed Map would > be fine, although I'm actually very confused about the times Vasile is > reporting. I believe (but I will double-check) that generating the Via > header is barely more complicated than a String.format(), so I'm not > sure why this is taking 8ms at all, let alone 3 seconds. This > definitely doesn't match my experience using the caching client. You are right, as I said previously my mid-night math was wrong. > > Vasile, can you share the code you're using to take the measurements? > I'd like to be able to reproduce this so we can understand what's > going on here. I simply took the System.nanoTime() values at the beginning and the end of the method and logged the difference. After that I accessed repeately the same cacheable resource from web (a small image). > > Thanks, > Jon > > On Wed, Oct 12, 2011 at 7:53 AM, Oleg Kalnichevski <[email protected]> wrote: >> On Tue, 2011-10-11 at 23:21 +0300, Vasile Alin wrote: >>> Since we handle a small number of protocols (such as HTTP and HTTPS >>> 1.0 and 1.1), we could cache generated Via headers in >>> CachingHttpClient. Each header takes around 3 seconds to create on my >>> machine - Win7 64 bit, AMD Turion X2 & 4Gb of RAM - (would be >>> interesting to find values for other platforms) and would worth >>> improving this area by caching generated Via headers by putting them >>> in a Map with a ProtocolVersion key. >>> >>> Tests show that having this cache in place reduces the time to >>> generate a Via header for each request from 3 seconds to 8 millis. >>> What do you think? >>> >>> Alin >>> >> >> Hi Alin >> >> Jon is the authority on the subject of HTTP caching, so his opinion will >> matter most. As far as I am concerned anything that can reduce execution >> time from 3000 to 8 ms is worth pursuing. As always the best way to get >> things done here at ASF is by raising a JIRA and submitting a patch. >> >> Cheers >> >> Oleg >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
