3.3: final preparation and performance

Chanh,

Thanks for posting that. Could be very insightful I think! Couple of questions:

1) Are the various xdebug_blahblah.txt files reports on various pages or something else?

2) When you see a line like:

0.0423722267    24    mysql_query()    \manager\includes\extenders\dbapi.mysql.class.inc.php:79

Does that mean the .04x seconds was repeated 24 times, or is the 24 (number of calls) line time a total of all the calls?

Regardless, looks like we’ve got some interesting things to consider for optimization:

Execution Time Profile (sorted by execution time)
-----------------------------------------------------------------------------------
Time Taken    Number of Calls    Function Name    Location
-----------------------------------------------------------------------------------

1129446558.7695980000    1    *documentparser->log()    \manager\includes\document.parser.class.inc.php:539
0.3428461552    1    *{main}()    \index.php:0
0.2083690166    1    *documentparser->executeparser()    \index.php:101
0.1842479706    1    *documentparser->outputcontent()    \manager\includes\document.parser.class.inc.php:1044
0.1814990044    1    *documentparser->invokeevent()    \manager\includes\document.parser.class.inc.php:437
0.1805019379    1    *documentparser->evalplugin()    \manager\includes\document.parser.class.inc.php:1987
0.1792690754    1    {eval}()    \manager\includes\document.parser.class.inc.php:644
0.1621170044    1    *output->mergelinks()    \manager\includes\document.parser.class.inc.php(644) : eval()’d code:78
0.1565489769    1    *documentparser->postprocess()    \manager\includes\document.parser.class.inc.php:0
0.1023380756    10    *documentparser->gettemplatevar()    \assets\modules\quick_edit\contentVariable.class.inc.php:65
0.0989408493    10    *documentparser->gettemplatevars()    \manager\includes\document.parser.class.inc.php:1562
0.0839047432    7    *contentvariable->set()    \assets\modules\quick_edit\output.class.inc.php:130
0.0680510998    1    *documentparser->documentparser()    \index.php:89
0.0677330494    1    *documentparser->loadextension()    \manager\includes\document.parser.class.inc.php:25
0.0590798855    12    *documentparser->getdocuments()    \manager\includes\document.parser.class.inc.php:1214
0.0528759956    23    *dbapi->query()    \manager\includes\document.parser.class.inc.php:137
0.0423722267    24    mysql_query()    \manager\includes\extenders\dbapi.mysql.class.inc.php:79
0.0383169651    1    *documentparser->useragent()    \manager\includes\document.parser.class.inc.php:2367
0.0376267433    3    *contentvariable->set()    \assets\modules\quick_edit\output.class.inc.php:181
0.0365419388    1    *documentparser->match()    \manager\includes\document.parser.class.inc.php:2609
0.0345547199    8    *documentparser->getdocument()    \manager\includes\document.parser.class.inc.php:1581
0.0303790569    1    trim()    \manager\includes\document.parser.class.inc.php:2585
0.0195620060    1    *documentparser->getsettings()    \manager\includes\document.parser.class.inc.php:895
0.0128221512    10    *documentparser->getsettings()    \assets\modules\quick_edit\contentVariable.class.inc.php:171
0.0124876499    7    *contentvariable->checkpermissions()    \assets\modules\quick_edit\output.class.inc.php:133
0.0121538639    2    *documentparser->getdocument()    \manager\includes\document.parser.class.inc.php:1581
0.0108571053    1    *documentparser->getdocument()    \assets\modules\quick_edit\contentVariable.class.inc.php:99

Ryan,

Yes, I turn on the profiler and start clicking on a different page to collect the number.

Yes, I would tend to agree with your conclusion on how to read the number.

I hope it will be hefpful on tuning Modx.

As I was looking through the code I also found many instance of "var" will is "deprecated" in future version of PHP. It suggests to use "private/public/protect" rather than "var"

I also notice there are LOT of call to "trim". Is there a way to reduce number of call to "trim"?

There’s definitely the need to do a little work on tuning and optimizing MODx as best as possible. There’s likely to be areas in the functions themselves where we can streamline the processes and cut down on parsing time.

In regards to the deprecated "var" instances...I agree. Especially from an object-oriented point of view, it’s probably best to label all variable calls as either private, public or protected depending on its use within a given function or class.

The most logical way to cut down on the use of "trim" is to use it only when saving a string to the database. There really should be no reason to have to use a trim on data that already exists. The more proper use of trim is for data integrity before a string is even saved to the database. We might have to look at little things like this too while optimizing MODx.

Quote from: chanh at Oct 17, 2005, 09:47 AM

Yes, I would tend to agree with your conclusion on how to read the number.

Ahhh... I don’t have a conclusion yet. It can either be a sum of all calls (which I sorta suspect it is) or it can be the average of the number indicated. I hope it’s a sum. Regardless, seems like we could do som array manipulation in order to extract better performance vs. repeated calls.

I hope it will be hefpful on tuning Modx.

I suspect it very much will be!

As I was looking through the code I also found many instance of "var" will is "deprecated" in future version of PHP.  It suggests to use "private/public/protect" rather than "var"

This is a PHP5 vs. PHP4 thing. What is the best way to maintain backwards compatibility with older PHP versions?

I also notice there are LOT of call to "trim".  Is there a way to reduce number of call to "trim"?

I noticed that too. Will be interesting to see if one of the coding-enabled folks comes up with some suggestions.

If we want to make MODx feel really responsive I think we should strip out the core stats and use a stats module (is Mark’s ready to go?) that is turned off by default. If I’m reading the profile correctly then the log is taking an enormous amount of time. I know from experience that the logging can cripple a busy site.

I know we’ve talked about this in the past but maybe it’s worth doing for 3.3. I doubt that it will take too much work.

Mark’s is close to ready, but should be as soon as the other Marc (of the stats making fame) does a release "any moment now"

I would like to see this also; I would like a basic counter module, to start with. Most people only want that kind of "tracking", and with what we have now it’s "all or nothing". I’ve been thinking of making a simple snippet to just keep a count in a text file. I wonder which is faster, open a text file, read the integer, add one to it, write it back, or use a database "update blah set x = x+1"?

Quote from: sottwell at Oct 17, 2005, 01:37 PM

I wonder which is faster, open a text file, read the integer, add one to it, write it back, or use a database "update blah set x = x+1"?

Initially it could be slower but it would definitely be faster in the long run. The problem comes when you have megs worth of table data to wade through everytime a page is viewed.

I am waiting for SlimStat v0.6 by Stephen Wettone since there is an error with the db install sql in v0.5. My version runs (not entirely in MODx though ) but required an extensive workaround install.

He said it should be out in the next few days. So unless TP3.3 can wait AT LEAST a week it won’t be ready.

As for a counter: there are hundreds of free scripts out there that do exactly what you describe that could easily be integrated (we’re talking minutes).

As for which is faster, db or flat file, I have no idea. But a word of advise: for very basic tracking (only # of visitors) JUST UPDATE THE FILE OR DBLINE!

I integrated Slimstat into my Mambo sites and after a few month it kill my server! My site was so sluggish that is not usable so I have remove it from my sites.

I have used several stat collection over the year and I must say none of them are as good as the cpanel awstats or any of the different flavor. It has no impact to the site performance!

I am in agreement with Susan that there should be some really simply stats to be collected like the hit counts and that should all is need in my opinion.