locked
CDN - Cache Control not really working for us???? RRS feed

  • Question

  • Hi there,
    We are expirencing some problems with our solution based on Azure Compute CDN and Im wondering if anyone could help me out
    solving our issues.

    Some background:
    - The solution we are building are in short serving custom tiles for a mapping solution.
    - The web site's users will come from Sweden.
    - We use Azure CDN compute for the tile requests since it gives us not only a great cache mechanics but will also "move"
    our web site physically closer to our customer in Sweden, Azure doesnt have a datacenter in Sweden but a CDN node is located
    in Stockholm Sweden, thus we have now also removed the network latency between Sweden and the datacenter located in Western Europe!

    Now to make our site performing even better we decided to write a script that will preload all of our tiles nightly so that all of our customers including the "early birds" will get the "pre generated" / cached version directly.
    The preload script sets the following http request headers:

    ***********************************************************
    http://ourdomainname.se/spatial/tiles/1/19/13/4487/2349
    Accept-Encoding: gzip,deflate,sdch
    Accept: application/json
    ***********************************************************

    And our server responds with:

    ***********************************************************
    HTTP/1.1 200 OK
    Cache-Control: public, max-age=46301
    Content-Length: 34345
    Content-Type: application/json
    Content-Encoding: gzip
    Server: Microsoft-IIS/7.5
    Access-Control-Allow-Origin: *
    X-Powered-By: ASP.NET
    Date: Tue, 22 Nov 2011 17:08:17 GMT
    Connection: keep-alive
    ***********************************************************

    Now despite that we are 100% sure that our preloading script has loaded a specific tile, when requesting the very same tile in a browser we dont get the cached version based on the following facts:

    1. The time it takes to load the tile.
    2. The HTTP header Expires are not present.
    3.  The HTTP header Age are not present.

    If we now make a second HTTP request for the very same tile in the browser we always get the cached version!
    (This fact must then mean free our application that it would set wrong cache control headers!)

    So the big question is why our tile preload scripts requests doenst work for us, why dont we get a cached version immediatley despite having preloaded a tile, why does two subsequent browser request give us the cached version?

    From our understanding and trials, Azure compute CDN differentiates http request not only URLs but also what value of the Http header "Accept-Encoding"(naturally). However this cant be the reason since we have assured that we send exactly the same value of this http header as our preloading script.

    What im currently wondering about is if the problem originates from different physical locations and the unicast protocol:

    The preloading script runs in the datacenter located in Western Europe, then I assume that the cached version will be stored in a node very close to this datacenter. Then, when i try to access the very same tile in my browser from my home in Copenhange maybe I get a response from the Node in Stockholm, which in turn would pull the content from another node? Could this be the reason?
    If true, why wouldnt we then see Age and Expires headers?

    If anyone could help us out it is of course very much appreciated, Microsoft perhaps?

    Regards
    Niclas Rothman

    PS

    Does anyone know were i can find any offical documentation which tells us which http headers that comput CDN differntiates on?

     

     


    Niclas
    Tuesday, November 22, 2011 6:34 PM

Answers

  • If you run your "precache" tool from the Western Europe datacenter, that tool runs on a system which is network-wise "close" to a CDN POP that is not the one in Sweden. Your tool thus warms the cache in that other POP but not the one in Sweden. That is precisely what you're seeing; the first request from Sweden is "slow", subsequent requests for the same tile issued from a client in Sweden are "fast".

    The CDN's Anycast DNS system ensures that requests are served by the CDN POP "closest" (fewest hops, according to BGP) to the client making the request. If you want to warm the cache in Sweden, you need to issue the requests from systems that are "closest" to our CDN POP in Sweden.

    Jason


    Jason Zions
    Wednesday, November 30, 2011 12:58 AM

All replies

  • Hi,

    Can you try to run the preloading script on your local machine, and then get the same tile from a browser? Or you can try to run the preloading script twice. This will help to identify if the problem is within the script, or if it's because the script was running on a remote machine so the cache was stored on a remote data center instead of a nearby data center.


    Please mark the replies as answers if they help or unmark if not.
    If you have any feedback about my replies, please contact msdnmg@microsoft.com.
    Microsoft One Code Framework
    Wednesday, November 23, 2011 6:28 AM
  • If you run your "precache" tool from the Western Europe datacenter, that tool runs on a system which is network-wise "close" to a CDN POP that is not the one in Sweden. Your tool thus warms the cache in that other POP but not the one in Sweden. That is precisely what you're seeing; the first request from Sweden is "slow", subsequent requests for the same tile issued from a client in Sweden are "fast".

    The CDN's Anycast DNS system ensures that requests are served by the CDN POP "closest" (fewest hops, according to BGP) to the client making the request. If you want to warm the cache in Sweden, you need to issue the requests from systems that are "closest" to our CDN POP in Sweden.

    Jason


    Jason Zions
    Wednesday, November 30, 2011 12:58 AM