Usage example:

$sfManagedCache = new sfManagedFunctionCache(
  new sfFileCache(array(
    'cache_dir' => sfConfig::get('sf_external_cache_dir').'/sfManagedCache',
    'lifetime' => 86400))
);

$xml = $sfManagedCache->call(
  array('Webserice', 'call''),
  array($parameter1, $parameter2),
  1800
);

The tasks are used like this and should be set up as cron jobs:

./symfony managed_cache:refresh --application=webservice --env=prod
./symfony managed_cache:refresh --env=prod

The first call is for a specific application while the second one is for application-agnostic cache items (not for all items!).

This is not a fire-and-forget plugin. It requires planning and maintenance. Since the cached items are designed to never expire, carelessness can easily lead to problems. I will cleanup the plugin some more, write documentation and then release it.

1) The data was raw and needed to be reprocessed before we could use it. That meant parsing the XML, running it through the processor and then writing it out again. Too much effort to do on every request, so again data would have to be cached.

2) More importantly, the webservice performance was atrocious. Request times for a 4 item rss feed hovered around 5 seconds. A completely rendered page could require several calls to this service. Whether these long request times were due to problems on our end, their end or somewhere in between was unimportant for the moment. The results would have to be cached to be useful.

Naturally, I could have left the caching to the application that used the webservice, ie. parse the information provided and store the results in memcache. The problem with that approach is that memcache is a very simple cache, and paired with the long request times for the webservice you're bound to run into problems. No matter how scalable your application and infrastructure is, if a reasonably common request is taking 5, 10, 15 seconds to complete, you're going to see a thread pileup sooner or later, which is what will happen when the items in memcache expire. And don't even get me started on the degraded user experience.

The proper solution for this is a managed cache.  One important concept is prefetch, ie. refresh the cached data before it expires, so it doesn't matter how long it takes to create it. WP-Supercache has this feature and Varnish recently introduced this feature as well along with grace. Grace is the other concept, which allows you to continue serving up stale or expired data if the data source becomes unavailable. In most cases, serving up old data is better than no data at all.

Symfony doesn't have any plugins or classes or other facilities to deal with these kinds of things as of right now, so I decided to just deploy Varnish for the purpose of caching the modified webservice data. No development time and very little effort to deploy and working perfectly. Unfortunately, I have to abandon that setup because of "complexity concerns". So in the next couple of weeks, I'll probably write a managed cache plugin for symfony.