Query Cache v1.0

OK, went through file by file and found that some files just did not install. Now they are all in and - I see data but I also see this strange box at the top of the page
"[ Close ] Match queries (regex): "

It's Find Box for Query Log. I'll try to create screencast today to show how to use it.

It seems that Query Cache is working on Your site.

Parse Time: 0.770 - Number of Queries: 140 - Query Time: 0.26794561802673

Normally (without QC) query count would be around 500-1000.

It is working - thank you so very much. The funny thing is that I am not as interested in optimizing queries at this point as I was about seeing where my POST data was going. For some strange reason it was switching to the GET array and not coming back. Now I just test for the presence in either array and I'm good.

I suppose later I'll look at query optimization. For now, I truned teh display off since I don't need it just now.

I look forward to the next tutorial.

Roger

data_digger:

It's Find Box for Query Log. I'll try to create screencast today to show how to use it.

It seems that Query Cache is working on Your site.

Parse Time: 0.770 - Number of Queries: 140 - Query Time: 0.26794561802673

> Normally (without QC) query count would be around 500-1000.

Nice. Had one page go from 1813 queries to 262! I think it was so high because of a mod I have on that page. I'm on shared hosting so hopefully the cpu utilization won't be a problem, but I'll keep an eye on it. Thanks much for this!

Query Cache v1.6 can't install

1017 Can't find file: './hostname/zen_get_terms_to_filter.frm' (errno: 13)
in:
[select * from zen_get_terms_to_filter]

luxurywatches:

Query Cache v1.6 can't install

1017 Can't find file: './hostname/zen_get_terms_to_filter.frm' (errno: 13)
in:
[select * from zen_get_terms_to_filter]
It has nothing to do with Query Cache. Most probably someone (You, Your hosting company, some of Your scripts or hacker) changed permission to ./hostname/zen_get_terms_to_filter.frm and possibly other files. Check that MySQL has privilages to access the file (read/write).

Hi,

Im running zencart 1.3.8 .

Here are the parse times,

On localhost :

Before installing this Add-on
Parse Time: 0.721 - Number of Queries: 1574 - Query Time: 0.330065291428

After Installing the Add-on
Parse Time: 0.511 - Number of Queries: 370 - Query Time: 0.228095473282

On centralized Test machine ( higher load/more users/larger db)

Before installing this Add-on
Parse Time: 1.781 - Number of Queries: 1443 - Query Time: 1.17740702115

After Installing the Add-on
Parse Time: 2.140 - Number of Queries: 1426 - Query Time: 1.54411397633
Parse Time: 1.766 - Number of Queries: 1426 - Query Time: 1.21343658868

As you can see, localhost shows the drastic improvement but the centralized testing server shows negligible improvements.

I tried setting all combinations of QC_USE_PRODUCT_QUERY_DETECTION and
QC_ZEN_GET_CATEGORIES_PRODUCTS_LIST_PREFETCH but to no avail.

Any idea what could be going wrong ? :frusty:

Any help appreciated !

It seems that You haven't uploaded all files. Compare Your online store with files from distribution. Most probably You haven't uploaded

includes/classes/db/mysql/query_factory.php
includes/classes/query_cache.php

installing this module seems to have broken the encrypted master password module. any ideas on how to fix so they are compatible?

thanks

follow up. now seems entirely coincidental and unrelated.
pti.

Took my queries from over 5000 down to under 1000 so pretty dramatic loadtime difference.

THANKS VERY MUCH excellent work

We are using UTF-8 and have some problems with this module.

All charachters such as ü or đ, š, ć, č and similar are now shown as some weird symbols.

We tracked the problem to this part of the module on the shop side.

If you want to enable UTF-8 support to work properly in Zen-cart you have to add this part of the code around the line 37 in file Zen-Cart\includes\classes\db\mysql\query_factory.php

    if (version_compare(mysql_get_server_info(), '4.1.0', '>=')) {
		mysql_query('SET NAMES "utf8"', $this->link);}/* Changes for UTF-8 Support*/

