We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 33983 ☆ A M B ☆
    • 181 Posts
    First let me say this, I am a big fan of MODX Revolution and in regards to page load time I think Revo out of the box is adequate for most sites as it uses advanced caching techniques and page load times are comparable or better than other MVC CMSs. But the more complex the site the longer time the page takes to load. This should seem like a no brainer as this is true no matter how you a develop website or what language you use, to do more will take more resources. Also for what I am about to propose to some the difference may seem small as to be pointless as I will be proposing a method that will trim anywhere from 1/3 of a second to 3/4 of a second from page load time from non performance tuned servers. But if you are running a complex site or have heavy traffic every millisecond is important.

    Hypothesis

    The largest remaining bottleneck for MODX is text processing. Creating a method to eliminate or greatly reduce text processing will enhance page load times and the created method will not affect how MODX is used in the MVC design.

    Every time you use a MODX tag, like [[*content]], MODX (really PHP) has to process those tags to properly to put in the content. The more tags you use the more time is required for processing.

    Example thought process layout

    • Create a method that preprocesses Templates, Chunks, TVs and Documents on Save and once saved MODX code is processed into PHP code and saved via the cachemanager.
    • When the page is loaded and calls on methods like getChunk() and getTemplate(), they first look for PHP code via the cachemanager and execute it. If no PHP code is found then it will process the MODX code and turn it into PHP code and then run.

    Proof of concept

    I have implemented this concept in a simple way for the Church Events Calendar extra. When doing my testing I was creating a year view and using the proper MODX methods of Chunks. This means that several Chunks are uniquely processed totaling more than 1200 times! My page load times where more than 2 seconds, to me that is unacceptable. Note my test server is not using APC, memecache or any other similar product. I wrote a very simple class called chunkToPhp. What the class does is covert a chunk in to a PHP function. The created function receives a $properties array and returns a string from concatenated PHP vars and the Chunk HTML. And the results for the Year view with the standard MODX Chunk method takes 2 to 2.3 seconds and when using the chunkToPhp class it is greatly reduced to: 0.8-0.9 seconds. I used firebug to view the time.

    Now the chunkToPhp class is very simple and will need to completely redesigned to incorporate input and output filters.
    The code: https://github.com/jgulledge19/Church-Events-Calendar/tree/master/core/components/churchevents/model/churchevents see chunktophp.class.php and mycontroller.class.php for how it is used.

    I would love to see this concept implemented in MODX but currently I don’t have the time to do devote to help fully implement this concept. I am hoping that this will inspire some more thought on to how to improve MODX.

    Post any comments or thoughts please. Thanks,
      • 18373 ☆ A M B ☆
      • 3,141 Posts
      I like how you're using this, but the first (criticial) thought comes to mind is - how does this compare in terms of performance to using a custom getChunk function as suggested in the Docs?

      See http://rtfm.modx.com/display/revolution20/Developing+an+Extra+in+MODX+Revolution#DevelopinganExtrainMODXRevolution-TheDoodlesclassgetChunkMethod

      One of the major (and for me deal-breaking) troubles with your code is that it doesn't seem to take into consideration output modifiers (for as far as I can tell from looking at the code, that is. I didn't actually try it out), and with that nested tags.
        Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

        Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
        • 33983 ☆ A M B ☆
        • 181 Posts
        Thanks for the comments Mark.

        1. Writing a custom getChunk() method as described in the Doodles examples does not change the issue I am addressing, text processing, but rather it allows for easy use of Chunks as files. In terms of performance it will have a very small increase in that you are reading from file verses reading from the DB. And if you use APC or memecache you might notice a slightly larger performance increase. Note you will have a large overall performance increase by using APC or memecache but the difference between one file and one simple DB call will be extremely small on a decent server. Also I am using a custom getChunk() method see: https://github.com/jgulledge19/Church-Events-Calendar/blob/master/core/components/churchevents/model/churchevents/mycontroller.class.php around line 125.

        2. The code that I wrote will work just fine with Output and Input modifiers as they would essentially be ignored and then processed via the MODX parser. This is really just a basic concept class that needs to be further expanded upon to convert Chunk calls, Snippet calls and modifiers to PHP. Or in other words mirror the MODX parse to make a MODX to PHP writer. Make sense?

          • 18373 ☆ A M B ☆
          • 3,141 Posts
          Re 1: While filebased tpls are one thing, it also "caches" the chunk to an internal array.. which I thought was something that modX::getChunk did not, though just checking the 2.2 source I seem to be mistaken there as that caches to modX::sourceCache..

          Re 2: if placeholders are only set using the getChunk('name',array('foo' => 'bar')) method, and not via modX::setPlaceholders(array('foo' => 'bar')).. then it definitely wont parse, plus from the looks of it it seems to just discard unset keys (replacing them with a php var in the script) so pretty sure it wouldn't even make it to the parser... I realize it's only a concept (and I must say an interesting one with those performance gains) but I think it definitely needs more refining.

          Definitely interesting in what the core team says of this!
            Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

            Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.