4

We have roughly 3500 product simple products displaying on around 300 group product pages. Some GP-pages have 2 associated products some have 50. The average is 11.6.

The majority of the associated simple products are not visible individually. Therefore their only existence is on this group product page. To improve the user experience we supply to the group product page more information by way of attributes than the default Magento Template.

We have 54 attributes, 5 not in use, 9 are created by us and of the remaining 40 default Magento attributes we use less than 25% of them.

All attributes are in the default folder.

Oddly prelaunch test showed no problems. After launch this issues began with some pages failing to load completely. As a bandaid we implemented a lazy load of the products by closing certain sub-category groups created by an original attribute on the page. This is far from acceptable and performance seems to be very inconsistent.

Using NewRelic we can see our issue is in the /catalog/product/view (86%)

What are we missing? Do we need to restructure our Attributes? If so by what factor?

1
  • Thank you Sonassi, We have removed NewRelic per your suggestion and are investigating Server Configuration. Commented Oct 12, 2014 at 20:43

1 Answer 1

1

The number of attributes isn't really too relevant. But if the attributes are multiselect/dropdown - the number of attribute options they each have is very relevant. If you have hundreds/thousands of options, the burden will be huge. However, I suspect this isn't your issue.

What you are doing isn't particularly heavy, or complex - and you shouldn't really be having any performance issues.

It sounds more like your issue is either infrastructure (ie. improperly configured hosting - the issue in 99% of slow stores) or a badly built template.

If you have even so much as one product->load(), this will be amplified by the associated simple products, and the effects will be catastrophic.

NB. My first tip would be to ditch New Relic. Its pretty and handy for reference, but it's a performance killer (being based on XDebug), and its very presence will slow your store. Use it on dev. but don't deploy on live.

1
  • Thank you Sonassi, We have removed NewRelic per your suggestion and are investigating Server Configuration. Commented Oct 12, 2014 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.