Attribute Combinations

[Yabber]

Thirtybees inherited a completely useless attribute combination feature from PrestaShop 1.6, which generates a huge number of SQL queries on the product page.
After running tests with a profiler, it’s clear that this serious bug in the store engine’s architecture has been fixed in the latest versions of PrestaShop.
I believe that fixing this bug should be a priority in Thirtybees, because in its current form, this feature is completely useless, except perhaps for a few or a dozen attribute combinations.
The screenshots show profiler data for a product with a thousand attribute combinations.

[the.rampage.rado]

Do you have proposal how to fix this 'bug'? I believe it's architecture change that breaks compatibility with many things.

[wakabayashi]

7 hours ago, Yabber said:

The screenshots show profiler data for a product with a thousand attribute combinations.

Well, is it then even a bug? 

It would also be interesting to see, which queries are loaded that often. I personally tend to avoid attributes.

[Yabber]

17 hours ago, wakabayashi said:

Well, is it then even a bug? 

Such a huge number of SQL queries is definitely a serious bug in the design of this feature. It results in very long loading times for product pages.
That’s why, in PrestaShop 1.6, no one used this feature, and everyone was forced to purchase “Attribute Wizard Pro” module.

[wakabayashi]

Ah yeah I agree. It's a bad design. But likely not a classical bug, where you just can fix a few lines. 

But as I said, it would be interesting to see, which queries/functions are called that often.

[Yabber]

58 minutes ago, wakabayashi said:

But as I said, it would be interesting to see, which queries/functions are called that often.

A painstaking analysis, examining 20 thousand SQL queries 🙂 
For comparison, a Prestashop 1.6 fork called PhenixSuite. For a thousand attribute combinations, “only” 8 thousand SQL queries.
So, to some extent, optimizing this functionality is possible.

 

[wakabayashi]

You can scroll down and there should be something like "doubles". I guess this section could be helpful.

[Yabber]

10 hours ago, wakabayashi said:

You can scroll down and there should be something like "doubles". I guess this section could be helpful.

After analyzing the profiler logs, I realized that the “blocklayered” module was generating such a huge number of SQL queries. After disabling the module, the number of SQL queries dropped from 21 thousands to 3 thousands.
It is puzzling that this occurs on the product page, where no navigation filters are supported.
We need to take a closer look at the structure of this “blocklayered” module.

 

[wakabayashi]

I don't use this module. So I can't much for it. But filter modules are often the crucial point for speed.

If it occurs on product pages, that is very dubious. What does blocklayerd make on a product page?

[Yabber]

1 hour ago, wakabayashi said:

If it occurs on product pages, that is very dubious. What does blocklayerd make on a product page?

I found the cause of the product page crashing when there are a large number of attribute combinations and the “blocklayered” module is installed.

In the Product class, within the two methods getAttributesInformationsByProduct() and getAttributesParams(), SQL queries have been added with the following condition:

if (Module::isInstalled(‘blocklayered’) && Module::isEnabled(‘blocklayered’)) {

And these are the ones generating such a huge number of SQL queries on the product page.
Interestingly, after removing these SQL queries from the Product class, the navigation filter block on category pages works correctly 🙂 

I would report this on GitHub, but there’s no point, because no one has been handling these issues for almost a year now.