Timing tags in Revolution

Do the "timing" tags exist in Revolution?

I’m looking for the Revo version of the following Evo tags:

[^qt^] - Query Time - Shows how long MODx took talking to the database
[^q^] - Query Count -Shows how many database queries MODx made
[^p^] - Parse Time - Shows how long MODx took to parse the page
[^t^] - Total Time - Shows the total time taken to parse/ render the page
[^s^] - Source - Shows the source of page, whether is database or cache.

I tried [[^qt]] etc but it doesn’t output anything.

Thanks.

Oops never mind - the tags are still the same; they don’t appear to have been converted to the Revo tag format.

Do they work properly in Revolution?

I always get the following output:

0.0000 s - Query Time - Shows how long MODx took talking to the database
0 - Query Count -Shows how many database queries MODx made
x s - Parse Time - Shows how long MODx took to parse the page
x s - Total Time - Shows the total time taken to parse/ render the page
database - Source - Shows the source of page, whether is database or cache.

Parse and Total Time are always equal. Query Count and Query Time are always 0 (even after clearing the cache?!?) and Source is always "database" although I use caching.

It’s very important for me to find the performance bottleneck. Because our (very simple) MODx site is very slow and I need to know why to be able to complain to our hosting provider.

Quote from: Jakob at Nov 17, 2010, 11:45 AM

Do they work properly in Revolution?

They do indeed work fine for me in Revo 2.0.4-pl2. I haven’t got access to my system at the moment so I can’t give you a sample, but it’s something like this in my template:

<!-- modx - database: [^qt^], [^q^] queries, application: [^p^], total: [^t^], source: [^s^] -->

which outputs something like:

<!-- modx - database: 0.384s, 18 queries, application: 0.409s, total: 0.793s, source: database -->

or after caching:

<!-- modx - database: 0.000s, 0 queries, application: 0.301s, total: 0.301s, source: cache -->

Incidentally I did spot on the tracker that a future version of modx will convert these tags to the Revo format.

They sort of work, but the database query count and time is wrong; the problem is that not every query in Revolution goes through a mechanism where the query time can be calculated. In fact, most of them cannot be traced the way the DBAPI did for various reasons. This may be addressed in the future, but for now, you’ll have to live with inaccurate results for the db queries.

Quote from: OpenGeek at Nov 25, 2010, 03:14 PM

They sort of work, but the database query count and time is wrong; the problem is that not every query in Revolution goes through a mechanism where the query time can be calculated. In fact, most of them cannot be traced the way the DBAPI did for various reasons. This may be addressed in the future, but for now, you’ll have to live with inaccurate results for the db queries.

Thanks Jason. I must say, I did wonder, particularly as I have some uncached snippets which do call the database and these queries aren’t reported on a cached page (the chunk that hosts the timing tags is also called uncached, as it recognises the switch between cache/database.)

Quote from: OpenGeek at Nov 25, 2010, 03:14 PM

They sort of work, but the database query count and time is wrong; the problem is that not every query in Revolution goes through a mechanism where the query time can be calculated. In fact, most of them cannot be traced the way the DBAPI did for various reasons. This may be addressed in the future, but for now, you’ll have to live with inaccurate results for the db queries.

Is there any update on this?
Knowing the number of queries and the times etc would be very useful for debug info.

Quote from: jusmeig at Apr 05, 2011, 02:59 PM

Quote from: OpenGeek at Nov 25, 2010, 03:14 PM

They sort of work, but the database query count and time is wrong; the problem is that not every query in Revolution goes through a mechanism where the query time can be calculated. In fact, most of them cannot be traced the way the DBAPI did for various reasons. This may be addressed in the future, but for now, you’ll have to live with inaccurate results for the db queries.

Is there any update on this?
Knowing the number of queries and the times etc would be very useful for debug info.

No, unfortunately there is no way to intercept all possible queries without creating significant overhead, at least not that I have found yet. Use a Snippet solution like Executioner and/or MODX logging to capture information on how long specific queries are taking during development.

Hi,
My home page is generating 250 queries if this is reliable?



I'm using Migx and getResources.
Does this look right? I have about 230 more queries than i should have. I use [[include? &file=`assets/templates/index.php`]] to call my template if it matters?
How can i lower the queries. is there some cache feature I'm missing?

Running an apache bench test returns good times?




Thanks

If your getResources calls include TVs, that can add significantly to the number of queries, especially if the TVs have @ bindings or hold the default value because GR needs to make at least one more query for each TV for each resource. Even if the TVs don't contain those values, just having TVs in the mix can make for additional queries.

I have a blog post coming out in a day or so on why this is the case and offering a possible solution.