It actually made me realize the many shortcommings of the built in caching. This could actually made a big difference in NopCommerce, since it is very often that only some page parts are personalised whilst other remain the same.
Also this sounds like made for nop commerce:
devtrends wrote:
It is often quite useful to be able to remove items from the outputcache dynamically. If you have this ability, it is possible to ramp up cache durations quite significantly because you can automatically invalidate the cache when you know that data has changed.
I think the current problem with caching durations is that they are set too short for low intensity stores that don't get enough hits for 120 second caching durations to work and which could benefit greatly from caching durations around 1 hour..
Yes, it's a much nicer implementation of output caching - you can generally replace the [OutputCache] attributes with [DonutOutputCache]. Invalidating cached page content is much easier, and using cache profiles for child actions makes a much cleaner approach.
I also think it will work really well in nopCommerce. It will allow some aggresive caching of main portions of the site while keeping all the product functionality separate - where things like customer specific pricing need to be generated.
The fact that it mentions distributed caching as well will help scale nopCommerce. Imagine you have a web farm running 10 instances of nopCommerce, you could have another application server providing all the cached page content for the web farm. This kind of easily configurable, enterprise level functionality will
I recommend you add the package to the Nop.Web project and give it a go. You'll instantly see where you can start adding donut caching - there are quite a few obvious child actions. I noted some excellent performance gains
Botton line: Adding a Catalog.ShowProductsInSubcategories setting should improve Nop 2.5 performance by significantly reducing size of Products_To_Categories table few times ..
I would have thought that changing to FullText is giving you the best performance increase.
I find it hard to believe that the main procedure uses something as badly performing as PATINDEX to search the string columns.
FULLTEXT allows you to implement far better functionality very easily, i.e language based stemming, so battery and batteries gives the same results.
In the past I have done what Filip has done and created a concatenated field with the text to search and fulltext indexed that, although you can select multiple fields in your text index and search across them with CONTAINS(*,'searchterm').
I also found that it's quite easy to implement a thesaurus, not using the MS search though, simply by holding a table and doing substitutions before you search.
So, user searches for 'usb key 8mb' gets replaced as:
('usb key' or 'memory stick' or 'flash card') and '8mb'
