Query Cache v1.0

[s_p_ike]

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

[Tick]

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.

[DrByte]

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.

As has been stated elsewhere, it does.

[damiantaylor]

Thank you for this great mod!
I have a question......my web host has switched mySQL query cache on.
Will this mod cause any conflict?

[kelvyn]

WARNING: There is a conflict between Query Cache 1.6 (download / official forum / zen support thread) and Google Base Feeder ( download / official forum / zen support thread )

It took quite a few hours as well as support tickets to my host who gave up in the end! But starting from a clean install this morning, and putting things back one by one, I've arrived at the answer this afternoon :)

Well, here we are a year on, has anyone had any ideas about this? What I've done now is a small script that copies the standard (works with google base feeder but inefficient) copy of query_factory over before base feeder runs, and then copies the query-cache version back.

But this doesn't seem a very elegant way of doing things, but query cache does make a BIG difference to the store speed.

[fergusmacdonald]

Hi there,

I have this mod installed in my store and am wondering if anyone has some information on its compatibility with 1.3.9c before I attempt an upgrade.

Any help much appreciated.

[donplay]

I clicked through to see if there was a solution for the incompatibility between Google Base and this mod but didn't see any details. Has anyone been able to work through this?

thanks,
Don

[tony_sar]

Hi there,

I have this mod installed in my store and am wondering if anyone has some information on its compatibility with 1.3.9c before I attempt an upgrade.

Any help much appreciated.

i don't think this would be compatible with 139a,b,c,d , as query_factory.php has been changed in new releases .

[lat9]

i don't think this would be compatible with 139a,b,c,d , as query_factory.php has been changed in new releases .

You're right ... there were changes to both query_factory.php and functions_categories between zc1.3.8a and 1.3.9c. The attached zip-file has the merged version that combines Query Cache v1.6 and the respective files from ZC 1.3.9c; there is no directory structure in the zip-file, so you need to copy the files to:

/includes/classes/db/mysql/query_factory.php
/includes/functions/functions_categories.php

[mdegrandis]

Anybody get this working in 1.3.9d? I tried it, and it doesn't break the cart, but it also does not lower queries.

It is a fresh install that I used my custom template from 1.3.8a.
Mod wise it has IH2.
It has php 5.2.11 and mysq 5.0.90

Tried running it with query log as well. This is the output:

QUERY DEBUG: Requested execution of: 0 queries. Executed: 7073 queries. Returned from cache: -7073 queries.

SUM: 0


Thanks!