Search

Before moved to symphony i used modx cmf to create websites. Also i’ve read many articles about perfomance and struggled in every project to minify database queries. In common in all older projects there was 10-20 db queries on a page. But when i installed symphony for a first time i was shocked about stunning number of queries. On the simple demo project it was 78 queries on a page. The question How does many queries effects on a performance of high loaded projects? Is there any way to optimize/minify number of queries?

What version of Symphony are you using? This blog post might shed some light on why there are so many: Squeezing more juice from Symphony queries

How does many queries effects on a performance of high loaded projects?

Not much. We’ve built relatively big sites (tens of thousands of users per day) which ran fine with standard Symphony data sources.

Is there any way to optimize/minify number of queries?

Optimise code as you would any other way: only query the data that you need and nothing more. One mistake Symphony users often make is using a single page for two purposes, sending different HTML depending on a URL Parameter. What they forget is that data sources for both views will be attached to the page and, if configured incorrectly, will execute and query on every page load.

The number of queries might look scary, but if you delve into them (append ?profile and you can see each one and the time they take to execute) you’ll see the majority are extremely simpe SQL SELECT which run extremely quickly. Quite often many granular queries perform cumulatively faster than one single big one.

this is not the problem of concrete version. this thing is in symphony philosophy that create a table for every section element. my question is not a real-project problem. just thoughts on a performance theme. You are reassured me with

Blockquote> Quite often many granular queries perform cumulatively faster than one single big one.

version of symphony was 2.1.1

I can reassure further and say that forthcoming Symphony 3 (in development) reduces queries further. While there will still be a table for each field within a section, the meta data of these fields are stored in XML rather than database tables, so the only queries that are needed are for content and not meta/schemas.

nick, is symphony 3 compatible with symphy 2.1 (2.2)? will there be a migration tool or smth to upgrade from 2.2=>3.0?

is symphony 3 compatible with symphy 2.1 (2.2)?

No, officially it won’t be, though it’s not inconceivable that a migration tool could be developed.

I’ve been spinning an idea about replacing the current query system with a (hopefully more efficient) system using JOINs for Symphony 3. All fields and most of the EntryManager and FieldManager stuff needs to be rewritten for that so it will never ever happen in Symphony 2.x. :-)

Brendan and I have discussed this at length before and decided that trying to boil a data source into a single query would never be flexible enough to work with the flexibility Symphony affords. But I’d be interested in talking it over with you and the Core WG sometime, as there are various different ways of approaching this.

I know I keep banging on about this, but would it be worth completely abstracting the DB functions at the same time? Not all clients want to go with a MySQL DB, and therefore can’t use Symphony… I think it’s a really important feature for Sym3, I was thinking like CodeIgnitor’s Database Class.

I’ll shut up now ;o)

would it be worth completely abstracting the DB functions at the same time?

Unfortunately, I think this is off the table at the moment. Sort of a ‘bigger fish to fry’ deal…

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