Support: 1-800-961-4454
1-800-961-2888

Extending TTL for Cloud Files CDN Users

25

Our users have spoken and we have heard loud and clear! We have extended our limits for TTL (Time to Live) for objects on the content delivery network (CDN).  We have moved our limit up from 72 hours to 50 years.

TTL is a limit that you can set on how long you would like your CDN content to “live” on the CDN edge servers.  Once your TTL expires, the edge server checks back with the origin for a new copy of your object.  If your data rarely changes, you can set a longer TTL so the CDN edge server won’t check back with the origin as often resulting in faster response times for your end users.

That being said, the CDN’s edge servers always operate on the logic that the most popular content will stay cached.  That means if your content is less popular, but you have set a 50 year TTL, it won’t necessarily be 50 years before the edge server has to come back to the origin in Cloud Files for your object.

Simply think of TTL as the longest possible time that your content will go without being updated or requested again from the origin.

While we are changing our upper limits, we will still keep our default of a 72 hour TTL.  That means that if you take no action, your set up will remain exactly as it is today.  If you are using our API, you can now set your TTL anywhere from 15 minutes to 50 years, with increments as low as seconds (e.g. TTL = 26 minutes, 30 seconds).  This feature is coming soon within our Cloud Control Panel and will allow users to set their TTL up to 50 years, in hourly increments.

If you have any questions, comments, or concerns about this feature, please let us know.

About the Author

This is a post written and contributed by Megan Wohlford.


