zen cart for contact lenses?

Hi again folks.

I'm now about 3 weeks into setting up a zen cart 1.3.9h installation to sell contact lenses at http://opticalnow.ca

I've managed to get everything set up the way it's needed, but now I have issues with parse time and requests, I'm guessing due to the huge amount of attributes that have to be pulled from the DB before the pages can be displayed.

Contact Lenses are pretty specific, product wise. I've arranged the attributes in two sets to account for selling left and right pairs, using flexible attributes to define the layout.

The Sets of attributes contain values for the following variables:

BC / DIA
Power Range
Adds (if any)
Axis (if any)
Cyl (if any)
Quantity (as a price factor)
Base Price (as a hidden base attribute)

On average, each product has between 80-120 attributes to display on a product page, and most products have a set of attributes that are unique.

I've disabled everything I can find to improve product load speeds, optimized the database, and even removed some javascript. It seems like the cart is trying to do too many queries per product page.

This page for example has a ridiculous load speed.

Parse Time: 17.119 - Number of Queries: 4948 - Query Time: 10.224817272491

HALP! :cry:

You will never get great times at GD

I get great load times on pages such as categories, the home page, defined pages. What I don't understand is why, on a product page, do my queries to the database seem to inflate exponentially?

These I can live with.
Parse Time: 1.089 - Number of Queries: 185 - Query Time: 0.18311192378235 (home page)
Parse Time: 1.953 - Number of Queries: 617 - Query Time: 0.97392892268372 (a 15 product subcatagory page with lots of medium sized, unoptimized images.)

I have to select around 120 variables on average, to give users enough options to order. Shouldn't that add up to be more like (all inclusive) around 300 queries? does it have to query 5000 times to get 120 attributes?

I will be doing some maintenance tonight to see if there are parsing errors I'm not accounting for. I've been streamlining the CSS and java as much as possible.

why, on a product page, do my queries to the database seem to inflate exponentially?

I have to select around 120 variables on average
And each is at least one DB query and then the relationships etc

kobra:

And each is at least one DB query and then the relationships etc

doesn't this imply that the table structure itself is incorrect?

doesn't this imply that the table structure itself is incorrect?
NO, no implication there at all as if that were the case you would most likely be seeing errors

hmmm.... well, no errors that I can see, however I still have to check for warnings and possibly missing files... I have had some trouble with the lightbox 3 plug-in, and removed it. For some reason it conflicted with my new jquery lavalamp menu.

I'm still not sure how fetching 120 attributes can cause 5000 queries, it doesn't add up to me. I have seen references to caching modules and performance mods which reduce the number of queries overall, and really the question to ask, is if all this querying can be done more efficiently, in this open source community, why hasn't it been done yet?

From what I've heard about zen cart 1.4 (or is it 2.0) a lot of these exponentially multiplied queries have been removed in favor of parsing fewer queries.

Unfortunately I have not been able to find a patch or mod to improve this yet, if anyone has any ideas for performance mods for 1.3.9h please let me know.

So to check this out properly, I've installed in the header.tpl:

error_reporting(E_ALL);
ini_set('display_errors', '1');

I have a LOT of warnings, which I have to assume slow things down.

Notice: Use of undefined constant ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL - assumed 'ATTRIBUTES_PRICE_FACTOR_FROM_SPECIAL' in /home/content/29/7029429/html/includes/functions/functions_prices.php on line 1031

Notice: Undefined index: id in /home/content/29/7029429/html/includes/modules/iC_AthemeV1.3/attributes.php on line 581

Note: I'm also using price factors.

Unfortunately I have not been able to find a patch or mod to improve this yet,
Our experiene with these it that while they might reduce querries in number, they do not improve parse times as there is additional non-mysql overhead using them
So to check this out properly, I've installed in the header.tpl:
Using 1.3.9h debug files should be generated and located in your /cache dir already

Using 1.3.9h debug files should be generated and located in your /cache dir already

they were, but I like to see where they occur on the page to track down the issues. :frusty:

the most effective thing I could possibly do to cut down on queries, i think, would be to somehow double up the display and use of my set of attributes, so they aren't pulled twice, from different database entries. I have no idea how this would be accomplished tho.

I'm using two duplicate sets of attributes to get enough info for prescriptions. Is there any way to make a functional clone of one set in the attributes.php - and have the form send both sets, so we have right and left attributes with only one cloned set of attributes?

