Poor performances on Opencart 1.4?

mmurph wrote:yes, I agree with you, but what I'm tryng to do is to rewrite the category box code in the way you said and leave the original one, so the Opencart has two category boxes, one for big sites and extreme performance, the other for little databases and full category listing, I want to try to place in the admin side the option to choice what kind of listing the shop admin want to show

Thank you in advance for the contribution of that code.

I agree with Xsecrets that for most users the current code will do, as for heavy users like you the code you will come up with will hopefully do what it needs to do.

Was there any update on this?

Perhaps there is a suggestion or workaround?

I do not think I have extravagant requirements -- I sell motorcycle parts. We split the categories into Make/Model/Year. Right now, I have 571 categories, and it has brought the category box to it's knees. Unfortunately, I will need to be able to kick this up to a few thousand categories.

It's not that we have an unusual number of parts, it's just that the make/model/year category method is "industry standard" -- my customers expect this, and I can't really expect them to change their shopping habits for my convenience.

The problem is not in the categories box, it is in the Search category drop-down in header.tpl. One solution is to reimplement using an Ajax drop-down (Category/Category/Category/...), but for simplicity, I have included the following. You must also nix the category dropdown on search.tpl.

A different solution is to render these drop downs statically (which gets regenerated at category update time), and dump them that way.

This is my workaround:

catalog/controller/common/header.php:

Comment out line 101: $this->data['categories'] = $this->getCategories(0);

catalog/view/theme/<theme>/template/common/header.tpl

Comment out lines 52 to 61 (<!-- ... --> is sufficient)

catalog/controller/product/search.php

Comment out line 94: $this->data['categories'] = $this->getCategories(0);

catalog/view/theme/<theme>/template/product/search.tpl

Comment out lines 20 to 29 (<!-- ... --> is sufficient)

Sorry for the triple post.

With this fix, my system is running fast (sub-second response times) with 4124 categories in 3 layers.

megiddo wrote:Sorry for the triple post.

With this fix, my system is running fast (sub-second response times) with 4124 categories in 3 layers.

@megiddo great workaround. It worked great. I am using around 3500 categories and it had been as pain as we were entering categories manually and not with import. This has fixed the front end issue of loading site.

Did you workaround anything for the admin page, when we try to enter a category it takes few minutes and then sometimes show timeout or sometime blank page, though it inserts the value in category table. Any hint will really appreciate.

Regards.

I have the same problem with 6000 categories the site is dead slow.
and I agree with mmurph 15000 is not much in my case:
Simple Car Store:
Cat level one : Cars, Oil, Batteries have like 11
Cat Level two under Cars: BMW, Honda etc.. have 40
Cat level three: BMW 1, BMW5 etc.. have like 10 under each car.
Cat level four for example under BMW1: Breaks, Parts, have 20

If I only start from Level two 40x10x20= I am already at 8000 categories.

Although I am just running 1.4.94. I wounder if it would help upgrading to 1.5 or anything else can be done to improve performance?

Thanks,

tuba wrote:I have the same problem with 6000 categories the site is dead slow.
and I agree with mmurph 15000 is not much in my case:
Simple Car Store:
Cat level one : Cars, Oil, Batteries have like 11
Cat Level two under Cars: BMW, Honda etc.. have 40
Cat level three: BMW 1, BMW5 etc.. have like 10 under each car.
Cat level four for example under BMW1: Breaks, Parts, have 20

If I only start from Level two 40x10x20= I am already at 8000 categories.

Although I am just running 1.4.94. I wounder if it would help upgrading to 1.5 or anything else can be done to improve performance?

Thanks,

actually no at this point 1.5 is worse with lots of categories than 1.4.x was. If you make sure you have all the caching fixes then you should be able to get 1.4.9.x running fairly well with lots of categories.

megiddo wrote:The problem is not in the categories box, it is in the Search category drop-down in header.tpl. One solution is to reimplement using an Ajax drop-down (Category/Category/Category/...), but for simplicity, I have included the following. You must also nix the category dropdown on search.tpl.

A different solution is to render these drop downs statically (which gets regenerated at category update time), and dump them that way.

This is my workaround:

This is a real workaround!
Why the OC-team has built it in the way it originally works is quite obvious if we think that many shopusers use the search. In fact, I think that most shop users do'nt search by other means than browsing. The original method makes the OC eat heavily on the servers load. Megiddo has a point here, and maybe the OC should be built a little different?
It could quite easily generate a static file that gets picked up (or even directly included) where the category dropdown is placed. In this way the list of categories is placed rather than rendered on every page viewed, saving server and database load.
The file could be generated every time a category is changed (should'nt be to hard to make this, eh?)
Allso: the usage of this file shuld be an add-on; without it all products are scanned in the searc, with it the search is only in the active category.

Anyway: Thanks to Megiddo for actually identifying the problem area and supplying a good and easy workaround.

falkweb