Saturday, June 14, 2008

Reviewing events from the System.Net.Cache source

The previous entry was on typical output of System.Net and System.Net.Sockets trace sources.

Lets try to retrieve some image twice and see how caching is going to help us. We need first to enable caching as it is disabled by default:

  <system.net>
    <requestCaching defaultPolicyLevel="Default">
    </requestCaching>
  </system.net>

More info on caching configuration here: http://msdn.microsoft.com/en-us/library/6szcd7yh.aspx

Upon first HttpWebRequest, cache key is checked and not found:

image

Whole image is read then using System.Net.Sockets.
After System.Net.Sockets completes reading a response from our first request, System.Net.Cache evaluates if it is "worth it" to cache:

image

If it is, like in our case, it copies the contents of response to the cache. As already mentioned in few blogs, System.Net.Cache uses IE cache, which is why we can see reference to the local profile directory in the above log. As of this writing it means that having a profile for the app user is required, read more here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=263447&wa=wsignin1.0 and original here.

Upon second request for the same image, no network communication is taking place because cache is first consulted for the key presence:

image

And then for the cache item not being stale:

image

After those checks image is read from the cache, no work for the System.Net.Sockets required!

No comments: