Symphony.

You could also add your brute-force kill-the-whole-cache solution as an preference

I'll take your suggestions into account and try to find a better way of making this more reliable.

Any other issues or suggestions that need to be adressed for the next version?

I have just installed the 2.3 version and when i look at the cached files in the cache folder, they are xml files... while in a 2.2.5 installation it caches the rendered html?
Is this supposed to be so? or is this a bug?

Mhh, seems really strange. I haven't changed anything on the extension's behaviour so far, only made a few migration changes for 2.3.

I'll look into it.

Found an explanation.

The xml files in the cache folder aren't from cachelite. Seems like the core Debug Devkit extension is creating some (xml) cache files as well.

The syntax highlighter in the Debug Devkit is Bitter, originally written by Rowan and it's this that writes cache files. I am not 100% of what they contain, but I imagine it'd be just the preprocessed XML tree to save processing it next time.

Yep, the pages do get cached, they start with 'cache'.
I was checking if they where there and i picked the cached xml files from the debug debkit... i missed the html files.

Hi folks

For one of my projects I have configured multiple domains to run from a single Symphony build (i.e all the domains point to the same folder on the server).

The Data Sources within the site are filtered by the $root param which allows me to localise the content for each domain.

I would like use Cache Lite, however, when I enable the extension, all the domains display identical cached content (e.g from the first domain requested) rather than the localised content as served prior to the extension being installed.

Does anyone have any thoughts on how I could get the extension to recognise the site root when caching pages? So the cache is based on the full page URL - not just the Symphony page relative to the root, as it would appear to be currently.

I'm using version 1.1.3 of the extension with version 2.2.5 of Symphony.

Any input would be much appreciated.

Cheers,

JL

Hi mate,

CacheLite will probably be using all params after the domain name to build a unique reference for each page. All you need to do is add the domain name into the mix.

See https://github.com/symphonists/cachelite/blob/8634c7191d8a89e0dfc9bca11b85cc47c72addf0/extension.driver.php#L21

$this->_get = $_GET;

The GET array is converted into a string (serialize(...)) which is eventually hashed (md5(...)) to be the unique ID for that page (and combination of GET params). You could modify this to also include the domain name in the array.

$this->_get = $_GET;
$this->_get['domain'] = $_SERVER['SERVER_NAME'];

I would like use Cache Lite, however, when I enable the extension, all the domains display identical cached content (e.g from the first domain requested) rather than the localised content as served prior to the extension being installed.

A fix for that will be included in an upcoming version of this extension I'm currently working on.

But yes, it's basically what Nick said.

That works a charm. Supreme!

Support for 2.2.5?

Probably, use 1.1.3

@nick

I'm currently researching the use of APC / apc_store(...) for output caching instead of CacheLite.

Is this (storing static site output in memory) generally a good idea? Or can you think of any downsides? What about caching images? Would it make sense for something like JIT Image Manipulation (not neccessarily in Symphony, but in general) to use this as well?

Yeah it's definitely a good idea — memory is faster than reading from disk, so less IO reads the better. The obvious downside is that if you reboot the server then the cache is purged. But it's a hardly a downside as it doesn't happen often... and if your server goes down then losing a temporary cache is the least of your problems ;-)

Rowan has been using his own alternative to JIT for some years which caches to APC. It makes a lot of sense. Sites with lots of images can create a massive cache size, often with a huge long tail of images that are requested infrequently. Using APC (or memcache) keeps the most frequent in memory, which seems like a sensible optimisation.

I have suggested before that Symphony should provide a better caching layer (at the Cologne Symposium one of my slides suggested a cache providers interface). I'm hoping to talk this through in detail with Brendan soon in order to make a proposal for #1046. I hope to extend the existing Cacheable class so that it provides the best cache available to your environment i.e.

• if you've got APC, it'll try to use this first
• then try memcache
• then use the database (Cacheable class current implementation)
• then use the file system (JIT current implementation)

Any thoughts on this specifically please add to the ticket :-)

I'm hoping to talk this through in detail with Brendan soon in order to make a proposal for #1046.

Sounds great. Already read your ticket, but you explicitly mentioned object caching, not output caching (as provided by CacheLite ;).

I hope to extend the existing Cacheable class so that it provides the best cache available to your environment i.e.

I guess an extension would still be needed for output caching, but different caching-extensions and even JIT could utilize the core Cacheable class instead of an external library like CacheLite?

Using APC (or memcache) keeps the most frequent in memory, which seems like a sensible optimisation.

I tested APC's behaviour on my local machine today. Seems like you can allocate a maximum amount of memory, and as soon as it reaches this limit, old data is deleted from user cache in order to store additional stuff. The default value is 32MB, so it reaches the limit and starts deleting stuff pretty soon when resizing some images, so I guess this only works well in practice if you allocate A LOT of memory to APC?

I guess an extension would still be needed for output caching, but different caching-extensions and even JIT could utilize the core Cacheable class instead of an external library like CacheLite?

Absolutely. The CacheLite class doesn't do much beyond what the existing Cacheable class does, except the CacheLite extension (which bundles up this class for Symphony) does the delegate subscriptions to implement the caching. So if Symphony provided file-based caching through its own API, CacheLite could be rewritten to use that. Likewise JIT rewritten to also use it, and Symphony's own internals also rewritten to cache its objects using the same API.

The default value is 32MB, so it reaches the limit and starts deleting stuff pretty soon when resizing some images, so I guess this only works well in practice if you allocate A LOT of memory to APC

Yep. 32MB is pretty low, but it depends if you've just got one webserver doing everything (including database etc.) or multiple app servers. Some people run a dedicated machine just for the cache layer (especially for sessions). It'll depend on your hardware, but you should be able to increase this significantly. The default RAM for Apache (under MAMP anyway) is 16MB, and the first thing I do is bump it to at least 64 or 128MB anyway.

Unfortunately, there is no 1.1.3

unless .. is it this?

Bit of a crosspost, sorry. I have the issue that the amount entries in symcachelitereferences doesn't decrease when doing ?flush=site, and eventually over some weeks leads to a server crash when mysql increasingy is getting concurrency issues. I've had >30K entries occasionally.

I mentioned it here: http://getsymphony.com/discuss/thread/100031/1/#position-3 – together with another problem,

thanks! J

I'll have a look and take care of the outstanding issues as soon as 2.3.3 has landed. Stay tuned...

Somewhat related, but still on a sidenote: I can really recommend using cloudfront (or any other cdn, for that matter) for your static assets (images, js & css files).

Most of the time, you will be able to setup a distinct domain for these assets (think static-DOMAIN.com, or cdn-DOMAIN.com), making it cookie-free, which is another big win.

Now, this by itself will create some problems, especially with user-uploaded images and files, unless you use the unique file upload field, which will append a random string, which is very useful for cache purging. The static asset versioning extension I released a while back might also be very useful for this.

The biggest benefit of this is that requests for static assets will never hit your server anymore. So your server can deal with the important stuff: serving your website. Also, serving the static stuff from a CDN means your page might load even quicker than before (I say might, because it really depends on where your visitors are located. If they are all close to your own server it won't matter much). Serving everything (image, css, js, pdf's, etc) from cloudfront is costing me.. wait for it... $1.59 for around 50k visitors per month. Not really breaking the bank, so to speak :)