Modx so slow

Hey guys.

We are having serious performance issues with modx right know. So maybe somebody can help us with speeding up that thing.

So here’s the deal: i make a blank page with no template only with debug code:

Parse time is about 0.2 - 0.4 seconds which is okay.

Then i put the same code one of our templates, erase it from the resource and assign the template to the resource. And whaaaaaam - loading time beetween 0.8 and 1.2 seconds! For a blank page???


Anyone any ideas what’s the deal with that?


P.S: addidtional infos:
We have a large number of resources 10000+, so far 41 TVs but only one assigned to template i did the test with.
We are running on Revo 2.0.4 (planning to upgrade to newest version very soon)

Definitely upgrade, and also paste us a link to a pastie with your template code. If you have uncached snippet calls on it that’s most likely the call. The content shouldn’t add time, but an uncached getResources or Wayfinder call can add to the time for sure.

the template is empty... no code. That’s the issue. I somehow think it’s cache related because the second call on it is much faster. But i wonder what can be cached on an empty template or why it takes so long to cache an empty template.

No without knowing about your server, environment, etc. See the red text above the post button when creating a new topic.

Does your template have a link to a favorites icon that doesn’t exist? This can slow things down as well as add a huge amount of lines to your error logs.

No the template is really empty no html - nothing.

To the system:
It’s running on 3 different environments. All suffer the same problems. One is a Windows, two Linux (Ubuntu). On the Windows machine we have a Zend Server CE (not entirely sure right now: 5.0.3 or 5.0.4) on the Linux we are running Apache 2.2.14. The PHP versions are 5.3.* ones and MySql 5.1.41, pdo is installed.

Because we are facing the same problems on those environments it may not be environment related.

But as i said, if the site comes cached it is fast. But the problem is the first call. I therefore suspect the caching process (because i tested it on a blank page and template). Maybe some caching settings not set properly? Anyway, we need to clear the cache from time to time and cannot affort long loading times even on the first call.

Hopefully tomorrow i’ll be able to analyse the profiler data to identify the processes that are slowing down the whole thing.

Okay... i analysed the xdebug output and, as i guessed, it seems to be the cache!

a single call of modCacheManager->generateContext() is using 700ms! Far too much. Anyone an idea what slows down the cache?

Yes, but that method is only called to regenerate the cache after it is cleared, and improvements are coming to this process. It is expensive because all of the friendly URLs are calculated into the context cache when it is generated. The next minor version of Revolution, 2.1.x, will move this calculation to the Resource save process so the context cache can be generated in a single query. It will also reduce the size/memory usage of the context cache.

Thanks for your reply. Figured that out by myself - actually it affected development environment because we cleared the cache very often. Because it is cached only once i think those 700 ms are okay but, as you said, would be a lot better if done at another place.

Generally our perfomance problems (on non empty) sites had other reasons. One of the main reasons was that we seemed not to understand the concept of the chunks prefectly. So we had some chunks called from other chunks and also snippets called from within chunks. That resulted in an enormous amount of collectElementTags and processElementTags calls - affecting performance in a very negative way. We restructured everything and performance was enhanced a lot.

The second problem is related to caching. Because elements that appear on every page seem to be cached only for every single page, not for the whole site (sometimes that makes sense tough, but for some elements this was not desireable). So for some of those elements we use a custom caching process now.