One of the things that I’ve noticed in running PHPDeveloper.org is that the highest traffic (most of the traffic for the site, actually) is going to the RSS feed giving the latest news I’ve posted. When I first relaunched the site with Solar, things were fine – but only for about ten minutes. As soon as everyone’s aggregators came back on and started pulling the feed, the load on my server shot straight up. Thankfully I was able to get it back down to a more manageable level with a static version before the box took a nosedive. I had to do something about it and I figured that caching the feed’s information was definitely a start.
I’d never really used the Solar_Cache stuff before, but thankfully – it’s super easy. I figured that the biggest bottleneck in making the feed was pulling the data from the database each time. I opened up the controller for my feed (Feed.php – I know, very creative) and added a Solar_Cache object.
You can set this stuff up in your configuration file too, but I dropped it into my controller as a quick solution.
In my _setup() call:
$config=array(
'adapter'=> 'Solar_Cache_Adapter_File',
'path'=> '/tmp',
'life'=> 200
);
$this->cache = Solar::factory('Solar_Cache', $config);
This creates a cache object in $this->cache that I can use for whatever I want. It’s file caching and the results will get put in /tmp. That “200” for the life is in seconds, so it’s at about three minutes right now. There’s lots more options for caching besides files already built into the framework too like APC, eAccelerator, variables and XCache.
With our object made, we apply it down in our default actionIndex() wrapped around our database fetch:
$ret=$this->cache->fetch('feed_data');
if(!$ret){
$news=$this->news->fetchNews();
$this->cache->save('feed_data',$news);
$ret=$news;
}
$this->news_items=$ret;
Pretty simple, really – the cache object checks to see if the data already exists and, if it does, just passes it on through to our view. If it doesn’t (either that it’s the first time it’s being made or it has expired) it will pull the new news and push it out to the cache. The view then takes this array of values and makes a basic RSS feed out of it for all the world to see.
You wouldn’t believe how much something simple like caching your feed can help on even a moderately popular site. Check out the class list for details on the other caching options.
blog.phpdev 
Right on!
This is what I love about Solar: you don’t have to think how it works because it does things with the most obvious way.
LikeLike
For sure that caching the ‘data source’ result improves performance but I’m wondering what’s the reasoning to don’t cache the final feed so it doesn’t need to be built on each request?
As I see it, the most effective solution is to build the feed(s) and place them with your static files (images, css, js), this way you can even use something like lighttpd and there is no need to launch PHP for each request. Even authentication can be solved easily in the system layer.
Am I missing something?
LikeLike
I agree with DrSlump, most times you don’t need a dynamic script running these feeds in my experience. For example, if your rss feed is for news, I would usually have the news Model have an observer which is an RSSFeedBuilder or some such which would observe save/edit events and then make intelligent decisions about whether to rebuild the feeds. If you’re only changing/adding/editing the news through the Model object then there’s no problems. YMMV, but my finding is there’s little reason to even launch PHP for RSS fetches.
LikeLike