right after line 37

  if (@mysql_select_db($zf_database, $this->link)) {

Does anybody have any ideas how to enable Query Cache and UTF-8 support?

Thank you very much for your supoort and this great module!

dionidis:

Does anybody have any ideas how to enable Query Cache and UTF-8 support?

Your solution does not work?

I promised to release new, more memory efficient version of Query Cache soon – unfortunately (or fortunately) it seems that PHP is quite good at managing memory and there’s not much to improve. Therefore version 1.7 of Query Cache will be delayed.

Request to Query Cache users:

If You use Query Cache and Your store is still slow and it’s not related to search script please contact me either on email, PM on Zen-Cart.com (data_digger) or by leaving comment. I’ll check Your site and try to make necessary changes in Query Cache v1.7 for You.

Ah I get it now. 1.7 is not out yet. I saw your website and was confused.

I will install this when I get home.

Hello,

I just installed your script. I had problems with attributes, as well known.

Situation:

This site is on a cloud hosting, so resources are not really a block. Remaining inside some range (that we may increase if needed whenever we want, in real time), we may 'move' resources a bit around and since it's cloud, it use resources as needed.

But of course there are some limits (and we didn't anything atm to investigate how is possibile to better tune mysql for example).

Well, I put some products with some attributes in the cart, obtaining these results:

Before query cache

Home page

query: 1156 query time: 0,3294 Parse time: 0,6650

Cart page (I already worked a bit on attributes flags to lower # of queries from around 13000 to 6600)

query: 6662 query time: 1,6375 Parse time: 2,3140

After query cache

Home page

query: 234 query time: 0,3178 Parse time: 0,5960

Cart page

query: 340 query time: 1,3861 Parse time: 2,0980

Consideration: in cart page we had a cut of 95% in # of queries. That's really great! More, that's incredible.

Unfortuntaley performances didn't improve so much (some test gave even worst results).

I tried checking server resources usage charts and it seems (a bit too early to see well on the chart) that we had a growth in memory and cpu usage (we already stress a bit cpu with url rewrite and other htaccess rules for performance gaining moving load from bandwidth to cpu).

Now I decided to put QC_USE_PRODUCT_QUERY_DETECTION false and things started goingi really well!

Home page

query: 285 query time: 0,1769 Parse time: 0,460

Cart page

query: 380 query time: 0,5018 Parse time: 1,0980

A bit increase of # of queries (irrilevant, but strange as you stated)

Good values for the situation. A bit strange that without this mod query time to execute 300 queries is something like 0,03 but with this mod, it becomes 0.17 / 0.5 (strange but sure it is so, since I made many reloads).

Results: this mod is great. Even in cloud hosting where ther's not a real block, we gained seconds. For us it's not a matter of server resources but user satisfaction. Now we'll work on parse time (I found an awfully made template...)

Thank you data_digger!

s_p_ike:

Now I decided to put QC_USE_PRODUCT_QUERY_DETECTION false and things started goingi really well!
Yep, as stated in read me file (You've read it, right? :P ) You should check if this switch speeds up or slows down Your site.

Thank you data_digger!
Thanks for feedback.

By the way, shopping cart page needs serious rewriting. It seems that the more distinct products customer adds to shopping cart the more time it takes to load the page. As far as I observed time to generate shopping cart page grows linearly by quite large factor with number of distinct products in shopping cart. With 20 products in shopping cart (not so uncommon in some sorts of online stores) it usually takes 4-8 sec to generate shopping cart page.

It depends on many many factors.

Attributes are the main reason for bad performances in cart page.

I didn't studied the growth of the number of queries but for sure, I too noticed that it increases quite in a linear way with number of products. It seemed (maybe) more than linear if there are more attributes for product.

Then, order_total modules have a role too

s_p_ike:

Attributes are the main reason for bad performances in cart page.

Yes. shopping_cart->calculate and shopping_cart->get_products() both perform queries inside of a loop that iterates through each product, and then another inner loop that iterates through each attribute for each product. That design makes them both very expensive functions from a performance standpoint. I managed to speed this up a little by implementing some (primitive) caching code in the shopping cart class. It also appears both functions are called needlessly (probably "just to be safe"). Hopefully Zen 2.0 will address the issue by moving to an object-oriented approach to products that will store the values in memory rather than needlessly re-executing queries.