View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004988 | OXID eShop (all versions) | 4.05. Performance | public | 2013-03-11 16:26 | 2022-01-31 12:52 |
| Reporter | Phenix | Assigned To | |||
| Priority | high | Severity | feature | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 4.6.4 revision 49061 | ||||
| Summary | 0004988: Performance issue with products with lot of variants (about 2000) | ||||
| Description | The problem is on a product which is a bike with 4 variants type (Size, color, type of wheels and type of frame) each variant can have 4 to 12 values, so it ends with about 2000 variants with specific price and stock. When i call the product details page on front end, it takes about 15-20 seconds to load. It's the same when i choose a value in selection lists. | ||||
| Additional Information | The memory usage of the page is 481MB and i don't have slow queries. Here is some info on memory usage : Profile process: 15.82207s 100% 1 * 15.82207s Profile articleAssign: 13.23237s 83.64% 4049 * 0.00327s Profile loadinglists: 9.66465s 61.09% 7 * 1.38066s Profile articleAssignPrices: 7.85399s 49.64% 4049 * 0.00194s Profile selectVariants: 7.58904s 47.97% 20 * 0.37945s Profile articleAssignParentInternal: 2.81569s 17.8% 4049 * 0.0007s Profile _getAmountPrice: 0.45481s 2.87% 79618 * 1.0E-5s Profile oxNew: 0.19087s 1.21% 11461 * 2.0E-5s Profile _applyVAT: 0.14531s 0.92% 11087 * 1.0E-5s Profile fround: 0.09912s 0.63% 44436 * 0s Profile _assignPriceInternal: 0.06927s 0.44% 2030 * 3.0E-5s Profile buildTree: 0.02059s 0.13% 1 * 0.02059s Profile oxAutoload: 0.01391s 0.09% 209 * 7.0E-5s Profile smarty_function_oxmultilang: 0.01231s 0.08% 88 * 0.00014s Profile _getLangTranslationArray: 0.00875s 0.06% 136 * 6.0E-5s Profile getArticleMainUri: 0.00817s 0.05% 11 * 0.00074s Profile getCategoryUri: 0.00451s 0.03% 116 * 4.0E-5s Profile seoencoder_loadFromCache: 0.00193s 0.01% 253 * 1.0E-5s Profile getArticleUri: 0.00148s 0.01% 8 * 0.00019s Profile parseThroughSmarty: 0.00097s 0.01% 1 * 0.00097s Profile executeMaintenanceTasks: 0.00059s 0% 1 * 0.00059s Profile !__SAVING CACHE__! (warning): 0.00014s 0% 1 * 0.00014s Profile oxviewconfig::getViewConfigParam: 0.00012s 0% 51 * 0s Profile seoencoder_saveInCache: 7.0E-5s 0% 1 * 7.0E-5s Profile isSearchEngine: 5.0E-5s 0% 1 * 5.0E-5s Profile oxviewconfig::setViewConfigParam: 2.0E-5s 0% 10 * 0s In oxArticle::_loadVariantList, i tried to put $this->_aVariants[$sCacheKey] in an APC cache instance, thinking that it would help to keep all the list of variants in memory but the execution time is still bad, here's the same info with APC (Memory usage dropped to 170MB) : Profile process: 18.77929s 100% 1 * 18.77929s Profile articleAssign: 13.7172s 73.05% 4049 * 0.00339s Profile loadinglists: 9.73646s 51.85% 7 * 1.39092s Profile articleAssignPrices: 8.49396s 45.23% 4049 * 0.0021s Profile selectVariants: 5.96399s 31.76% 15 * 0.3976s Profile articleAssignParentInternal: 2.78511s 14.83% 4049 * 0.00069s Profile _getAmountPrice: 0.48308s 2.57% 77434 * 1.0E-5s Profile oxNew: 0.19623s 1.04% 11134 * 2.0E-5s Profile _applyVAT: 0.1509s 0.8% 10775 * 1.0E-5s Profile fround: 0.10669s 0.57% 43188 * 0s Profile _assignPriceInternal: 0.07197s 0.38% 2030 * 4.0E-5s Profile buildTree: 0.03302s 0.18% 1 * 0.03302s Profile oxAutoload: 0.01499s 0.08% 209 * 7.0E-5s Profile smarty_function_oxmultilang: 0.01268s 0.07% 88 * 0.00014s Profile getArticleMainUri: 0.00947s 0.05% 12 * 0.00079s Profile getCategoryUri: 0.00462s 0.02% 116 * 4.0E-5s Profile seoencoder_loadFromCache: 0.00203s 0.01% 255 * 1.0E-5s Profile getArticleUri: 0.00196s 0.01% 8 * 0.00024s Profile _getLangTranslationArray: 0.00171s 0.01% 134 * 1.0E-5s Profile parseThroughSmarty: 0.00091s 0% 1 * 0.00091s Profile executeMaintenanceTasks: 0.00058s 0% 1 * 0.00058s Profile oxviewconfig::getViewConfigParam: 0.00015s 0% 51 * 0s Profile !__SAVING CACHE__! (warning): 0.00014s 0% 1 * 0.00014s Profile seoencoder_saveInCache: 7.0E-5s 0% 1 * 7.0E-5s Profile isSearchEngine: 5.0E-5s 0% 1 * 5.0E-5s Profile oxviewconfig::setViewConfigParam: 2.0E-5s 0% 10 * 0s If i look in the data info of APC, I can see that the cache uses 15MB of data to store the list of variants, that's really big! I don't have any database problem or slow query, i think it's related to PHP processing. | ||||
| Tags | Performance, PHP, Products, Variants | ||||
| Theme | Not defined | ||||
| Browser | All | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
problem is on creating an loading objects for all 2000 variant. there are places to improve, but only for major updates. in other side, please rethink your product configuration strategy and concept. is it really useful to have 4 variant type and 2000 variant for one product from business perspectives. |
|
|
Your case is an example of product configuration. I'd say this is feature request for the standard shop. Each variant is loaded by eshop as a separate article. 2000 articles per page is a lot. You may provide the product configuration over different way. One of the ways would be using 3rd party configuration module: http://exchange.oxid-esales.com/Shopping-experience/Product-presentation/psKonfigurator-1-2-0-Stable-EE-PE-4-7-x-5-0-x.html |
|
|
waiting for the PO decision. |