More
  • http://www.swastiksolutions.in Hire Khambhayta

    Thanks,
    It was lacking as the ttl was max of upto some 3 days only.
    Thanks for great supporting step.

  • Seb

    Great news – I just signed up and my first thought was “what the hell, 72hrs max? I’m outta here”.

    Any idea when it’ll be available in the control panel, as I’ve not delved into the API yet?

  • http://rackspace.com/cloud Megan Wohlford

    Great to hear that you are both excited about our news!

    Seb- We’re working on the Control Panel integration, but we’re not close enough for me to give exact dates yet. I’ll update this blog post as soon as we roll it out.

  • Seb

    Does this apply to rackspace UK as well as rackspace US?

  • Ryan Williams

    I have to admit I’m still not entirely getting this concept. As I understand it:

    1. Files are uploaded to Cloud Files’ central server(s)
    2. If someone accesses my file from Amsterdam, the closest edge server to that person will get the file from the central server and then server it to the user
    3. For 72 hours by default the edge server will serve the file if someone accesses it from the same location
    3. After 72 hours both the edge servers will scrap their versions of the file and re-download it from the central server(s) WHEN ACCESSED

    Anyone know what kind of speed we’re looking at for someone to get a file via the edge server when it’s not already cached on the edge server? Is it still quicker than someone accessing it directly from the original web server (assuming both Rackspace’s central server and my web server are in London for example)?

  • Pingback: Rackspace Cloud Computing & Hosting

  • Lags

    Being able to increase the TTL is good and all, and I appreciate that. However, I don’t really think this fixes many of the potential issues regarding Expires and Cache-Control headers…

    Example scenario:

    I have site.css in Cloud Files,
    I want it to have a far future expiry so people don’t need to request it often,
    so I update the TTL to something longish, say one year.

    Then one day I need to update the site.css, so I upload and overwrite site.css with my updated file.
    Then I need to force browsers to request the file even if they have it in their caches, so I do (as many people do) and append a version number to the end of the url, eg: site.css?v=2

    Now with the updated file uploaded, and my css url modified browsers should request the new file!

    BUT, the TTL I set in the beginning doesn’t just set the Expires headers it also sets the actual TTL for the edge servers, so forcing the browser to get the latest version of a file will only get the latest version on the edge server, not the actual updated file in Cloud Files.. that won’t happen until the edge servers update (ie. a year later, or something).

    TTL is good and all for the edge server’s own use, but the Expires and Cache-Control headers need to be adjustable independently from the TTL.

    Hopefully there are plans to remedy this, it’s a fairly significant issue in my view.

  • Lags

    Well, guess I should have done some more research… I just happened to come across this little bit of information regarding how to purge data from the edge servers:

    http://www.rackspace.com/cloud/blog/2011/02/25/cloud-files-cdn-gets-edge-purge/

    So, problem solved. ;) Thanks.

  • http://html-color-codes.info/ Frenky

    For all of those who would like to use far future expire headers in Cloud Files I have written this article: http://blog.html-color-codes.info/2011/06/how-to-set-far-future-expire-headers-on-rackspace-cdn/

  • Andrew

    Pretty ridiculous that this still isn’t available via the Cloud Manager GUI.

  • Mattias

    Great new!
    But as many others, I’m also wondering when this will show up in the web control panel.

  • http://www.phoenixrealestateguy.com Jay Thompson

    “This feature is coming soon within our Cloud Control Panel and will allow users to set their TTL up to 50 years, in hourly increments.”

    Can you define “soon”? This was written almost five months ago…

  • http://www.bbgun-shop.co.uk Henlow

    Hurry Up!

    I have had a running support ticket open with this for over 10 days. Bugs me that my managed hosting team doesn’t have a definitive answer on this yet.

    Frenky’s article is certainly promising, but for low level developers it really deserves more clarity.

    Again I will say it Hurry Up!

  • http://www.bbgun-shop.co.uk Henlow
  • http://abcya.com/ Steve

    The extended TTL feature is still not in the control panel. Can we have an update?

  • http://www.headfonia.com Mike

    Also looking to get an update on this. I talked to the support staff just now and he told me to go read the API guides to set the TTL time for longer than 72 hours. So much for a company that prides itself in customer service.

  • http://theroadchoseme.com Dan Grec

    Looking for updated TTL in the cpanel – when will it be ready?

    Thanks,
    -Dan

  • http://scryb.es Jools

    Also wondering when this feature will be added to the control panel?

  • Mas

    After 1 year … still nothing, TTL remains at 72 hours in Control Panel. The “Fanatic Support” “heard loud and clear” and this was all. Probably, this will never change, because with a TTL of 50 years … RackSpace will earn less money than with 72 hours.

  • ByBe

    TUT can be found here explaining how you can use SSH to change the TTL settings.

    http://www.bybe.net/blog/how-to-fix-rackspace-file-cloud-leverage-browser-caching-via-api-ssh.html

  • Alex

    almost a year since this blog post and still it’s not possible to set a TTL higher than 72 hours via the control panel – what’s going on??

    megan @ rackspace please give us an update!

    i’m not clever enough to use the API to do this!!

  • Dan

    I would like to add my name to the list of people who think it’s totally weak that we cannot set the TTL past 72 hours using the web, nor with the iPhone app, a year after Rackspace promised this feature was “coming soon”. HEAR US RACKSPACE!!

  • Matt

    Does someone have a video of how to do this. I wouldn’t know the first thing about using API. Or has someone created a webpage where you can put in your API key and set the TTL from there. That would be cool!!

  • http://www.rackspace.com/cloud Megan Wohlford

    All-
    I sincerely apologize that it took us so long to get this feature put into the control panel. However, I am happy to inform you that users can now set their TTL in the control panel up to 50 years. Let me know if you have any questions.

  • http://benipsen.com Ben

    For me the issue is on the lower end of TTL. When a user uploads a new version of an asset, they expect to be able to download the result immediately as I can provide with Amazon S3. I’ve had to abandon Cloud Files for this reason, however given Amazon’s outage record (west coast is down today) I would love to come back… The edge purge seems like a reasonable start but word on the street is there is a 25 request per day (not going to work for me) and still some lag time. What are the chances you’ll ofter a more realtime solution in the future?

Racker Powered
©2014 Rackspace, US Inc.