15
A Static Cache for Symfony and Silex – Would you use it?
12 Comments · Posted by Christian in The real job
Ever since I write sfImageTransformExtraPlugin I have this plan of porting it to Symfony 2 and/or Silex. So far I just didn’t have the requirement thus no time for it. But I know roughly what ingredients would be needed.
One of them would be a static cache.
The idea
A static cache would take any response for a given URL and write it onto the filesystem in the document root folder with the URL path as its filename.
http://www.example.com/path/to/your/resource.html
Would become:
/var/www/example.com/htdocs/path/to/your/resource.html
So the next time this resource is requested it would be served statically by the web server and no PHP process would be involved.
For Symfony this static cache would implement HttpKernelInterface so it could be used just like the HTTPCache (AppCache).
For Silex it would probably not implement HttpKernelInterface but instead wrap the whole app and run it.
Of course a cache like this comes with some trade-offs.
The consequences
There would be no invalidation. Not expiration no revalidation, no stale-while-revalidate all that cool Http stuff you learned from Symfony would not be used at all.
If a request can get a response it will be written to disk and from then on the same response will be served forever.
Or until the cached response is manually removed (maybe using a command) or automatically (maybe via a cron job calling a command).
So you can imagine that this kind of cache is only suitable for specific use cases and doesn’t apply for every project.
Another downside I am not yet fully sure of is security. This cache would require the web server to be able to write in the document root. So you have to be extra aware of handling user input as this could be a security breach. Also any security hole in your web server or in PHP could probably be exploited easier.
If you are a security expert please commet on this post.
Optional
Optionally the cached response could be written into a document root of another web server for performance improvement.
Think of using a very lightweight web server with only static file serving for your main domain and a htaccess that rewrites any request to a non-existent file to another URL where a full blown web server with PHP will produce a response, write it into the document root of the first one and return it. Next time the same resource is requested it would be served by your lightweight web server without any PHP and stuff compiled into it.
What do you think is there a need for such a thing?
Igor Wiedler · 15. November 2011 at 08:06
Honestly I don’t think it is needed. If you want a static site, use a static site generator. Most people don’t need actual static files, and they can just use Varnish to cache their content.
Admin comment by Christian · 15. November 2011 at 08:08
@Igor I agree that in most cases it won’t be needed but what about generated images like thumbnails or diagrams for reports and such?
naholyr · 15. November 2011 at 08:45
I think you missed the point about the drawbacks :
* security : of course never write to docroot directly! This is a huge flaw! Come on this system is all but new, how does it work everywhere else? You write in a subfolder (named from your app and environment by the way, or you may suffer severe complications) and use proper rewrite rules.
* about the invalidation it’s in fact a commonly unsolved usual issue. I’d handle it by two ways:
** obviously, some pages should not be cached and some config or call to `response->staticCache->disable()` could do the trick.
** you could simply store response cache headers like max-age and expires, store it in a metadata file attached to the cached file in some way, and periodically browse those metadata to invalidate some parts of the cache with a smart way (async io could be a good thing for such a daemon)
Matthias Breddin · 15. November 2011 at 10:03
I would rather invest some time looking into the ESI Feature of sf2.
Also if you use nginx, cu.be will release a nginx-esi plugin soon. With Dynamic support. See: http://www.slideshare.net/wimg/making-dynamic-sites-scale-like-static-sites
Marc · 15. November 2011 at 10:57
@naholyr: It’s reinventing at its finest.
@christian: I clearly don’t see the point. Look at how the AvalancheImagineBundle works for caching assets.
If you really need something like this, look at how ESI works. You’ll be really pleased with the result.
Admin comment by Christian · 15. November 2011 at 21:16
@Marc cool it’s been a while since I last looked at AvalancheImagineBundle. It seems to cache exactly the same way as I proposed above and the same way I implemented with sfImageTransformExtraPlugin.
@Matthias Of course ESI is to be preferred if you can take advantage of a varnish or squid cache. But in a single server environment I would prefer not to spawn PHP.
@naholyr well the last option of the article would take care of that as there would be no more server side logic to be exploited when serving the written data.
Pierre · 26. November 2011 at 08:18
@Christian
I like the idea!
Coupled with a change management (Event based) would make such thing very useful and handy.
The comments here are somehow misguided, varnish, ESI or any other similar solutions are nice but add a useless complexity to the architecture of the application. It does not matter either if there are one or many servers.
Admin comment by Christian · 27. November 2011 at 14:35
@Pierre thanks for your comment. I am sure that there are many situations where my proposal isn’t the desirable solution. However especially on single machine setups it can make sense.
Pierre · 27. November 2011 at 19:02
@christain, one single machine makes sense but even with many.
If a give area of a site is only static but generated, say less than once per hour/day, it makes totally sense to do what you suggest.
A typical use case is something like what we do in pecl.php.net (a pear channel). We are rewamping the site and all the public parts are static html only.
The few parts that require dynamic contents (new releases on the home, or similar cases) are generated from the client using js).
Admin comment by Christian · 27. November 2011 at 21:35
@Pierre there’s a similarity to static page generators of course though I would rather call this approach a static response generator as the cache would be written on the first request and invalidated (deleted) from the underlying application i.e. when a new image is uploaded and thumbnails would have to be updated or an article is being rewritten.
I still think this cache would make a lot of sense for some use cases like thumbnailing. If you look at Imagine or Assetic you will see that the do the same thing essentially.
Pierre · 30. November 2011 at 18:15
@christian indeed, it is usable in both cases (and many other
Eric Clemmons · 5. May 2012 at 03:48
I stumbled on this via Google and was looking to do exactly this for my personal Silex site so that I could push it to Github pages.
Heads up, I’m going to end up working on this