Hi Per,
Cloud you elaborate on the reasons for needing a configurable cache control option? The Weblob data type that WP2Cloud uses to store media files in the cloud generates a new URL every time the data changes, so there is no functional need to have an expiration policy.
Hi Artem,
I’m planing to move my site to aws. I’ve have a test site at http://aws.soderlind.no/ built on your linux + mysql instance (not the yapixx instance) where I’ve added apc, php-fpm, nginx (with fastcgi cache and the purge cache module) and wordpress with the nginx, wp2cloud and w3 total cache plugins. I monitor the site using new relic.
Content is distributed using cloudfront (cdn01 = wblob, cdn02 = js, css + etc ) and cloudflare.
Tuning for speed, gtmatrix and pingdom complains that the wblob files should have a expiration time ( Cache-Control max-age: “one week or more”). w3 total cache sets the expiration time for the files on cdn02 but not for the image files in cdn01.
Br,
PerS
Here’s the result from tools.pingdom.com: http://screencast.com/t/jG5MOhNAn1yH
Hi Per,
Thank you for report! It looks like ClouSE doesn’t set the cache control headers, so S3 uses its default expiration policy which is one hour, I believe. I filed a bug suggesting that ClouSE should set max-age to a year (or more) in the future.
This feature will be available in the next release of ClouSE, hopefully within a month.
Excellent, looking forward to it.
Just released a new version of ClouSE. Now the max-age is set to one year in the future.
Eh .. how can I update / add the max-age for existing images ? I’m using cloudfront.
Hi Per,
ClouSE doesn’t set cache control headers for existing Weblobs. You can do it manually if you don’t have a lot of objects or you can use a script.
I used Bucket Explorer to change the max-age.