[3.4] Cache CategoryModel in CatalogController.Category()

6 years ago
In eCommerce, perhaps the most viewed page is the product listing page (category page). We are trying to minimize the page load time.

In 3.3 -> 3.4, the SubCategories is now cached instead of caching just "whether a category has subcategories". Under our load testing, this has made significant improvement in performance.

I went deep and look further and came up with the following:-

(1) Any reason why we are only caching "whether a category has featured products" (CATEGORY_HAS_FEATURED_PRODUCTS_KEY) instead of caching the actual featured products? Is there any technical implication that I might have overlooked for not doing it? Or simply less priority in the roadmap?

(2) As this page is expected to load heavily by shoppers, can't I just cache the entire CategoryModel so it doesn't need to look up anything from the database? From my load testing, the performance gain is another big leap.

Again, Is there any technical implication that I might have overlooked for not doing it? Or simply less priority in the roadmap?


Thanks.

Sunny
6 years ago
We do not product models because prices could be quite complex and depend on applied discount codes, tier prices, customer roles, discount rules, etc. Simply saying prices (hence, product models) can depend on certain customer
6 years ago
a.m. wrote:
We do not product models because prices could be quite complex and depend on applied discount codes, tier prices, customer roles, discount rules, etc. Simply saying prices (hence, product models) can depend on certain customer


OK Thanks. It is fair to say it is around the price / discount area would be the main concern for caching the model then.

For customer role, I think you guys already resolved by including the "roles of the current user" as part of the key, so I don't think that's much as issue.


How about Feature Products?

CATEGORY_HAS_FEATURED_PRODUCTS_KEY uses category id, roles of the current user and current store ID for keys. I think this can be safely cached without too much complications?
6 years ago
We cannot cache product models because of the reason I described. That's why we cache only boolean value ("CATEGORY_HAS_FEATURED_PRODUCTS_KEY" cache key) indicating whether products should be loaded
6 years ago
Since I started the thread, I feel responsible to wrap it up.

We are on nop 3.3, and I merged some changes from 3.4, then I added some caching to the the Category method. The result is quite satisfy.

http://tech.sunnyw.net/2014/08/performance-tuning-nopcommerce-category.html


Thank you Andrei for pointing up about the risk of caching price.
6 years ago
sunnyw wrote:
Since I started the thread, I feel responsible to wrap it up.

We are on nop 3.3, and I merged some changes from 3.4, then I added some caching to the the Category method. The result is quite satisfy.

http://tech.sunnyw.net/2014/08/performance-tuning-nopcommerce-category.html


Thank you Andrei for pointing up about the risk of caching price.


Nice article.

Which tool are you using for load testing?
6 years ago
Dharmik wrote:
Since I started the thread, I feel responsible to wrap it up.

We are on nop 3.3, and I merged some changes from 3.4, then I added some caching to the the Category method. The result is quite satisfy.

http://tech.sunnyw.net/2014/08/performance-tuning-nopcommerce-category.html


Thank you Andrei for pointing up about the risk of caching price.

Nice article.

Which tool are you using for load testing?


http://www.badboy.com.au/
6 years ago
It will be good to share the actual  code changes with the community,
i did some extensive caching and by using ajax calls for catalog listing i am able to achive even better loading time than 3.4(using 3.3) by 30-50% less load time according to miniprofiler but i'm not sure if my changes are "safe", for our needs its working so far.
6 years ago
Lucho wrote:
It will be good to share the actual  code changes with the community,
i did some extensive caching and by using ajax calls for catalog listing i am able to achive even better loading time than 3.4(using 3.3) by 30-50% less load time according to miniprofiler but i'm not sure if my changes are "safe", for our needs its working so far.


I first refactored the code that gets the CategoryModel called PrepareCategoryModel(). Then I override the methods and add the model to the cache.

The blog link had an image of the source.

I already submitted a pull request in the fork for the refactor works.


The point is my changes is not a express ticket to the performance boost. It's a point making that what options are available when it comes to caching the category page, and a matter of finding the best fit to your custom solution.

Andrei was right about the caching of the price will break other stuff. Products or discount if that's what you rely on for mark down.
5 years ago
sunnyw wrote:
It will be good to share the actual  code changes with the community,
i did some extensive caching and by using ajax calls for catalog listing i am able to achive even better loading time than 3.4(using 3.3) by 30-50% less load time according to miniprofiler but i'm not sure if my changes are "safe", for our needs its working so far.

I first refactored the code that gets the CategoryModel called PrepareCategoryModel(). Then I override the methods and add the model to the cache.

The blog link had an image of the source.

I already submitted a pull request in the fork for the refactor works.


The point is my changes is not a express ticket to the performance boost. It's a point making that what options are available when it comes to caching the category page, and a matter of finding the best fit to your custom solution.

Andrei was right about the caching of the price will break other stuff. Products or discount if that's what you rely on for mark down.


how does your changes look like for the version 3.5? are they still valid and helpful? I am also looking for a solution like yours. thanks