NopCommerce 4.10 - High memory usage and how we've handled it

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
5 years ago
Hello,

After upgrading our demo stores to nopCommerve 4.10 we've started to experience problems with our stores. They were super slow.
After inspecting the server our demo stores are running on we found something really troubling - our demo stores were using all of our system resources. The memory and CPU usage of our system were at 100%.
Due to that situation, our SQL Server was capped at half the memory it normally uses to run with that many application connected to it. This made our demo stores extremely slow.
After further inspection, we saw that all of our stores are using 3-5 times more memory to run. In some cases, the .NET Core Host process used up to 1,3GB of memory for a single store. We have a total of 45 stores hosted on that system. Prior to the 4.10 update, the server didn't have any problems running that many sites. We had to do something about it.
After some research, we found out that disabling the Server Garbage Collector might help us in such a situation. There are two main modes of Garbage Collectors - Server and Workstation. The difference between them is that Workstation GC is designed for lightweight application on single-core systems and minimizes the time spent in GC while Server GC is optimized for application throughput in favour of longer GC pauses and higher memory consumption.
The GC in Workstation GC happens more frequently but with shorter pauses in the application threads which is ideal for UI applications that have a high refresh rate (such as games or console applications for example). The Server GC is optimized for a server application that would usually run on multi-core systems and can support many users. The Server GC uses more memory and the amount of memory depends on the number of cores on your system - more cores means more memory usage. This is the thing that got our attention.
Since our demo stores are running all our products we tried to build our products using the Workstation GC. That didn't improve anything. All of our sites were using around 1GB of memory. Then we tried building nopCommerce using the Workstation GC. We downloaded the Source version of nopCommerce 4.10 and added the following code to the Nop.Web.csproj file :
<PropertyGroup>  
    <ServerGarbageCollection>false</ServerGarbageCollection>
</PropertyGroup>

After that, we built and published the Nop.Web project and replaced the nopCommerce files of all our demo sites with the newly published ones.
Immediately, we saw a massive improvement. All of the sites are now using around 300MB of memory. That is 3-5 times lower than before! Our server is no longer out of memory and our sites are as fast as before the update.

I even ran a test on my local machine. The processes below are of the same site - clean nopCommerce and newly installed database. The only difference is the mode of the GC - first is using Workstation, the second Server GC.


You can see for yourself that the allocated memory is alot lower.

On paper, using the Workstation GC should result in less memory usage but should also lower the performance of the site. In practice, we do not see any degradation of the performance of our demo stores, but we saw a great decrease in the memory usage. I don't think this would apply to everyone, though, since our sites don't often get more than 100 people browsing them at a time due to the fact that they are just for showcase and not real stores.
I think this might be useful for people that faced the same problem as us, and don't have a lot of options, though.

Hope that information was useful to anyone!

Regards,
Anton
5 years ago
Hello,

This information is indeed helpful for developers thanks for sharing with community.
5 years ago
This reduced the memory usage a lot. Thanks for the solution. I mentioned this issue on an earlier post but team missed it I guess.
5 years ago
Is this what we need to do to make sites behave as they should in hosted environments too?
We have a 4.00 site running on SmarterASP without problems. I made a mirror on staging site (same environment) and upgraded it to 4.10. Now it's horribly slow and i can't really find a reason for that. This is the only post I've found about this so far.

Anyone could think of any other reason for 4.10 update crippling down the site?
I was running Venturi theme on the site, had to disable it to try speeding things up somehow, can't say it helped so far.
5 years ago
Hi Anton,

We'll check in the near time - https://github.com/nopSolutions/nopCommerce/issues/3233
5 years ago
Hello,

Just an update on this topic.

We found out that the changes to the Garbage Collection don't require rebuilding the Nop.Web project. It is possible to edit the Nop.Web.runtimeconfig.json file in the root folder of nopCommerce and change the "System.GC.Server" property to false. The file should look like this:

{
  "runtimeOptions": {
    "tfm": "netcoreapp2.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "2.1.0"
    },
    "configProperties": {
      "System.GC.Server": false
    }
  }
}


Another way to lower the memory consumption, even more, is running nopCommerce as a 32-bit application. You can do that by installing the 32-bit version of .NET Core Runtime and changing the processPath attribute of the <aspNetCore> element in your web.config file to the path of your 32-bit dotnet.exe (for us it was C:\Program Files (x86)\dotnet\dotnet.exe).

Here is how your aspNetCore element inside the web.config should look like:
<aspNetCore requestTimeout="23:00:00" processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\Nop.Web.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" startupTimeLimit="3600" />


Note: You can download the 32-bit version of .NET Core Runtime from here.

Hope that helps!

Regards,
Anton
5 years ago
Interesting...
So in hosting environment we should check with tech support guys if they have 32-bit version installed and check the path to it?

Is it realistic that they'd do that? I guess it doesn't hurt to try. Most of the people running NopCommerce are not running their own servers I suppose...
5 years ago
Nop-Templates.com wrote:
Hello,

Just an update on this topic.

We found out that the changes to the Garbage Collection don't require rebuilding the Nop.Web project. It is possible to edit the Nop.Web.runtimeconfig.json file in the root folder of nopCommerce and change the "System.GC.Server" property to false. The file should look like this:

{
  "runtimeOptions": {
    "tfm": "netcoreapp2.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "2.1.0"
    },
    "configProperties": {
      "System.GC.Server": false
    }
  }
}


Another way to lower the memory consumption, even more, is running nopCommerce as a 32-bit application. You can do that by installing the 32-bit version of .NET Core Runtime and changing the processPath attribute of the <aspNetCore> element in your web.config file to the path of your 32-bit dotnet.exe (for us it was C:\Program Files (x86)\dotnet\dotnet.exe).

Here is how your aspNetCore element inside the web.config should look like:
<aspNetCore requestTimeout="23:00:00" processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\Nop.Web.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" startupTimeLimit="3600" />


Note: You can download the 32-bit version of .NET Core Runtime from here.

Hope that helps!

Regards,
Anton


This one helped a lot.. Thank you for sharing such important thing..
5 years ago
compito wrote:
Interesting...
So in hosting environment we should check with tech support guys if they have 32-bit version installed and check the path to it?

Is it realistic that they'd do that? I guess it doesn't hurt to try. Most of the people running NopCommerce are not running their own servers I suppose...


Hi Damir,

Usually when you install the Core runtime you install the 64x version on a x64 machine.
Then when you type "dotnet" it searches in the paths in the PATH environment variable and if it finds it then it will be used. That is why by default you will most probably end up running with the x64 version of dotnet and your process will be x64 even if they have the x86 version installed unless you explicitly specify the full path to dotnet.exe.
So my advise would be to check with the hosting provider and they will advise you for the exact path to the dotnet.exe if they already have the x86 version installed.

Thanks,
Boyko
5 years ago
We've just updated and re-uploaded the package with these performance changes

You can re-download the existing one or manually apply the fix
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.