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

What is the TTL attribute for a Cloud Files container?


NOTE: This article is written for our First-Generation Cloud Control Panel. A version of this article is also available for our Next-Generation Cloud Control Panel.

All container in Cloud Files have an attribute called TTL (Time to Live). The attribute and its value can be viewed / modified in the CDN and Metadata section of the Cloud Files user interface (shown below).

cfttl.jpg

 

  • The TTL is the time interval after which the CDN will reread the contents of the container.
  • This time interval can be viewed / modified / stored as number of days using the up/down arrow in the CDN & Metadata pane.
  • After modifying the number of days by using the up/down arrows user must press the "Apply TTL" button. The new value will take effect after the current TTL cycle is completed.
  • The TTL option in the control panel can accept values between 1 hour and 50 years. Higher numbers should be used for static content which does not change often.  If you require a longer TTL, see this blog post on using the API to set TTL as low as 15 minutes.
  • Smaller numbers should be used if the content changes more often.


© 2011-2013 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


See license specifics and DISCLAIMER

11 Comments

The TTL setting accepts a maximum value of 72 hours, yet most performance optimisation experts suggest caching static content for weeks if not months. Is there any way to increase this?

The content will continue to be cached after 72 hours. The "TTL" value specifies how often the CDN will check for a change or removal of the file. With a TTL of 72 hours, then, it means that the CDN will poll the file to check for any changes every 72 hours. If it doesn't find a change then the CDN continues to serve the cached copy.

To add to, and correct, my previous comment: It looks like the actual limit on the TTL was extended to 50 years a few months back, but only through the API. I'll add a link to the blog post explaining the change in the article:

http://www.rackspace.com/cloud/blog/2011/03/31/extending-ttl-for-cloud-files-cdn-users/

Is there any way to add expires HTTP headers to the content served from the CDN?

As I understand it, setting the TTL on a container will also set the expires header on its content to the same length of time.

You mentioned that, "This will reduce bandwidth charges to the account". But the pricing section of "Cloud Files" states that "When files are requested over the CDN, there are no request/operation charges and no bandwidth charges from Cloud Files to the CDN." Doesn't it mean that every time the CDN edges receive updates (on every TTL), it won't charge money? Please clear my confusion on this regard.

Thank you.

Hello Mohammad,
The sentence that you referred to which mentions reducing bandwidth charges was written for the article during a time when we were still charging for both inbound and outbound bandwidth. The 'savings' mentioned would have applied to less frequent updates to Cloud Files (inbound). Now that we no longer charge for inbound bandwidth (only outbound) that sentence no longer applies to Cloud Files, and has been removed from the article.

You can also find some more updated material on using Cloud Files in the following article:
http://www.rackspace.com/knowledge_center/content/best-practices-using-cloud-files

Please let us know if you have any more questions, or if there is anything else we can help you with.
Thank you!

I write a short TUT explaining how people can use SSH to extend the 72 hour control panel limit of TTL to upto 50 years with the API

Tutorial can be found here
<a href="http://www.bybe.net/blog/how-to-fix-rackspace-file-cloud-leverage-browser-caching-via-api-ssh.html">Rackspace File Cloud Leverage Browser Caching</a>

Tut wouldn't of been possible without the helpfulness of the Rackspace Team, Thanks for the on going support you provide my company.

Hello Bybe!
Thanks for the feedback and for crafting that excellent tutorial on using cURL for issuing commands through the API! I'm sorry it took so long to get the information that you were looking for through our support staff, and I'm sure many customers will find your tutorial helpful. We are working hard to improve the information in the Knowledge Center and recognize the need for a good cURL tutorial.

In the future we will be including the ability for our customers to contribute content directly to the Knowledge Center. Can we contact you at that time to see about incorporating this information?
Thanks again

I am integrating the usage of CDN with files that change frequently.. sometimes every minute.

What happens if I put a TTL of 0? Does this mean the frequency of checking for changes is more regular, or does it mean no checking at all?

I believe you would be prevented from setting TTL to 0. The minimum TTL is 15 minutes. If TTL could be set to 0 there wouldn't be much benefit from a CDN - the CDN would check for changes too frequently for it to proliferate any objects across the network.

If the file changes that frequently you'd be much better off serving it locally, where you can more easily control the content and replace it instantly (instead of waiting for a change to replace copies cached on edge servers on the CDN).

Add new comment