Performance optimization needed - NOPCOMMERCE IS TOO SLOW !

And what about the multiple calls to the same code?
Hi Nicolas,

Please clarify

Moving off EF would be a very risky business move for nopCommerce imo. Companies hire developers with lots of various .NET experience which includes EF...its one of the selling features of the platform... not to mention all the general independent developers that would affected.
I would recommend not leaving EF now, but spend the next iteration improving performance by other means and re-evaluate this decision a year from now...basically if Microsoft doesn't do something within a year, then it could be time for such a drastic move.
Andrei, while searching for a recent status of 2 level caching for EF, I came across this article.  [url] http://blog.3d-logic.com/2014/03/20/second-level-cache-for-ef-6-1/[/url]
Its from last month so it is recent...very interesting read and would be interested in your thoughts on it.

I mentioned in another post to begin leveraging more background process that populate calculated fields that are relevant during catalog browsing.  That could also help.

Moving off EF would be a very risky business move for nopCommerce imo...

Andrei, while searching for a recent status of 2 level caching for EF, I came across this article.  [url] http://blog.3d-logic.com/2014/03/20/second-level-cache-for-ef-6-1/[/url]
Its from last month so it is recent...very interesting read and would be interested in your thoughts on it..

I proposed many improvements, concerning change tracking, lazy loading for example, nobody answers on these points. The idea was not to kill EF but use it better, with official and documented options. And these options was created to use EF faster, I don't understand why we are waiting to integrate this.
It's a shame for me to have 50 or 100 database request to  load a page, I can't explain to my customers why there store is so slow, it's not there problem, it's mine.

I proposed many improvements, concerning change tracking, lazy loading for example, nobody answers on these points. The idea was not to kill EF but use it better, with official and documented options. And these options was created to use EF faster, I don't understand why we are waiting to integrate this.
It's a shame for me to have 50 or 100 database request to  load a page, I can't explain to my customers why there store is so slow, it's not there problem, it's mine.
Hi Nicolas,

Thanks. I still have links to all your suggestions on my internal performance improvements list. All possible suggestions were implemented. But some of them are too complex to implement. For example, change tracking. There's just no good way to implement it. It'll require each service method to be extended with "bool disableChangeTracking" (or "readOnly"), etc.Maybe, I missed something. It would be great if you could demonstrate how exactly it could be implemented.

        public virtual IPagedList<Category> GetAllCategories(string categoryName = "", 
            int pageIndex = 0, int pageSize = int.MaxValue, bool showHidden = false, bool readOnly = false)
        {
            var query = _categoryRepository.Table;
            if (readOnly) query = query.AsNoTracking();

Hi Andrei!
You are right, we could add readOnly parameter to each GetSomething method, in last position with default value to false, so that it would not affect existing code for developers. Then a single line would disable change tracking like this example :

        public virtual IPagedList<Category> GetAllCategories(string categoryName = "", 
            int pageIndex = 0, int pageSize = int.MaxValue, bool showHidden = false, bool readOnly = false)
        {
            var query = _categoryRepository.Table;
            if (readOnly) query = query.AsNoTracking();

The second step is to set this new parameter to true for homepage, categories and products in priority, then have a reflexion on settings, locales, etc.

All possible suggestions were implemented. But some of them are too complex to implement.

I don't understand, splitting SearchProducts method in a few simpler and faster methods is simple and very efficient. Probably the biggest impact in all my suggestions.

Example
In GetCategoryProductNumber we call
.SearchProducts(categoryIds: categoryIds,  storeId: _storeContext.CurrentStore.Id, visibleIndividuallyOnly: true, pageSize: 1)

in PrepareProductDetailsPageModel we call
.SearchProducts(storeId: _storeContext.CurrentStore.Id,  visibleIndividuallyOnly: false, parentGroupedProductId: product.Id)

It's just examples to show that theses simple calls do not need a so complex sql query using a temp table. You already simplified that king of product acces for the home page, with two methods GetAllCategoriesDisplayedOnHomePage and GetAllProductsDisplayedOnHomePage. We have to do the same to load associated products etc. probably each call that do not use keywords or paging.

I don't understand, splitting SearchProducts method in a few simpler and faster methods is simple and very efficient. Probably the biggest impact in all my suggestions.

Example
In GetCategoryProductNumber we call
.SearchProducts(categoryIds: categoryIds,  storeId: _storeContext.CurrentStore.Id, visibleIndividuallyOnly: true, pageSize: 1)

in PrepareProductDetailsPageModel we call
.SearchProducts(storeId: _storeContext.CurrentStore.Id,  visibleIndividuallyOnly: false, parentGroupedProductId: product.Id)

It's just examples to show that theses simple calls do not need a so complex sql query using a temp table. You already simplified that king of product acces for the home page, with two methods GetAllCategoriesDisplayedOnHomePage and GetAllProductsDisplayedOnHomePage. We have to do the same to load associated products etc. probably each call that do not use keywords or paging.
I did not properly write. It should be "All possible suggestions were implemented. All recent suggestions are also tracked and will be implemented soon"

BTW, please see changeset 53a9b1906f79. Thanks again