Right and left attributes need to stay separate so the info in the database stays distinguishable.

gjh42:

Right and left attributes need to stay separate so the info in the database stays distinguishable.

I'm looking for a way around this. Left and Right are clones, but each has to pull around 100 attributes. I want to only have the attributes called once to fill two selection rows, and still use the info each row submits in the order details etc. There has to be a way...

the database has all the options and values it needs with only one set of the variables, but it needs to be called and then displayed twice in the form which is submitted, in the same query.

On another note, I'm coming to the conclusion that* I may be approaching the whole issue backwards*. The site is meant to be a replacement contact lens site, and we only want the user to order prescriptions they are already wearing, not change brands without consulting an optometrist, and so, they don't really need to browse through the catalog, so much as they need to be led directly to their specific product.

So the thought is then, that these prescription variables should be required with sign-up to the site, and a script put in place to direct logged in users to their prescription, their product, without the need to display these query intensive attribute selections on every product page. (which would eliminate the need to clone attributes, put a stop to unnecessary page loads, and bring up the speed of my pages, with a few exceptions)

thedjphat:

Hi again folks.

I'm now about 3 weeks into setting up a zen cart 1.3.9h installation to sell contact lenses at http://opticalnow.ca

I've managed to get everything set up the way it's needed, but now I have issues with parse time and requests, I'm guessing due to the huge amount of attributes that have to be pulled from the DB before the pages can be displayed.

Contact Lenses are pretty specific, product wise. I've arranged the attributes in two sets to account for selling left and right pairs, using flexible attributes to define the layout.

The Sets of attributes contain values for the following variables:

BC / DIA
Power Range
Adds (if any)
Axis (if any)
Cyl (if any)
Quantity (as a price factor)
Base Price (as a hidden base attribute)

On average, each product has between 80-120 attributes to display on a product page, and most products have a set of attributes that are unique.

I've disabled everything I can find to improve product load speeds, optimized the database, and even removed some javascript. It seems like the cart is trying to do too many queries per product page.

This page for example has a ridiculous load speed.

Parse Time: 17.119 - Number of Queries: 4948 - Query Time: 10.224817272491

HALP! :cry:

Just curious: what image files are you using for all your images? BMP, JEPG, etc...

Try GIFs.

If you have already done so, then it's probably something else.

At your side, keep every file (especially image files) you want to display in the smallest size possible.

Cheers!:smile:

assorted image files. It's the least of my trouble though, it's all about query time, and my not so good sql host (godaddy).

i scraped my images from all over also. but i did some work to change them into gif files since i heard that gif is 'good for web site display' some time back.

i'm not sure about godaddy's host capabilities and so i won't make any comment but your site really does has a lag feel. seems to need some time to load pages.

try change your images to gif files first so that you can be sure that the lag in the page load is not your fault. its a procedure to zero-in to the problem. :smile:

oh yar, i did respond to your messages in the flexible attributes forum. any solution?

Please try to keep you comments over here and I will help as much as I can, posting in the flexible attributes section is badly off topic, which is why I made this topic.

:frusty:

In the Free Addons section there is a module called Query Cache. Try that as it has helped a lot of sites run faster; by using less queries.

Website Rob:

In the Free Addons section there is a module called Query Cache. Try that as it has helped a lot of sites run faster; by using less queries.

I have looked into it, but it doesn't support zen cart 1.3.9h yet. Thanks for the suggestion though.

From Geek host:
Unfortunately your site would be flagged by our service monitors. There is no reason to have 5000 queries per page for any script. This shows coding issues and abstract layer problems. As our servers can handle it, your site on a busy day would use too many system resources.

The options that you have are:

1. correcting your code to run better and lower your queries
2. running your site on a dedicated server of it's own

No matter where you host, you are still going to be using a lot of cpu / database resources and they will probably tell you the same thing. If you run a very busy site and do not wish to change the code, you run the risk of bringing down your dedicated server as well.

Our systems here are meant to run Zen Cart and we have customers with 50000-100000 products and their queries don't go any where near your numbers.

Again this makes very little sense. I set the attributes according to the usual zen cart motif, I believe. It seemed to be trucking along fine until I added the second set of attributes for the left eye (which is the same set) and started using price factors for quantity. Has anyone run into this issue before, while setting up a contact lens type store?