Symphony.

I understand that this is kind of asking "how long is a line". But still: What is an acceptable page creation time? In what range, at least?

For a page with 9 DS's, I have a page creation time hovering at 1.5 seconds.

That's getting quite high. What's the bottleneck — data source execution or page generation?

In my experience the two largest performance bottlenecks are complex DS filters (where a single DS takes a long time to execute), and many data sources creating a lot of XML (in which case it's the XML generation/rendering that takes time).

Could you paste in your profile results?

General details: Engine Initialisation 0.0033 s

Page creation process started 0.0318 s

XML Built 1.3562 s

XML Generation 0.0142 s

Page Built 1.4157 s

XSLT Transformation 0.0261 s

Page creation complete 1.4738 s

DS execution: article (filter by $header param) 0.2119 s

articles_all (no filter, retrieve all articles, at present 28) 0.3981 s

articlesbypublisher (get all articles published by a choosen publisher, filter by $publisher param) 0.3417 s

articleslatest10 0.1560 s

external_delicious 0.0366 s

external_flickr 0.0119 s

jaikulatestone 0.0645 s

menu_main 0.0332 s

publishers 0.0818 s

This is on a page called 'published', which has two url parameters: 'publisher/entry'.

If the page is called without a url parameter, a list with all articles are displayed. With the publisher parameter, the visitor get a filtered list with only articles from that specific publisher. And with 'publisher/entry', a specific article is shown. That means that of the three first DS's, only one is really used for each page view.

Should I consider splitting things up? To go with a published page for the whole list, with 'entry' as the only url parameter. And have 'publisher' as a subpage of 'published'?

How many entries are we talking about? So, it sounds like you could reduce the time by two thirds if you split the one page up into three?

The articles_all DS gives the largest XML set. Currently 28 nodes. So there are not that many entries in either of them.

That's odd. But then again I've come across weird cases like this. For instance, my categories data source which comprises about 10 categories takes longer than the entry data source which produces filtered results of about 10 from 250.

Does the field setup affect the DS run time? Or is it just how you choose to filter and group the result?

In total, I've 28 article entries, 4 publishers, 2 blog entries and 4 blog categories right now. So it's not that S2 is under that much load yet.

Could you use the 'required URL parameter' option in the DS to check for the publisher or entry parameters and only execute them when required?

Splitting to sub-pages would certainly aleviate this.

Alternatively if you're happy editing your data source PHP files you may be able to make some modifications. For example "articles" only needs to return when $publisher is not set. Therefore in the grab() function of your DS you could add a condition around the code, something like:

if ($this->_env["param"]["publisher"] == "") {
    // original contents of grab() here...
}

This will check the publisher parameter and only execute the DS when this is empty.

Remember that if you do edit the PHP yourself, delete the allowEditorToParse() function to prevent yourself re-saving through Symphony, thereby losing your changes.

Alternatively there may be a simple native solution:

I think you could double up your Articles and Articles By Publisher data sources. If you modify Articles to filter the Publisher field by $publisher, when this parameter is empty it will be ignored (same as your present Articles DS). Therefore when $publisher is set, it will do the same job as your current Articles By Publisher DS. I haven't tried, but you might also be able to do the same with the article title too, since both the publisher and entry filters will be populated.

This is where Symphony's feature of ignoring empty parameters becomes useful, because you can fall back to the unfiltered list.

Also, can you streamline the fields each DS outputs? The more fields a DS is selecting and returning to the XML (and adding grouping as well) the slower the query will be, since an addition query is required for each field, for each entry.

In your Articles DS, you wouldn't need to output the entire article content, for example. This would only be required on the specific article DS.

Nick, thanks for the last suggestion. I didn't know about that possibility, about how Symphony works with empty url parameters. I know have one instead of three datasources. And my page creation time is down to 0.15 seconds.

(But the strange thing is: Page creation using my old solution has today dropped to 0.30 seconds...)

Great :-)

I think this concept is demonstrated in the default Symphony build — an Articles DS returns a list of latest articles, unless an article title handle is matched, in which case it returns a single article.