HttpResponseCache slow down UrlConnection

[andi78]

in simulator with "slow" file system access and mobile devices with bad file system performance:
A simple http get download is slower when HttpResponseCache is enabled.

URLConnection con = url.openConnection();
...
InputStream is = (InputStream) con.getContent();

i suppose HttpResponseCache store it on filesystem before the app is allowed to access the inputstream.

in my opinion this library should only be used if you expect high cache hit ratio.

Our service used "Etag" and "If Modified Since" headers. (for instance for images with size of about 15kb)
With enabled HttpResponseCache it was noticeable slower (with 304-not modified header) than regular urlConnection without caching at all.

[candrews]

Your testing is very different from what would be experienced in the real world.

In the real world:

• storage read/write access may be slow (compared to "normal" computing standards), but it's still faster than the emulator.
• Mobile devices have unreliable network access. So if you can cache something locally, you don't need to use the network at all - so the user won't see an error if the network is down - the app continues to work.
• Mobile network access is slow - I bet that the incredibly slow mobile network is slower than the storage, so caching wins.
• Mobile network access is metered - so using less bandwidth means the user doesn't hit their limit as fast, making them happier users of your app.

With that said, I'd be really psyched if you looked through the code and took a look at ways to make it faster. Even if you just submit ideas, that would be pretty great - a patch / merge request would be even better.

[jaypatrickhoward]

I just integrated the cache into my app, which serially pulls down about 20 images at launch (while showing a splash screen) before allowing the user to do anything and stores them in an in-memory cache. I then tested performance on a Samsung Galaxy Nexus using both the built-in ICS HttpResponseCache and your port. The performance was roughly the same between the two; if anything your port performed a little better. But that's the good news. The bad news:

• Time to load with no HttpResponseCache installed: ~7 sec
• Time to load with HttpResponseCache installed and populated: ~1 sec
• Time to load with HttpResponseCache installed but empty: ~33 sec

Is this huge disparity between "empty cache" and "no cache at all" merely caused by the general slowness of writing to internal storage? Or is something else going on?

It is not, at least, an issue with your port per se since the ICS-provided HttpResponseCache also exhibits the poor behavior. Maybe what's needed is some delayed write functionality so the caller doesn't have to wait for the requested data to be fully cached before it's made available to him?

[iNoles]

If you turn on StrictMode, you will see violation for HttpResponseCache installed. It will be very wise to put HttpResponseCache installed under AsyncTask.

[jaypatrickhoward]

I started my timing at the point when I began loading the images, not when I installed the cache.

Is the install process maybe "lazy", i.e. it only does the work when you first use a HttpURLConnection that has caching turned on?

[jaypatrickhoward]

Applying the patch in issue #9 solved the performance issues I described above. What it implies, however, that app developers should prefer to use candrews's HttpResponseCache even on ICS since the stock version that ships with ICS doesn't have the patch to fix the unreasonably slow performance when writing to cache.

[candrews]

I added a note to the README.md that this library may be a later version that one included in Android on the target, so developer may want to use it unconditionally. See 59e8ed9