0 users online. Create an account or sign in to join them.Users

Search

Hi everyone,

This seems to be a hot topic with symphony, however I noticed that it is hardly discussed anymore. Just wanted to ask…

I am working with Symphony 2.1.2 and wondering what my options/solutions are.

1) Using CachLite for caching the html pages would be really cool, however there exists some dynamic content on most of my pages. It would make sense to use javascript for such dynamic content however this doesn’t seem very robust. Any ideas regarding caching the html pages which contain dynamic content?

2) Using Symphony’s profile, I noticed that the datasources are taking up a considerable amount of time (1.4 seconds). I also noticed that the Page hierarchy is executing 340 database queries everytime a page is loaded. Is it possible to cache specific tables? Is there a robust extension that does datasource caching? I noticed there had been some work being done here but the project seems to have stopped. Maybe there is another way of caching the mysql queries or any other optimisation techniques you can think of?

Appreciate any feedback. My apologies if some of my comments seem to be overlapping others. Thanks

1.4 seconds and 340 db queries seems really high for Symphony 2.1.2. How complex is this page?

Does Symphony not cache the XML returned from queries in any way? It would make sense that you should be able to set a Data Source to cache if it isn’t dynamic data.

e.g. Article is created, said article is probably never going to change, so server caches the call for that data in XML format at least.

Is that making sense?

Cacheable Datasource is your friend.

Cacheable Datasource is your friend.

I had to use that one a few weeks ago for the first time. It’s so stupidly simple to use, amazing!

Cacheable Datasource looks great. I will try this out as my site is pretty busy too. Databases can be quite a pain as far as website speeds go…but what about the dynamic content and caching? I dont think this has been addressed yet - solutions?

but what about the dynamic content and caching? I dont think this has been addressed yet - solutions?

Can you elaborate?

Does Symphony not cache the XML returned from queries in any way? It would make sense that you should be able to set a Data Source to cache if it isn’t dynamic data.

Symphony does no caching itself. MySQL caching is enabled by default, but that is handled by MySQL itself, not Symphony, and doesn’t cache the result output of queries per se.

I recall the guys contemplating adding data source caching around version 2.0 but there were simply too many questions and use cases to satisfy:

  • should the cache be time based (purging the cache after a specified time), or event based (purging the cache when the data changes)?
  • should each entry in the data source be cached individually, or the entire output?
  • how do you handle cached data that is then updated via events?
  • how do you handle cached data when data sources are dependent on one another?

My Cacheable Datasource extension tries to satisfy these in the simplest way possible — the XML output of the data source is written to a file on disk with a time-based expiry. Because one data source can be re-used throughout your site in a variety of ways, every unique combination of data source options (sorting, limiting, pagination, filters) creates a new cache file.

It works pretty well, although it’s not perfect. There’s an odd bug I’ve come across whereby occasionally the DS returns nothing at all, but I’ve not tracked the bug down. Plus it only happens very rarely: I’ve got the extension running on many live sites without issue.

CacheLite is also a very good option. This uses time-based expiry with the addition of event-based purging too. So you can set very long expiry times (hours, days, weeks rather than seconds or minutes) and the cache can be purged when the data is created/updated in the backend instead, so your content changes are seen on the frontend instantly. I know that the BBC use this method of caching, and add non-cached fragments like “Logged in as {name}” in the header using JavaScript — it’s a widely used solution that you shouldn’t discount.

A single universal caching mechanism will not satisfy all possible use cases, but between CacheLite and Cacheable Datasource we’re close.

Thanks to all for such information! This Cacheable DataSource is amazing!

Does anyone have any experience using Datasource caching with the Multilingual Field extension? Can anyone recommend a modification to the extension which would make it work with multilingual fields?

@Nick- thanks alot for such lengthy replies…ur feedback is greatly appreciated

Can anyone recommend a modification to the extension which would make it work with multilingual fields?

What doesn’t work at the moment? If the data dource works with the Multiligual fields without caching, then adding caching shouldn’t change anything.

Forgive me if I might sound a bit primitive in my explanation… I have a number of Pages which contain a menu title and menu subtitle in several languages. The issue is that when loading up the page for the first time, the data gets cached in that language. When re-loading the same page in another language, parts of that webpage (i.e. that are not widgets) are loaded in the language in which the webpage was initially loaded.

I hope this is not misleading..

Aha, it sounds like the multilingual field is doing something too clever for my extension. Do you filter the data source by a language parameter at all, or does the language extension do this for you?

The caching mechanism builds a “signature” of the data source by taking unique combinations of the filters, sorting and limiting. If you change the value of a filter, then the cache doesn’t match anything so a new cache is created. With the multilingual extension it seems that it doesn’t “show” its language switching, so the data source doesn’t get re-cached for each language.

The only solution I can think of, without looking at the code, is that the cache logic also factors in the language URL parameter when it builds the signature for the data source. But I don’t like inter-extension dependencies so I’ll try and think of a more elegant solution.

Anyone have any smart ideas?

Thanks Nick. Just had a discussion about this with my colleague. Think we are on the same wave-length as we are thinking of patching the Cacheable DS extension to make it consider languages. We were thinking of amending the class.cacheabledatasource.php to something like this:

$filename = sprintf( “%s/cache/%s-%s-%s.xml”, MANIFEST, getclass($this), md5($filename), $GET[‘language’] );

As you suggested we will be appending the language set in the URL to the filename.

Yep, spot on, that’ll do it.

The Multilingual extension is on my todo list because I haven’t really seen how it works. I’ve got an outstanding pull request on Github to get Search Index working with the multilingual extension, and now Cacheable Datasource, but I’m reluctant to litter extensions with references to others. So while adding in language will work for now, we’ll try and think of something more elegant for the future.

ok cool! Thanks alot Nick for your active involvement and constant replies! Really appreciate it. Can’t wait to get more involved in Symphony.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details