Symphony.

I noticed a short while ago that my test site seems to slow down on page loading. I checked my Page Profile:

Engine Initialisation: 0.0294 s
Page creation process started: 0.0303 s
XML Built: 0.3942 s
XML Generation: 0.0010 s
Page Built: 0.3972 s
XSLT Transformation: 0.0078 s
Page creation complete: 0.4354 s

I think the XML building time is high, but I don't know why. I commented out all complex XSL templates but nothing changes. From time to time the XML building time takes even more than a second, sometimes it seems quite normal. The shown data is an average result.

Anybody else experiencing problems? Is this a server or a Symphony related problem?

Nils

It seems to be connected with the database queries as far as I can see. I'm working with the Page Profile for the first time and missed the other tabs with more detailed information. This is the full statistic of a slow page generation:

General Details

Engine Initialisation: 0.0121 s
Page creation process started: 0.0131 s
XML Built: 0.9544 s
XML Generation: 0.0010 s
Page Built: 0.9620 s
XSLT Transformation: 0.0053 s
Page creation complete: 0.9805 s

Data Source Execution

ausgabe: 0.3457 s
layout_artikeluebersicht: 0.2269 s
layout_name: 0.1859 s
layout_struktur: 0.1932 s

Full Page Render Statistics

Total Database Queries: 238
Slow Queries (> 0.09s): 0
Total Time Spent on Queries: 0.4200 s
Time Triggering All Events: 0 s
Time Running All Data Sources: 0.9517 s
XML Generation Function: 0.0010 s
XSLT Generation: 0.0053 s
Output Creation Time: 0.9805 s

Anything I can do about it?

Additional information concerning the Data Sources. The DS ausgabe which execution takes the longest time is pulling three values from a section containing articles:

• kategorie (english: category; select box),
• veroeffentlichungsdatum (english: publish date; date field) and
• nummer (english: number; input field).

The result is filtered by three statements:

1. "Veröffentlichungsdatum": 1950-01-01 to {$today},
2. "Nummer": {$nummer} (page handle) and
3. "deutsch" (english: german; checkbox): yes.

The resulting XML looks like this:

<ausgabe>
  <section id="1" handle="artikel">Artikel</section>
  <entry id="17" kommentare="0">
    <kategorie>
      <item handle="analog">analog</item>
    </kategorie>
    <veroeffentlichungsdatum time="19:39" weekday="3">2008-02-06</veroeffentlichungsdatum>
    <nummer handle="4">4</nummer>
  </entry>
</ausgabe>

I don't know why this process takes this long, it seems not to be that complicated ...

Hmm, I can't see why the DS will take this long...

The only thing that might do it is the date range filter, which has not gone through rigourous testing and optimisation. Can you take away the date range and see if that helps significantly?

That seems to help: It reduces the execution time of this DS to <= 0,1 s (most of the time).

But Data Source execution times seem not to be consistent: they are changing drastically on every reload and it's not always one Data Source taking the longest time period. E. g. the DS first being the slowest might be the fastest after reloading the page.

These are some examples:

ausgabe: 0.0946 s
layout_artikeluebersicht: 0.0356 s
layout_name: 0.0208 s
layout_struktur: 0.0122 s

ausgabe: 0.1712 s
layout_artikeluebersicht: 0.0869 s
layout_name: 0.0472 s
layout_struktur: 0.0113 s

ausgabe: 0.0673 s
layout_artikeluebersicht: 0.0574 s
layout_name: 0.0979 s
layout_struktur: 0.0114 s

ausgabe: 0.0463 s
layout_artikeluebersicht: 0.1475 s
layout_name: 0.0207 s
layout_struktur: 0.0200 s

ausgabe: 0.7171 s
layout_artikeluebersicht: 0.5730 s
layout_name: 0.0232 s
layout_struktur: 0.0128 s

Are you on a shared hosting environment? If so, is there another web application that has some sort of profiling device you could use to test the consistency? We need to determine if the erratic rendering time is caused by being in a shared hosting environment where other users of the same server is eating up resources or whether or not it's caused by Symphony.

I'm on a shared host but I'm not aware of another application with a profiling device.

I copied an ensemble to my local host and the page redering times are constantly around 0.1 seconds. So it seems to be connected to the server resources. I'm running another website on the shared host (using Symphony 1.7) which sometimes is slow but normally behaves quite well (total page render times between 0.1 and 0.2 sec).

Allen, I contacted my host and they checked the server logs. The server is running stable with a average usage. They can't find any problem and there seem to be no other processes on this server that could cause a slow response of the data base.

So the problem seems to be connected to the processes run by the Data Sources I'm using. There are 238 queries on my site, none of them marked as slow, but maybe a large number of fast queries sums up to the long rendering times. Is there a good way to test this?

We've seen query counts as large as 1,000 which are processed quicker than yours. Query count is unlikely the culprit, but rather the possibility of just a couple from the set of 238 which is causing the slowdown. Determining which particular query is causing the slowness will help get us one step towards finding the problem as a whole. However, before we even get to that stage, we still need to figure out why your site is experiencing an erratic render time behaviour. Personally, I cannot seem to find any reason why Symphony would cause this behaviour but this is an area best left to our resident systems engineer, Alistair.

It's all a little strange - so thanks for your help! (Isn't it nighttime in Australia now? It's even getting dark here in Germany.) The guy of the support wrote to me that he could not retrace the problem in any kind, so there seem to be no hints that the data base responds slow.

An idea that came into my mind: Is it possible that there is a setting for MySQL databases to just accept a certain number of queries in a time period? I don't know much about databases, but maybe it could be something in that direction.

Maybe it helps, these are some slow queries popping up from time to time:

0.1482: SELECT SQL_NO_CACHE * FROM `sym_entries_data_1` WHERE `entry_id` IN ('17')
0.1054: SELECT SQL_NO_CACHE * FROM `sym_fields_textarea` WHERE `field_id` = '22' LIMIT 1

Have you compared the mySQL php.ini settings on your shared to that on your local?

Try turning on query caching via /manifest/config.php. Assuming that your hosting has query caching enabled, that should at least take strain off MySQL (it wont reduce the query count however).

$settings['database']['disable_query_caching'] = 'no';

That should do it. You will notice that SQL_NO_CACHE should disappear from any query.

Hm, this option was set to no. Anything else I can do?

Have you compared the mySQL php.ini settings on your shared to that on your local?

Yes. They are the same except the Client API version (which is 5.0.41 @ localhost compared to 5.0.27 @ shared host).

yeah, I looked at the library files in question and it seems that there are some discrepancies in settings variables...

differences between: "disablequerycaching" and "query_caching"...

I may be wrong though...

update: I fixed this issue and it sped up my load times significantly...

Can you please put this up as a bug on the tracker?

already did :)

Thank you lots with gusto.

differences between: "disablequerycaching" and "query_caching"...

Whoops. Thanks for spotting that. For now, changing the config to

$settings['database']['query_caching'] = 'on';

should do the trick.