Symphony.

Hi!

It was found that each field in the section, producing an average of 3-5 requests to the database. Even a simple record containing three fields of type "Input", produces 13 queries (!).

How can we optimize the number of queries to the database? Please, express your thoughts in the comments.

For example, you can edit the data source manually.

Write their own queries to the database using the "left join", "inner join", etc. However, the data source is obtained by hard-coded for specific tables in the database.

Are you seeing real world performance issues from this situation?

A good idea with any heavily used Data Source is to employ caching of the Data Source in question. 13 queries is not that many given the dynamic nature of Symphony's Data Sources, but if Symphony only has to make that query once every 5 minutes rather than on every request, things will be much smoother.

If your Data Source is including counts of entries in other sections, turning that off will reduce the query time.

Thank you very much for your feedback tonyarnold!

I do not think this is a problem. This architecture Symphony. But I'm looking for ways to optimize it, and invite other developers to share their ways.

When using multiple sources of data related to each other, the number of requests increased to 100. Of course, this very well to caching.

I'm thinking of extension, which should optimize the data sources. At this time, the data source dynamically calculates the types of fields, data tables, etc. This leads to an increase in the number of requests. Extension will process the data source, switching it to "static" (hard code) mode.

@tarakanoff

Extension will process the data source, switching it to "static" (hard code) mode.

Interesting ... I wonder what @brendo and @nickdunn have to say about this.

It's probably worth mentioning that there has already been work done for Symphony 2.3 that optimises the discovery of fields and sections which would probably negate some of your effort. If you're interested in these changes checkout a copy of the integration branch and have a look around!

Have you looked at other methods of caching through Cacheable Datasource (which essentially makes your query count zero) or Cachelite (caching the page output) extensions?

Thank you for your comment brendo!

I always look new changes. And very happy!

Of course, I looked at all the available extensions (for caching). But, here's an example. Frequent changes of multiple data sources, which are displayed on the main page. The cache is cleared. There will be a "wave" of database queries. I would like to optimize this critical moment.

If you dynamically change the data sources is not essential, then why not make them static? You can do the switching operation of the source data. Dynamic (for a change in control panel) and static (changes are prohibited, some queries are combined into one).