In my last post I outlined a mechanism to provide some flexibility in updating web site content while by keeping those resources in Azure Storage, but reducing the per transaction costs associated with Azure Storage by caching the resources locally in Local Storage of a WebRole. I did a quick test with my harness being serving content via four different means:
- Directly from Azure Storage
- From WebRole Local Storage via Response.WriteFile()
- From WebRole Local Storage via Response.BinaryWrite()
- From WebRole Local Storage via Response.TransmitFile()
There are different reasons to consider using each of these and a lot of that consideration has to do with size of the content being served. For example, if I want to serve a 3 MB (for that matter a 30 MB) video I might consider using direct access to Azure Storage as the additional tenth of a second really won’t make a difference in the long run. However, if I want to ensure scale across multiple WebRoles for a video file of substantial size, but small enough for WebRole Local Storage to still be a viable option then I would want to use TransmitFile instead of WriteFile() due to the fact that it skips buffering when using TransmitFile.
With that bit of preamble, here are the results of my test as the average time to serve the 15k png:
|Directly from storage||0.13510 sec|
|BinaryWrite first request removed||0.00361 sec|
If you’ll note the two entries for BinaryWrite there was a 13 second response on the first request made to the BinaryWrite method. Discounting this response we get the second average. Note that for all of the methods that are implemented using the HttpModule the response time either rounds up or down to approximately 0.004 seconds.