Minimum memory requirements for Nopcommerce

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
9 years ago
TomvE wrote:
So yesterday I had a quick play with the trial version of .NET Memory Profiler, which also has the option to track unmanaged resources.

I tried it out on a standard nopCommerce v3.30 installation (using the default demo catalog).
Interestingly enough there was about 410 MB assigned as unmanaged code, which was tracked down to the kernel virtual memory. When looking into the instances using the Unmanaged Resource Tracker it seems there are quite a lot of instances related to WebGrease (various CSS and JS bundling functions).

My next step would be to disable WebGrease and see what effect that has on the overall memory usage.
Of course WebGrease's bundling and minification is very useful, so I would rather leave it switched on.

I've also seen the same. Try going to admin area > configuration > general and misc settings > SEO settings and disabling all JS and CSS bundling. Is memory usage dropped?
9 years ago
I have switched off javascript and css minification in v3.30 and it keeps using 330MB
Perhaps it has lowered but it is a lot of memory anyway. The shop does not have products, is a clean installation.
By the way, v3.10 dont have the css and javascript minification option, so i couldnt test it.
9 years ago
a.m. wrote:
I've also seen the same. Try going to admin area > configuration > general and misc settings > SEO settings and disabling all JS and CSS bundling. Is memory usage dropped?


So I did some further testing today. As suggested I disabled all JS and CSS bundling in the settings, then I removed the WebGrease.dll from the bin folder and removed the dependentAssembly entry for WebGrease in the web.config. After that I restarted IIS and ran .NET Memory Profiler again.

This time the virtual memory usage was 220 MB. So switching off WebGrease seems to have freed up around 190 MB (compared to my previous test).
9 years ago
Another small memory optimization that could be explored is getting rid of the runAllManagedModulesForAllRequest setting in the web.config (in the modules section).

Currently this is set to True, which means that every request (even for static content like images, CSS and JS files) gets handled by ASP.NET.
By removing the setting completely IIS will handle requests for static content outside of ASP.NET. This seems to work fine when I tested it, and reduces the overall memory usage somewhat (haven't had a chance to profile it properly).
9 years ago
TomvE wrote:
Another small memory optimization that could be explored is getting rid of the runAllManagedModulesForAllRequest setting in the web.config (in the modules section).

Currently this is set to True, which means that every request (even for static content like images, CSS and JS files) gets handled by ASP.NET.
By removing the setting completely IIS will handle requests for static content outside of ASP.NET. This seems to work fine when I tested it, and reduces the overall memory usage somewhat (haven't had a chance to profile it properly).

Sure. Thanks a lot for suggestion. Done. Please see changeset 70947762ddef. Please give it a try. IMHO, looks much faster (haven't tested using Memory profiler yet)

P.S. Glad that VS developers also did it the default ASP.NET MVC template for VS 2013.
9 years ago
I compared your latest version to v3.30 and there is definitely an improvement (uses about 100MB RAM less with the default demo store).
9 years ago
More more suggestion. Please see commit c02dbe640b15 for more info.

Existing store owners. Please open \App_Data\Settings.txt file and remove "MultipleActiveResultSets=True" from your connection string.
9 years ago
I'm looking into reducing the memory footprint of my site, too (veering off quite drastically from the Nop.Web site) and am looking into potentially reducing caching for many services, as with the way I'm writing the code then there won't be more than 1 call to the same service. Instead I'm creating more granular service methods that do joins across entities needed and returns fully-populated domain objects, so no need to eager load.

Also for some pages I know will be traffic heavy and performance crucial, I'm changing custom service methods to return "skinny" objects, that I can use with automapper to map to ViewModels. If you look at a query generated in retrieving a Product, then it's bringing back ~40 columns, whereas I'm only using 6 or so. So at the service layer I'm projecting to a SkinnyProduct class that contains only what I need -- simplifies my code's intention when using the service, and also minimises the data that needs to fetched from the DB.

May knock a few mb from usage.
9 years ago
Please also see a lot of new performance suggestions here
9 years ago
By the way, do you experience this memory issue only with version 3.30 or with previous versions too?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.