View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004980 | OXID eShop (all versions) | 4.05. Performance | public | 2013-03-06 23:03 | 2013-06-23 19:13 |
| Reporter | dennishei | Assigned To | |||
| Priority | high | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.7.3 / 5.0.3 revision 54408 | ||||
| Target Version | 4.8.0_5.1.0_beta1 | Fixed in Version | 4.7.5 / 5.0.5 | ||
| Summary | 0004980: buildTree / assignArray very slow | ||||
| Description | We have 1.320 rows in oxcategories (some are deactivated but have to stay in db).... mysql select query is very fast: /* Affected rows: 0 Gefundene Zeilen: 1.320 Warnungen: 0 Dauer von 1 query: 0,000 sec. (+ 0,016 sec. network) */ if i debug in oxid: Profile buildTree: 0.87755s 2961.7% 1 * 0.87755s Problem seems to be: oxlist->assignArray in oxcategories we have "normal" shop seo content for the categories in oxlongdesc. it looks like that oxid gets ALL fields (also oxlongdesc) for buildung the tree menu on every call..... i think it does not make sense to load all coloumns for building the tree menu... This seems to be the performance killer nr.1 in our EE 5.0.3.... | ||||
| Steps To Reproduce | get my oxcategories.sql an have a look what happens.... | ||||
| Tags | No tags attached. | ||||
| Theme | Both | ||||
| Browser | All | ||||
| PHP Version | 5.3 | ||||
| Database Version | 5.5 | ||||
|
|
just cleaned for testing oxlongdesc. it does not affect performance. it is also slow with no content in oxlongdesc.... |
|
|
commenting out: $this->_ppRemoveInactiveCategories(); brings 0,3 sek performance boost to: Profile buildTree: 0.57923s 1114.79% 1 * 0.57923s but 0,57 sek for buildTree is also too slow..... |
|
|
$this->_blForceFull = false; ==> Profile buildTree: 0.04802s 187.65% 1 * 0.04802s TOP Performance... This must be the target :-) But no DropDowns Items any more in the topmenu (azure) except active category..... so this is not what i can do.... :-) |
|
|
Reminder sent to: dennishei hi, can you attach your category table sql dump? |
|
|
Reminder sent to: dennishei do you test on azure theme? do you on your custom theme always select all categories and build from it trees? |
|
|
Please contact me via email to send you my table. I don't like to send my SEO Text Categories to this public place :-) Otherwise every Luggage Shop in Germany would have our Content :-) |
|
|
in most cases to load all tree not needed. more often use case is use 2 levels of the tree etc. so fix can be extend oxcategorylist class to get 2 level trees or so. |
|
|
fixed, added functionality by default load only 2 levels as it was in prev version |
|
|
The Fix seems to make Problems: http://forum.oxid-esales.com/showthread.php?p=124296#post124296 |
|
|
Actually the fix has some side effects, see the thread Dennis has linked to. One possibility would be to re-enable the blLoadFullTree in oxconfig and implement again in admin within "Performace"-Tab. Ore, maybe better, to allow the shop owner to specify the number of levels loaded by default. |
|
|
have a look at demoshop http://demoshop.oxid-esales.com/professional-edition/Bekleidung/ existing subcategories are not shown any more at "Sportswear" and "Fashion" - despite the template code wants to show them: [{if $category->getHasVisibleSubCats()}] ... [{foreach from=$category->getSubCats() item=subcategory}] ... [{/foreach}] ... [{/if}] please check here within a 4.5 demo installation how it was intended: http://oxid-tpl-debug.stahlwarenhaus-hebsacker.de/azure/Bekleidung/ |
|
|
with a bug fix was introduces new getters please use them before tree generation to setup tree oxCategoryList::setLoadFull() and oxCategoryList::getLoadFull(); oxCategoryList::setLoadLevel() and oxCategoryList::getLoadLevel(); |
