[3.4] Cache CategoryModel in CatalogController.Category()

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

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

a.m. wrote:

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?

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

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.

sunnyw wrote:

Nice article.

Which tool are you using for load testing?

Dharmik wrote:

http://www.badboy.com.au/

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.

Lucho wrote:

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.

sunnyw wrote:

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