Performance Optimization Via Conditionals and getResources

I am trying to optimize performance of a site running on Revo that uses both conditionals and getResources for content presentation.

First, conditionals.

The site is small, so it was easy to use conditionals while leveraging a single template.Hence, in my main template are the following conditionals that pull in the main content of each page, by id (I do the same thing for the sidebar):



Two questions about this approach:

First, is the formatting optimal, meaning:
I got it from Jason Coward's post (http://modx.com/blog/2012/09/14/tags-as-the-result-or-how-conditionals-are-like-mosquitoes/), but scenarios it addresses are a little different than mine, so I'm unsure as to whether there's a benefit for my site based on the usage above?

Second, does the processing this approach requires hit page load speed to an extent that customized templates per page would be better? Maybe on a site this small, doing the latter is more viable?

getResources
After reading a few posts about getResources, I've adopted the wisdom of filtering as much as possible, and ordering properties deliberately.

Below is a sample getResources call that appears throughout the site in question, with similar properties in each instance.



Questions:

1. Is the order of the properties tweakable to further aid optimization?
2. Would a property set speed processing, or is this solely a dev efficiency?
3. Does specifying the template, when applicable, help limit the processing (assume yes, but worth asking)?
4. The site is flat, with a max depth of 1. In this scenario, does specifying depth aid processing speed, or is that case only when depth exceeds more than one level?

Thanks -- I hope any answers given here can help others as they utilize these great options!

This would be infinitely faster than your conditional and possibly easier to maintain:






