Support: 1-800-961-4454
Sales Chat
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
25 Comments

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

avatar Hire Khambhayta on April 2, 2011 | Reply

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?

avatar Seb on April 5, 2011 | Reply

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.

avatar Megan Wohlford on April 5, 2011 | Reply

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

avatar Seb on April 6, 2011 | Reply

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)?

avatar Ryan Williams on April 7, 2011 | Reply

[…] uploads so now companies can store videos, HD movies, very large backup files, etc. •    Extended TTL– TTL or Time to Live has increased from 72 hours to 50 […]

avatar Rackspace Cloud Computing & Hosting on April 27, 2011 | Reply

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.

avatar Lags on May 19, 2011 | Reply

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.

avatar Lags on May 19, 2011 | Reply

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/

avatar Frenky on July 4, 2011 | Reply

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

avatar Andrew on August 8, 2011 | Reply

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

avatar Mattias on August 11, 2011 | Reply

“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…

avatar Jay Thompson on August 12, 2011 | Reply

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!

avatar Henlow on September 8, 2011 | Reply

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

avatar Steve on September 13, 2011 | Reply

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.

avatar Mike on October 8, 2011 | Reply

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

Thanks,
-Dan

avatar Dan Grec on October 14, 2011 | Reply

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

avatar Jools on December 15, 2011 | Reply

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.

avatar Mas on March 11, 2012 | Reply

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

avatar ByBe on March 12, 2012 | Reply

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!!

avatar Alex on March 12, 2012 | Reply

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!!

avatar Dan on March 26, 2012 | Reply

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!!

avatar Matt on April 2, 2012 | Reply

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.

avatar Megan Wohlford on April 20, 2012 | Reply

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?

avatar Ben on September 28, 2012 | Reply

Leave a New Comment

(Required)


Racker Powered
©2014 Rackspace, US Inc.