MODx Benchmarks with Xdebug

If you are interested on how MODx benchmarks using Xdebug compare to others please visit this link:
http://opensourcecms.com/index.php?option=com_simpleboard&Itemid=166&func=view&catid=10&id=7546

Thanks

That’s interesting stuff chanh, but certainly not any kind of useful real-world benchmark. There is nothing indicating that the pages being rendered are similar in content, number of front-end feaures, etc. It’s also misleading in our case, because the manager pages (I guess this is viewing manager pages, based on rendering time and description of the test) are not rendered by the MODx parsing engine and are in fact proprietary php pages, unlike many of these others. A more accurate test might be to have a user login to manager and then test various front-end pages rendered by the parser, or just front-end page rendering benchmarks without login. Both are very important benchmarks to our true scalability.

The good thing is, I’ve never seen it take that long to render front-end pages in MODx, ever! And in fact, the default home page renders in ~0.2 to 0.4 seconds uncached on my 5.0.4 Windows/XAMPP environment the first time, and ~0.1 cached. And PHP 5.1 is supposed to be a huge performance increase over 5.0.x.

Moving forward, as part of a set of standard sanity checks, we should add some standard performance stress tests and produce KCacheGrind reports that we can all review to find places that need optimization during the release test cycles. I’ll look into getting this setup. This kind of data can help us further improve MODx and attract more professional-level adopters.

Hemm.... I thought that phorum will be the winner in this case, but it seems that it’s being graded way below. I’ll try to check on this on phorum forum I guess.

As far as MODx, we need a lot of tweak in the core. Believe me, most of the API is not being optimized to be called multiple time by snippets/plugins. We might need another layer of caching, other than just output caching. Maybe in the next release, before we reach 1.0, we need to revamp the database layer and added data caching on that part. So when resources need to use that API basically they get the best performance out of it as well. My only concern will be, what’s the limit to decide when we start needing data caching, considering that mysql is a fast database, even for multiple data access back and forth. So the whole question will, by adding data caching will it be more efficient or not.

Quote from: Djamoer at Mar 18, 2006, 06:11 PM

As far as MODx, we need a lot of tweak in the core. Believe me, most of the API is not being optimized to be called multiple time by snippets/plugins. We might need another layer of caching, other than just output caching. Maybe in the next release, before we reach 1.0, we need to revamp the database layer and added data caching on that part. So when resources need to use that API basically they get the best performance out of it as well. My only concern will be, what’s the limit to decide when we start needing data caching, considering that mysql is a fast database, even for multiple data access back and forth. So the whole question will, by adding data caching will it be more efficient or not.

@djamoer: First, we already use various data caching techniques, not just content caching. And the MODx OO API using a very lightweight PDO implementation, with brand new data model, parsing engine, and caching system, as well as featuring no eval() calls (see the coverage of eval in the benchmark graph), is already being coded, as we speak. I predict already that it’s going to slash the size of the core and the front-end page rendering times in half. Manager page rendering may be another story altogether, but one that is also being addressed with current development activities.

Thanks Jason for clarifying that. But as far as my knowledge about the code, I did not see any data caching being implemented, other than all the snippets, plugins, chunks, and etc is being cached. But the site content and tv is not being cached, other than when they are being rendered as a whole page. I might be wrong though.

Talking about eval, I still see that plugins and snippets are still being evaluated with eval. Is it for the future release, or it’s already been implemented on 0.9.1? Sorry, I might not know about the current progress that we have, all I did is just judging from the core code on 0.9.1.

With regards,

keeping an eye on the tech stuff though I wouldn’t be able to participate in the debate... interresting Chanh, this kind of thing will undoubtedly raise up in discussion of comparative performance with other CMSes...

Thanks !

@Chanh : I think Riklaunim does have an association with RkCMF2, he is listed as main dev on RkCMF2 Sourceforge page...