Symphony.

Support for 2.2.5?

Yes, use 1.0.0

The UI works, but it isn't generating any cache files :(
My cache directory under datasources is writable and empty.

PS. @nickdunn can u shoot me an email, been trying to get a hold of you for ur delivery

Nice, this is the first time I'm really looking into this, and it looks promising!

As usual, though, a few remarks: storage on my machine is networked, which makes dealing with many files quite slow. My vote would be to put some pressure behind the caching classes, and think about supporting memcache or APC here. At least for me this will be a huge performance plus. Also, because these mechanisms have proper garbage collection, we don't risk dealing with millions of files because of a bug.

I am still wondering about the expiration process: why are we expiring based on time? We have delegates that fire right before an entry is saved, so couldn't we use these to purge the cache on any datasource that relies on that section? I assume that a change in parameters will cause the datasource to re-render, right? If that's the case then there will be no problems with chained datasources, which is brilliant.

As usual, though, a few remarks: storage on my machine is networked, which makes dealing with many files quite slow. My vote would be to put some pressure behind the caching classes, and think about supporting memcache or APC here. At least for me this will be a huge performance plus. Also, because these mechanisms have proper garbage collection, we don't risk dealing with millions of files because of a bug.

See this comment

I am still wondering about the expiration process: why are we expiring based on time? We have delegates that fire right before an entry is saved, so couldn't we use these to purge the cache on any datasource that relies on that section?

I wrote this for exactly that reason.

I am still wondering about the expiration process: why are we expiring based on time? We have delegates that fire right before an entry is saved, so couldn't we use these to purge the cache on any datasource that relies on that section?

I've implemented this feature in my fork.

@andrr, could you submit a pull request for these changes? I am pretty sure these changes are welcome for everybody.

By the way: this extension is totally awesome, it has shaved 300ms off every request for me, saving nearly 75%, making everything feel very snappy.

This extension shrunk my page creation time from 2 seconds to 1 second (to 0.3s when every DS used is cached)!!!

Is there anyway to fix the formatting? This is what mine looks like:

This only happens for my first cached data source. The other cached data sources afterwards have proper spacing

Is there anyway to update the cache when an entry is editing from the frontend? @andrr's code only works when entries are updated from the backend.

Hello, I have and old site with symphony 2.1.2 and cacheable data source 0.4 In the back end if I go to system/cacheable data source I get this error:

Fatal error: Class 'FrontendPageNotFoundException' not found in /web/htdocs/www.bbox.it/home/symphony/lib/toolkit/class.datasource.php on line 66

How can I fix it?

Moreover... I have made a new entry, but the cached datasource is not updated and I don't get the new entry. It is the normal behavior with this extension or there is something wrong?

Thanks Daniele

I think you could say it's normal behaviour. The extension only caches and does not invalidate the cache, unless there's an expiry in the time. There are variations which allow to clear / refresh the cache on save.

However this most likely happens because someone would have previously navigated to the same URL getting a 404 error (hence you have a cache of the 404 error) usually waiting till the cache expires & is refreshed will solve the problem.

I would love to get some feedback on how people use this extension... mainly on what time duration they use when setting your cache.

In my situation, I have a very large site that is updated quite often which uses boatloads of queries and complicated datasources... so this is definitely the extension for me. I would love to know how to use it the best way. Right now, I am setting my cache to expire every 60 seconds.

Is that wise? Should I set that setting to go longer?

Also, I just found @brendo's Cacheable Datasource Add-on: On Demand which clears cache after entries are created, update, or deleted in the Symphony backend. I now have that installed.

With that installed would it be wise... to have bump the expiration time to say... 300 seconds?

What do y'all think? What has been your experience with this extension? How have you used it?

With that installed would it be wise... to have bump the expiration time to say... 300 seconds?

Or two weeks, or months...

I can't remember if this extension cleans up after itself when using chained datasources - but I believe my expiry times are measured in months rather than minutes. Because my output is expected to chance with Symphony entries only, this seems to work fine.

If you have other sources too then this will not hold, of course, and you might want to try different times.

To add to my previous post: it also depends on your website. How bad is it if a visitor gets results that are two minutes old? Would they even notice?

And, also very important, it depends on effectivity. On how many visitors receive the cached vs new results? I found that my homepage was visited most frequent and had the most expensive queries, while it changed quite infrequently. Caching thus made a huge difference. However I can imagine that there are pages that change every few seconds with just a few pageviews. Caching will not make a huge impact here.

Then, to make it all even more difficult, what are you aiming for? Even with cached DSes, Symphony is not the fastest. It has to talk to mysql, load a boatload of files from disk and so on. On my websites I use Varnish to keep the homepage very snappy. The cacheable DS is then used to keep everything fast even when Varnish needs to refresh.

The cache times for Varnish are set to around 1-2 minutes for me.

@creativedutchmen - very helpful response!

I use an expiration of 1 year. I forgot if I had @brendo’s fork installed, but the one I have already has the flushing of cache after updating an entry in the backend.

The problem is that cache will not be flushed with the creation of new entries in the frontend. So for user-created entries, I don’t cache them.

The problem is that cache will not be flushed with the creation of new entries in the frontend.

Honestly this sounds like a bug, not a feature.

the cache will be regenerated after x-seconds? so when additions to the data made at front- or backend there are not show for maximum x-seconds. I don#t think this can be a serious problem, when you don't take cacheable datasource for stock market or somethink like taht?

or am I complete wrong? so you got the possebuility to delete cache entries, when new entries are made, don't identify cache only with request params.

to say the truth, don't realise your trouble, please explain it.

@moma: sure, you could set the expiry time to a few minutes, but that means that the cache will be recalculated way more often than needed.

For busy sites, this will add up.

You can compare it with push vs pull on email and text messages. You could ask the server for a new message every few seconds, or you could wait for the server to tell you when a new message is posted. While the first works just fine when you set the interval small enough (a second, say), it will require a lot of processing power. Setting the interval to something longer means less processing power, but also less immediate notifications.

Now, back to the frontend posting thing: imagine a user posts a message but the message does not appear for another 5 minutes. What do you think the user will think? So, you probably set the caching interval to something like 10 seconds. But then you are recalculating the cache every 10 seconds, even if a new message is only posted once a week.

So, expiring the cache only when a new entry is posted means the best of both worlds. As soon as an entry is updated or created the update will show, but it is not recalculated until the next update. So yes, while setting an expiry time is a "fix", it is far from optimal, especially with front-end submitted entries.

@creativedutchmen - It’s definitely a bug, but I don’t think @nickdunn contributes to Symphony any longer, and I have no idea how to tackle this.

It’s definitely an issue for exactly what you described. You can’t cache messages, because once a user sends a message, the cache needs to be refreshed. However, when the user is just reading messages, all that data could be cached but isn’t.