View Issue Details

IDProjectCategoryView StatusLast Update
0004988OXID eShop (all versions)4.05. Performancepublic2015-12-01 09:10
ReporterPhenix 
PriorityhighSeverityfeatureReproducibilityalways
Status assignedResolutionopen 
Product Version4.6.4 revision 49061 
Target VersionFixed in Version 
Summary0004988: Performance issue with products with lot of variants (about 2000)
DescriptionThe 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 InformationThe 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.
TagsPerformance, PHP, Products, Variants
ThemeNot defined
BrowserAll
PHP VersionNot defined
MySQL VersionNot defined

Activities

Linas Kukulskis

2013-03-12 16:38

reporter   ~0008502

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.

tomas_liubinas

2013-09-26 14:28

reporter   ~0009116

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

svetlana

2014-03-28 10:05

reporter   ~0009759

waiting for the PO decision.