Optimized EAV Cache

[dng-dev]

This pull requests extends the eav cache to preload the entities and also cache them and reduce the amount of queries send to the Databases. In my Environment we reduced the amount of queries from 70 to 40. Also EAV Tags are added to cache entries to evict them on Attribute Save or Attribute set save etc. Also the Peak Memory usage gets lowered.

Here some Queries which gets executed once and cached.

SELECT `catalog_eav_attribute`.* FROM `catalog_eav_attribute` WHERE (attribute_id = :attribute_id);
SELECT `eav_entity_type`.`additional_attribute_table` FROM `eav_entity_type` WHERE (entity_type_id = :entity_type_id);
SELECT `eav_entity_type`.* FROM `eav_entity_type` WHERE (`eav_entity_type`.`entity_type_code`='catalog_product');

[colinmollenhour]

Looks great!

[colinmollenhour]

Did you not mean to also update the return statement here?

[joshua-bn]

What's the difference between getProductAttributes() and getAttributesUsedInProductListing()?

[colinmollenhour]

One change I'm not crazy about is adding code that is specific to Mage_Catalog into Mage_Eav. I feel like Mage_Eav is meant to be a general purpose module and the methods with names containing "Product" belong in Mage_Catalog instead. While some efficiency is gained by putting these arrays all in the same cache record so that object data is not duplicated, I think it could be almost as efficient to store the catalog-specific data in a separate cache record and only store the attribute codes and then rehydrate the attribute arrays from the eav/config singleton.

[seansan]

Great work! How are we going to test this?

…

On Mon, Sep 24, 2018 at 5:12 PM Colin Mollenhour ***@***.***> wrote: ***@***.**** requested changes on this pull request. Looks great! ------------------------------ In app/code/core/Mage/Catalog/Model/Config.php <#532 (comment)>: > @@ -256,8 +256,8 @@ public function getSourceOptionId($source, $value) */ public function getProductAttributes() { - if (is_null($this->_productAttributes)) { - $this->_productAttributes = array_keys($this->getAttributesUsedInProductListing()); + if (null === $this->_usedInProductListing) { + $this->_usedInProductListing = Mage::getSingleton('eav/config')->getAttributesUsedInProductListing(); } return $this->_productAttributes; Did you not mean to also update the return statement here? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#532 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAn0a203Znrzt7lXg2Qvu_CYdjMe7o93ks5uePZagaJpZM4Wzy_a> .

[IvanChepurnyi]

Looks good, except moving product attribute related cache to eav/config. maybe makes sense to catalog related config model and use it to cache this specific catalog calls.

[dng-dev]

Will work on it in the next time

[joshua-bn]

is_array() always returns a boolean. No need to do such a specific test here. It should just be !is_array()

[joshua-bn]

if (!is_array($setIds) || !$setIds) {

[luigifab]

I tried to resolve conflicts, but it's complicated for app/code/core/Mage/Eav/Model/Config.php. It crash for me (probably bad conflict resolving): invalid entity type.

I tried to only edit _load and _save, that's decrease number of sql request, but increase process time.
That's complicated.

[davidhiendl]

@luigifab I have a working alternative/variant that is partially based on some of the logic from this PR as a module (I got impatient waiting for it to be merged over the years). It does however go a bit further (also caches EAV options by attribute set) and has been in production for multiple stores for quite some time. I could rewrite the module as a new PR against 20.x if this is still interesting to have?

[luigifab]

All things that can reduce response time of OpenMage is interesting. If you can, I will very happy to test/use it.

[davidhiendl]

@luigifab Alright, I will prepare it asap.

[luigifab]

Closed in favour of #2993.