We have issues with a project where a lot of products have roughly 16 variants included with extended content. The back-office becomes very slow, listing and filtering takes a long time, editing a product could take up to 10 minutes. Loading the products on the site takes a long time, could be minutes depending on products and variants. Loading the products on the site is done by a web-api that is heavily cached, but the first requested take a long time.
Is this a common issue or are there ways to speed up performance by indexing or other improvements/ideas?
If for some reason the products are not serialized in the ProductIndex the first hit (per product will be slow) as the query will then do a fallback to the ProductService and build out the entire graph and then re-index the product in the ProductIndex. This is still pretty fast so there has to be something else going on if it's exhibiting the latency you are describing.
Can you check your memory usage? Perhaps there is redundant caching?
When using the Web-Api you should be querying through the MerchelloHelper (searches Examine first and then does the ProductService fall back) ... if you go directly against the ProductService, the product (graph) is queried and cached in the HttpRuntime - so if it's not in cache, it will be slow on the first hit. If your caching again (somewhere else) it could be that your cache expires after the ProductService cache expires, which could be forcing each product to be re-cached on the next load.
Entities in Merchello are cached individually (e.g. we're not caching entire pages or collections).
Memmory usage is arround 500 ~ 800 Mb. For the front-end we are using the MerchelloHelper. In the Merchello back-end it has also has performance issues. When we requesting a collection in the back-end of Merchello with no variants and extended content, there is no issue. We only see it when a collection has a lot of products have variants (around 16 variants) and each variant has extended content.
I could send you some more details in a direct message if you would?
This is a screenshot with glimpse, that shows that the post to /umbraco/backoffice/Merchello/EntityCollectionApi/PostGetCollectionEntities takes about 10000 ms.
Prefix shows that compilations takes a long time.
The header response is about 600Kb, and has al the content of the product, included variants and extended content.
I can speed this up a bunch by returning a smaller type to the lists.
Are you only experiencing the latency on the product list view in the back office or are you seeing the same thing in the IProductContent (front end). I've been thinking about creating a proxy version of that ....
I've updated the product variant repository to do some bulk operations which has sped things up considerably. This will be included in the 2.2.0 release which we hope to have out in the next 2 to 3 weeks.
Slow performance listing, editing products with variants (16) included with extended content
Umbraco: 7.4.3 Merchello: 2.1.0
We have issues with a project where a lot of products have roughly 16 variants included with extended content. The back-office becomes very slow, listing and filtering takes a long time, editing a product could take up to 10 minutes. Loading the products on the site takes a long time, could be minutes depending on products and variants. Loading the products on the site is done by a web-api that is heavily cached, but the first requested take a long time.
Is this a common issue or are there ways to speed up performance by indexing or other improvements/ideas?
Regards Wesley
If for some reason the products are not serialized in the ProductIndex the first hit (per product will be slow) as the query will then do a fallback to the ProductService and build out the entire graph and then re-index the product in the ProductIndex. This is still pretty fast so there has to be something else going on if it's exhibiting the latency you are describing.
Can you check your memory usage? Perhaps there is redundant caching?
When using the Web-Api you should be querying through the MerchelloHelper (searches Examine first and then does the ProductService fall back) ... if you go directly against the ProductService, the product (graph) is queried and cached in the HttpRuntime - so if it's not in cache, it will be slow on the first hit. If your caching again (somewhere else) it could be that your cache expires after the ProductService cache expires, which could be forcing each product to be re-cached on the next load.
Entities in Merchello are cached individually (e.g. we're not caching entire pages or collections).
Memmory usage is arround 500 ~ 800 Mb. For the front-end we are using the MerchelloHelper. In the Merchello back-end it has also has performance issues. When we requesting a collection in the back-end of Merchello with no variants and extended content, there is no issue. We only see it when a collection has a lot of products have variants (around 16 variants) and each variant has extended content.
I could send you some more details in a direct message if you would?
Sound good - send me a DM
Thank you! Send you a DM with details.
This is a screenshot with glimpse, that shows that the post to /umbraco/backoffice/Merchello/EntityCollectionApi/PostGetCollectionEntities takes about 10000 ms.
I can speed this up a bunch by returning a smaller type to the lists.
Are you only experiencing the latency on the product list view in the back office or are you seeing the same thing in the IProductContent (front end). I've been thinking about creating a proxy version of that ....
That could be a solution. We also experiencing the latency on the front-end.
Thank you for the response!
Hi Rusty,
Is this something is released in a newer version of Merchello? En when would that be? We want to give some feedback to the client.
Thnx!
Hey Wesley,
I've updated the product variant repository to do some bulk operations which has sped things up considerably. This will be included in the 2.2.0 release which we hope to have out in the next 2 to 3 weeks.
Thank you for the update and for helping out.
is working on a reply...