Symphony.

“Total Database Queries” appears to be under-reporting the total number of queries. My Data Source queries total more than 54, and the “Databaese Queries” tab lists 141 total.

Not sure whether this is a bug in the Profile devkit, or the way in which Symphony is logging queries.

A related issue (that I can nop longer replicate, bums) is that the “Total Database Queries” line has once before shown -1 running 2.0.8.

Attachments:

Screen shot 2010-03-24 at 13.04.34.png and Screen shot 2010-03-24 at 13.03.49.png

To confirm, this is a problem with Symphony core and not the Profile devkit. The devkit is simply rendering the information returned from Symphony’s getStatistics() and debug() MySQL methods.

Hmm, maybe more than one MySQL (Database) object is instantiated; and referencing $this->_page->_Parent->Database is a actually a different object to Symphony::Database().

In the Profiler, if I change this line the count is corrected:

$this->_dbstats = $this->_page->_Parent->Database->getStatistics();

to:

$this->_dbstats = Symphony::Database()->getStatistics();

Why would the count be correct for the static object and not for the other? I get 54 using the former code (incorrect), and 220 after (more correct, although I have no way of verifying).

Something is definitely wrong, because my DS list now shows one DS as using -2 queries!

Attachments:

Screen shot 2010-03-24 at 14.11.18.png

Nick, I’m curious to try and find a solution to this problem so have been taking a look at it.

What extensions are you using on the page with the differing query counts? My train of thought is that legacy extensions could still be using the $this->_page->_Parent database object instead of the static Symphony::Database(), which would result in the differing query counts.

Perhaps if the $_query_count variable was changed to static in class.mysql.php the counts would be the same regardless of how the class was instantiated?

Thoughts?

Perhaps if the $querycount variable was changed to static in class.mysql.php the counts would be the same regardless of how the class was instantiated?

Good idea. I think ill give that a go

http://github.com/symphony/symphony-2/commit/f45ef2b7cd6e3afef5e8c1a8693e96b87491e6e6

Make sure you git submodule update, since Profile Dev Kit was updated.

Sorry Brendan, I didn’t see your reply for more info.

It looks like you guys are on the right track, but this fix alone doesn’t solve the issue.

I made the $_log member static also, which started to even things out slightly. However numbers were still out. I discovered something new by printing this just after incrementing $_query_count in fetch():

echo(count(self::$_log['query']) . ', '  . self::$_query_count . "n");

One would expect both numbers to increment at the same rate, always remaining equal. What I found was that after between 50-100 queries, the $_log would be reset to 1, while $_query_count continued to increase. Even when both were static.

This led me to believe that the database object is being overwritten at some point. I traced this back to Symphony::initialiseDatabase() (class.symphony.php) and confirmed my suspicions that self::$Database = ... was being called mid way through the page load. I then changed the method to:

public function initialiseDatabase(){
    if (self::$Database) return true;
    ...

And query counts are now evened up.

So I believe that Symphony was opening up two database connections per page load. I’m not sure how. Surely initialiseDatabase() should only ever be called once? Since it’s called from within the Symphony::_construct method, does this mean other things like creating a new Profiler, Language, Configuration (etc) are also all happening twice per page load?

The database queries are now working (and unfortunately showing a large number of queries than before, since many were being masked/lost/hidden), but it still leaves this conundrum of multiple instances of Symphony and its database being created…

Ahaaaar! Solved. It was my Section Schemas extension foffing things up. I have to include class.administration.php in this extension since some fields make reference to Administration::instance() when I try to call their appendFormattedElement methods. But of course at the point I include class.administration.php it instantiates Symphony again, overwriting the static Database object, thereby buggering up stats.

I’ll move the inclusion of class.administration.php somewhere less obtrusive that the extension.driver.php, so that stats are only affected on pages using the extension.

Sorry ;-)

But still, I think the fix should be:

• make $_query_count static (which you’ve done)
• make $_log static
• add the check inside initialiseDatabase() just in case (?)

Pull requested.

http://github.com/nickdunn/symphony-2/commit/16c65e9d546d08fa75a97afe12b82a68194c6248