You could make it a little faster yet by naming the chunks with the IDs (with a duplicate for # 11) and just doing this:



About getResources (good questions):

1. Is the order of the properties tweakable to further aid optimization?

No, it won't make any measurable difference.

2. Would a property set speed processing, or is this solely a dev efficiency?

No, it would slow things down slightly.

3. Does specifying the template, when applicable, help limit the processing (assume yes, but worth asking)?

Yes, if it reduces the number of resources retrieved, especially when TVs are involved.

4. The site is flat, with a max depth of 1. In this scenario, does specifying depth aid processing speed, or is that case only when depth exceeds more than one level?

It shouldn't make any appreciable difference.


All that said, the things you're contemplating are pretty trivial compared to the inherent sluggishness of using getResources with TVfilters. For a small site, it won't make too much difference, but if the site will grow, you can speed things up by an order of magnitude by ditching the TVs, extending modResource, and moving the data to a custom DB table.

More information here: http://bobsguides.com/blog.html/2014/06/02/why-extend-modresource/ and here:

BTW, I just reread the first part of your question and am wondering why you are putting the "page content" in chunks, rather than directly in the page content field, which would be much faster and easier to manage. It will appear wherever you put this tag in the template:

Quote from: BobRay at Jun 20, 2014, 02:23 PM

This would be infinitely faster than your conditional and possibly easier to maintain:

[[!SelectChunk]]

/* SelectChunk snippet */
$id = $modx->resource->get('id');

switch ($id) {
   case 1:
      $chunk = 'myChunk1'
      break;

   case 2: 
      $chunk = 'myChunk2'
      break;

   case 3: 
      $chunk = 'myChunk3'
      break;


   case 5: 
   case 11:
      $chunk = 'myChunk4'
      break;
 
   default:
       $chunk = 'myChunk?"

}

return $modx->getChunk($chunk);

Awesome. If I pull this off, it'll be my first snippet (though not really, I suppose). I'll give it a shot!

Quote from: BobRay at Jun 20, 2014, 02:23 PM

You could make it a little faster yet by naming the chunks with the IDs (with a duplicate for # 11) and just doing this:

[[$myChunk[[*id]]]]

This has been implemented -- thanks.

About getResources (good questions):

1. Is the order of the properties tweakable to further aid optimization?

No, it won't make any measurable difference.

2. Would a property set speed processing, or is this solely a dev efficiency?

No, it would slow things down slightly.

3. Does specifying the template, when applicable, help limit the processing (assume yes, but worth asking)?

Yes, if it reduces the number of resources retrieved, especially when TVs are involved.

4. The site is flat, with a max depth of 1. In this scenario, does specifying depth aid processing speed, or is that case only when depth exceeds more than one level?

It shouldn't make any appreciable difference.


All that said, the things you're contemplating are pretty trivial compared to the inherent sluggishness of using getResources with TVfilters. For a small site, it won't make too much difference, but if the site will grow, you can speed things up by an order of magnitude by ditching the TVs, extending modResource, and moving the data to a custom DB table.

More information here: http://bobsguides.com/blog.html/2014/06/02/why-extend-modresource/ and here:

I will read this, for sure. This probably exceeding my skill level...but I have a photography website that could benefit from this, so I'll dig in...

And, to your follow-up question -- it's not just "content", per se. It's everything that makes each the page unique -- sections, subsections, etc. Given this, would the content field still be a better approach?

There's no simple answer. The more you put in the page content field, the faster things will be, but sometimes at the cost of structure and maintainability.

The general principle I follow is that if it's something I'd have to change on many pages if I redesigned the site, it goes in the template. If not it goes in the page content field or in TVs.

BTW, if some content is unique to a page, but you don't want to put it in the 'content' field (often because you'd like to place it somewhere specific), it usually goes in a Template Variable (TV) rather than a chunk (though extending modResource may be a better option). TVs hold specific information for specific pages.

Ultimately, you can put resource data almost anywhere (custom DB field, resource field, TV, chunk, plugin, snippet, etc.). The optimum place for everything depends on the site and how it operates.

For example, TVs are very convenient for Manager users, but very sub-optimal if you will need to search or sort resources on the basis of their content.

pdoTools with its pdoMenu and pdoResources snippets performs better than getResources and Wayfinder.

Quote from: sottwell at Jun 20, 2014, 03:27 PM

pdoTools with its pdoMenu and pdoResources snippets performs better than getResources and Wayfinder.

Does it have documentation, available properties the same?

Quote from: wpicotte at Jun 20, 2014, 03:41 PM

Quote from: sottwell at Jun 20, 2014, 03:27 PM

pdoTools with its pdoMenu and pdoResources snippets performs better than getResources and Wayfinder.

Does it have documentation, available properties the same?

Yep http://docs.modx.pro/en/components/pdotools/general-settings

The pdoMenu docs are also in English. But 99% of the properties are the same as getResources and Wayfinder.

If you haven't already seen Ryan's recent post regarding MODX Performance (http://modx.com/blog/2014/05/29/seven-ways-to-make-modx-fly/), I would recommend checking it out. There are some great performance tips, and while you can find most throughout the forums it does bring a lot of them together. I've added a few of my own notes regarding those suggestions:

1 & 2 - pThumb does a great job with image handling, but enabling the pThumb Cache and Resizer usage (System Settings > phpThumbOf Filter) makes it even better in my book. I've not had an issue with it's Cache Manager personally, but disabling it can help for image heavy sites.

3 & 5 - There are security and performance benefits to using a current PHP release (ex: 5.4.27+), granted your host is responsible for handing these upgrades. Opcaching (APC, eAccelerator, xcache) also falls under your hosts domain, and isn't something you typically see in shared hosting environments. There are some security risks using it on a shared environment, so MODX's usage is a little surprising.

It's great to see SPDY supported more, however it's worth noting it only affects SSL connections at this time. Translation there is little to no benefit supporting it for most sites.

In regards to pagespeed, it can improve your sites performance, however it does rely on your server to make those changes. I would recommend making the changes manually instead of relying on the server, the more work the server needs to do on the fly the longer it will take. Additionally, this isn't something found with all hosting providers at the moment.

__________

Getting back to the code, you can also benefit from more efficient extras such as pdoTools as Susan noted. Regardless of the extra's efficiency caching is also an important part of the equation. The less work required of the server the faster your site will load, so don't forget to give caching a good look.

JP has a great writeup on caching here: http://devries.jp/blog/2013/03/23/cash-in-big-with-modx-cacheing/ I would focus on getCache personally.

Another website performance friend is your .htaccess file, you can do some cool stuff for example: https://gist.github.com/amdbuilder/522c3c79a54cd1c90f7c (DON'T USE WITHOUT READING WHAT STUFF DOES FIRST!!)

Hope that helps you some