Symphony.

Servus,

I wrote an article about Symphony recently. The article is written in German and can be found at http://markus-schlegel.com/weblog/symphony-cms

One commentator claimed that there are too many database queries and actually there are really about 100 queries with the standard template and without any plugins.

100 are really many queries, but they are not significant slow, so where do all these queries come from?

And if you do not know where they come from but use symphony regularly, can you tell me whether there are any performance problems at all? Are there any comparisons between Wordpress’ and Symphony’s performance around in the web?

I hope you can help me and give a positive answer so I can justify my recommendation on my blog ;)

best regards,

Markus Schlegel

I can’t speak to the queries specifically, but I kow that there is alot of abstraction in how the secions/fields are handled, so that may be a factor.

As far as performance, any problems I have encountered have been my own doing. I have had 1 performance issue with an event-related extension, and another with using exsl in a less-than-efficient way. That said I don’t have any high traffic sites running Symphony…

I’m about halfway through my first symphony site, and the front page is completed. It’s a conversion of an old site that ran on textpattern; the data on the front page is nearly identical and they are on the same system.

Textpattern’s output is:

<!-- Runtime:    0.0331 -->
<!-- Query time: 0.012012 -->
<!-- Queries: 23 -->
<!-- Memory: 2871Kb, end of textpattern() -->

Symphony’s output is:

Total Database Queries
    165
Slow Queries (> 0.09s)
    0
Total Time Spent on Queries
    0.0225 s
Time Triggering All Events
    0 s
Time Running All Data Sources
    0.0719 s
XML Generation Function
    0.0017 s
XSLT Generation
    0.0081 s
Output Creation Time
    0.0927 s 

Yet, symphony for some reason feels snappier, perhaps textpattern’s data isn’t entirely correct.

The symphony website is built on symphony, so it’d be interesting to see it’s runtime and how many visitors the site gets, and if it employs any kind of caching for everything except the forums.

There may be many queries, but they are small. Symphony’s database tables are well-indexed and light-weight, but also normalised to fourth normal form (4NF). This means that every instance of every field has its own database table (100 fields means 100 database tables), with each table storing the values for that one field.

This means that to build an entry (say an entry has five fields) it requires one query to grab the main entry ID (from sym_entries), then one query for each of the five field values.

I don’t see that 100 queries is too many. MySQL caches commonly used queries, so they are very fast indeed.

We have commercial websites running Symphony that top 1000 or even 1,500 queries per page, serving several thousand requests daily, and performance seems to be fine (page loads sub 1 second).

The biggest performance bottleneck isn’t necessarily database queries, but building and rendering XML. Optimisations are being made in this department, with an aim to reduce Symphony’s memory footprint.

Can’t comment about Wordpress I’m afraid.

@Markus Schlegel: I just commented on your blog. Nice to see a German write-up about Symphony.

Are there any comparisons between Wordpress’ and Symphony’s performance around in the web?

I’m not sure if these two systems can be compared easily: they both serve different purposes. While Wordpress is specialized for blogs, Symphony is made to be flexible in all directions. This results in different architectures which suit well for different purposes.

I have a page that runs 488 queries, and is spending 15.6s on the querying. This is an average of .03s per query, but is unacceptable. DO I just have a slow MySQL server? What’s a good speed for a single query, or is that just a silly question?

@ashooner: Sounds strange to me. I have pages with more queries (750 to 1000), which are handled in 0.1 s altogether. (And this is not on a high end server.) As Nick Dunn described, most of the time is spent on building the XML normally.