ZEN_CHECK_URL_GET_TERMS() should be a global???

v1.5.6a Logging the query to build my homepage I am seeing the database query used by (TRUE/FALSE FUNCTION ON URL) ZEN_CHECK_URL_GET_TERMS() run 6 to 7 times....

select * from get_terms_to_filter;

it would seem checking this once per page and then putting into a global might be a good idea to reduce the database queries by almost 10%???

It goes into the select cache automatically, so the query isn't really run again (typically) but instead internally pulled as part of the page load.

That at least is the case with select queries since about ZC 1.5.3. If it truly is desired for a query to be fully run again during the load (some reason that the response is expected to change), then the query's cache has to be cleared at latest of the point where the query is executed.

This 10% reduction in queries, is it based on review of the code or by execution of substitution type testing. E.g. Was an improvement seen by applying the recommended change and what were the results?

Hello! Thank you for your reply. I turned on the "Log Database Queries" to see what queries were being run and if there was anyway I could stop some from being run. So far I have only done the query for the homepage and when I examined the output it appears that the ZEN_CHECK_URL_GET_TERMS function is being called about 7 times because of the call to select * from get_terms_to_filter;

Would you mind directing me to the code that caches select queries?

The page is saying about 72-73 queries are being run .... so you are telling me that if the select query is run once and I am seeing more in the query log that those were just cached?

I am trying to figure out how to get my site above the 90% on the https://developers.google.com/speed/pagespeed as i think this might be important for SEO. Without my categories it scores 93-94 but with my categories it goes down to 87-88%.

I have the category counts turned off but notice that the counts are still occurring in the select queries according to the query log....????

Thank you!

shrimp-gumbo-mmmhhh:

Hello! Thank you for your reply. I turned on the "Log Database Queries" to see what queries were being run and if there was anyway I could stop some from being run. So far I have only done the query for the homepage and when I examined the output it appears that the ZEN_CHECK_URL_GET_TERMS function is being called about 7 times because of the call to select * from get_terms_to_filter;

Would you mind directing me to the code that caches select queries?

The page is saying about 72-73 queries are being run .... so you are telling me that if the select query is run once and I am seeing more in the query log that those were just cached?

I am trying to figure out how to get my site above the 90% on the https://developers.google.com/speed/pagespeed as i think this might be important for SEO. Without my categories it scores 93-94 but with my categories it goes down to 87-88%.

I have the category counts turned off but notice that the counts are still occurring in the select queries according to the query log....????

Thank you!

Follow the code flow in includes/classes/db/mysql/query_factory.php for the Execute method. As it is executed, it should lead to answers at least to the what is going on in the background and how data is being treated. As to differences based on various options included/excluded there are a number of factors involved.

The query logging (file for future review) receives each of the select queries requested regardless of whether it is cached or not. This can be a beneficial tool when debugging or reviewing what is happening.

When you get down to $zp_db_resource = $this->query, the code then goes to the query method where it checks to see if $queryCache has been set (the core load process initiates the variable) and checks to see if the query is in the cache. If it is in the cache then it uses the previous result, if not then it asks the database and then logs (caches) the query.

While there may be some "improvements" in there, I would think that the issue lies elsewhere than the interaction with the database as in what is being asked of the database and any other associated software of concern.