Search

XML built time is 8.5 sec is it possible to reduce it anyhow. Thats too bad I should say.

Engine Initialisation   0.0089 s 
Page creation process started   0.0180 s
XML Built   7.2418 s
XML Generation  0.0175 s
Page Built  7.3087 s
XSLT Transformation 0.0587 s
Page creation complete  7.3854 s

cat_list    0.0487 s from 45 queries
current_cat 0.0260 s from 28 queries
current_subcat  0.1171 s from 31 queries
subcat_list 0.0372 s from 44 queries
interview_list  0.9933 s from 267 queries
lection_list    2.1663 s from 279 queries
video_statya    8.8980 s from 1261 queries

Total Database Queries  1996
Slow Queries (> 0.09s)  3
Total Time Spent on Queries 2.5428 s
Time Triggering All Events  0 s
Time Running All Data Sources   8.6331 s
XML Generation Function 0.0156 s
XSLT Generation 0.0302 s
Output Creation Time    8.7432 s

Something I do if a datasource is really slow is output it in a page as pure xml, and import it again in a new datasource as a dynamic xml source.

You can use this datasource in a page again where the caching of the dynamic xml really helps lighten the load.

And you could try these extensions of course ;)

can you explain the prosess of that when its pure xml imported dymanycally it’s still implemented when demanded by the second data source… or is it cached or whatever… cant get how it works on th whole…

how can i filter i then? cant get the whole idea

Looking at the profile, your bottleneck is:

video_statya 8.8980 s from 1261 queries

Some questions:

  • What are you using this DS for?
  • How many entries is it producing (how big is the XML).
  • Do you need all those entries in the XML?
  • Have you considered caching solutions?
  1. thats an article but i combines several outer sections with mediathek.
  2. the number of entries is five after ds filtering
  3. i have cut it up completely
  4. not yet though hope it will help

Can you post the XML the video_statya is producing? 1261 is an awful lot of queries! If Mediathek is using this number of queries for something simple then we need to do something about it.

And what version of Symphony are you using? Symphony 2.0.7 cuts down the number of queries in certain scenarios.

But seeing the XML should shed some light as to why this DS is so slow.

Just a quick note: CacheLite does not work with Symphony 2.0.7RC1. I posted a bug in the issue tracker but so far no joy.

1261 is an awful lot of queries!

Sure? In my experience this is not unusual as soon as you are using section links and chained datasources.

I would assume that this is a memory/processing power problem. See this thread.

@dougoftheabaci: Sorry, hadn’t seen that issue (there are no notifications for extension issues), I’ve posted a response.

@michael-e: shared hosting is just what i use for development version and I DO HOPE that moving from shared to VPS or rather dedicated will improve performance

Don’t know how to use this text field!!!! Cant post xml as it gets messy view..

Don’t know how to use this text field!!!! Cant post xml as it gets messy view..

You can always use Pastie or Gist if things break.

Yikes, yes I think having 5 Mediathek fields per entry is what’s doing this. Out of interest are you using 2.0.6 or 2.0.7 RC1? If 2.0.6 would you be able to clone your site and update to 2.0.7 RC1 and see if this makes a noticeable difference?

If moving to your VPS doesn’t make a discernable difference then I’d recommend caching of some form. The Cacheable Datasource code works pretty well.

  1. 2.0.6
  2. Some questions concerning upgrade. Howto? What about extensions (i use quite many) shell I do it manually or at least something can be updated automatically?
  3. I’m not sure that moving to vps will take place too soon at least i should get production version first.
  4. I use mediathek as very convenient means to add entries to other sections being inside the current section, simultaniously having the ability to choose throughout the whole range of entries already added. Maybe there’s any other way to get such functionality? But I have already asked such question and got no answer. That’s very important i should say… As 1200 queries multiply by 1000 users eaquals = 1000 000 just for one DS. But thats crazy to make person fill several sections before filling the main one. Being frontednd dev for rather high loaded project 720 - 740 Alexa rank I should say that our index page demands just 100 queries, considered to be a lot… Maybe I get something wrong.. but that makes me get stuck..
  5. Caching is ok but first the task is to reduce the munber of queries. What is the way symphony works with database? Does it produce query for every section field? I should have asked or read about that before, i think. So that i could build up better project architecture… Please share your ways of ds and architecture planning…

  6. @nickdunn Off-topic: can you share your experiments with lemonstandapp if you can please contact me through ibcico[at]gmail.com

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