Memory Consumption on Hosting Service #933
Comments
That is what happens with framework-dependent deployments. The .NET Core libraries and the .NET Core runtime are only deployed with the app when you perform a self-contained deployment. https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/ The team members will likely address memory requirements in general, but I was just curious: For the "basic website with no DB" app that you created, what were the memory requirements for the Core version and the non-Core version? |
Do you know how much memory was in use and was there constant growth until it ran out on the shared hoster? Things like server GC use more memory by default but I dunno if you're running into that specifically. You might also try pre-compiling views so that view compilation doesn't happen at runtime, that might also be another source of your memory problems.
Similar to @guardrex, do you have any specific numbers? How were you deploying to the shared hoster? Do you have a sample of the application output? There'll always be more dlls than with ASP.NET Core than there was with |
|
@guardrex
I assumed that using VS2015 Publish that I'd get this "default" they mention. Before we look at specific memory data, perhaps you can look at just what I did with the test project and tell me if I actually got the FDD version or the SCD version - appears to me I got the SCD? If I got the wrong version (I want FDD) then perhaps you can tell me where I went wrong. I'm going to try dragging a few images onto this comment area - if that doesn't work, I'll put them up on my hosting server. Here is where I selected the project template: This is the next step: These are the publish settings: This is the solution pane after the publish: This is the project.json file: `{ "tools": { "frameworks": { "buildOptions": { "publishOptions": { "scripts": { I appreciate your help! |
|
Adding to discussion until something actionable comes out of this. |
|
It's an FDD ... all ASP.NET Core apps built for the .NET Framework depend on the installed runtime and framework on the server. There's another doc (if you didn't see it) that may help demystify the choices there: https://docs.microsoft.com/en-us/dotnet/articles/standard/choosing-core-framework-server RE: The memory situation. As you can imagine, the team is small-ish and super busy, especially now because they're working around the clock to get v2.0 and VS2017 done and done! Like @glennc said, there isn't anything actionable until a clear problem is seen. First, you'll need to report back the difference in memory demand between these two versions of the same app. If there is a large difference ... double or something ... they'll probably ask you to first profile the memory usage (e.g., using PerfView or a similar tool) to see if there's anything obviously wrong. If they want to see the difference themselves, they'll ask you setup two GH repro apps: You'll set up your ASP.NET Web Application (.NET Framework) app in one repo and your ASP.NET Core Web Application (.NET Framework) in the other repo. That way they can pull them down and reproduce what your seeing there. Anywho ... first things first ... you should let them know what kind of difference you're seeing between the two apps. If the difference is only 10MB, that's not too bad. If it's double or something ... that could represent a serious problem. |
|
Please understand that I'm "out over the ends of my skis" at this point. I raised this question on a blog and was encouraged to post here mostly to raise awareness of what happened with a low budget app on a low cost shared hosting service. I didn't realize that I would need to provide analysis that's out of my skill area. So, sorry if I've wasted your time here. All I can say for certain is that:
This is about all I can tell you and perhaps it's just something to keep in mind if other developers raise the same questions - and perhaps someone that is better equipped to perform more analysis. For my part, you've cleared up the confusion about FDD - thanks. However, it's still disappointing that the core coding paradigm is really not practical for me at this time - I really liked that part of Core. |
|
My wild guess is that in memory roslyn compilation is probably bloating your memory (that plus the fact that it's probably not ngened on your hoster). If you can run an experiment for me on your hoster: Can you enable view pre-compilation (turning your views into DLLs) and see if that makes any difference? You need to add 3 things to your
For the last one you'll want to add it to your array of post publish tasks. |
|
@davidfowl, {
"dependencies": {
"BundlerMinifier.Core": "2.2.306",
"Microsoft.AspNetCore.Diagnostics": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.1.1",
"Microsoft.AspNetCore.Mvc.Razor.Precompilation.Design": {
"version": "1.0.0-preview1-final",
"target": "package",
"type": "build"
},
"Microsoft.AspNetCore.Mvc.Razor.Precompilation.Tools": "1.0.0-preview1-final",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.0.0-preview2-final",
"type": "build"
},
"Microsoft.AspNetCore.Routing": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.StaticFiles": "1.1.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.Extensions.Logging.Debug": "1.1.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0"
},
"tools": {
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Mvc.Razor.Precompilation.Tools": "1.0.0-preview1-final"
},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.1.0-*",
"type": "platform"
}
}
},
"net452": {}
},
"buildOptions": {
"emitEntryPoint": true,
//"keyFile": "../../tools/Key.snk",
"preserveCompilationContext": true
},
"publishOptions": {
"include": [
"wwwroot",
"**/*.cshtml",
"appsettings.json",
"web.config"
]
},
"scripts": {
"prepublish": [ "bower install", "dotnet bundle" ],
"postpublish": [
"dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%",
"dotnet razor-precompile --configuration %publish:Configuration% --framework %publish:TargetFramework% --output-path %publish:OutputPath% %publish:ProjectPath%"
]
}
} |
|
@pranavkm can you spot check that @DaveHarney Can you run the application without IIS? It's part of the drop down. That should show you the error directly. |
|
When I switched from IIS to my project name (CoreSize4) and switched to Firefox from Edge, I get the error: Microsoft.NETCore.app, version 1.1.0 wasn't found. If I then switch from .NetCoreApp, Version=v1.0 to ,Net Framework 4.5.2, then my project runs OK on my PC. However, v1.1.0 appears to be in my project?
Obviously, 4.5.2 is in my project, but I don't find a reference to it in any project settings file. However, when I create the project we get this menu and a default of 4.5.2
This is all pretty confusing and I have no clue as to how to run this project on my hosting service as I don't know how to force these changes once I FTP it up there. However, I'm sure you folks can tell me! |
|
Why did you add netcoreapp1.0 to your project? Remove it and go back to net452. It should be possible to run it the project directly without adding netcoreapp1.0. What does your |
|
First of all, thank you very much for sticking with this - I would have quit some time ago :-) Although I don't remember exactly, I guess I copied that netcoreapp 1.0 from the link you gave - when I couldn't get past the errors, I guess I started coping stuff from the project.json in your link. Always a bad idea to just start thrashing around! Anyway, I started over again with a fresh project based on the same MS template I used before (as shown in pix above). This time I only changed what you described in those links - nothing else except to resolve a few more of those 1.0.0-* things. Now I just see this:
The project runs fine on my PC. I published to a local file and FTPed it to my host server. Aside from the slow spin-up (which is not a problem) the project seems to run fine there also. I'll fool around with it more this evening to see if I can find problems - but, the original test of bringing up a core project and then another non-core project (like my forum) seemed to avoid what I experienced before with the repeated spin-ups, etc. I need to do more testing and look at the raw logs that I turned on - which are delivered nightly in a zip file. So, I'll try to post again tomorrow after some testing this evening. However, this is clearly a step forward - thanks again! |
|
Also, here is the project.json now: {
"dependencies": {
"Microsoft.AspNetCore.Diagnostics": "1.0.0",
"Microsoft.AspNetCore.Mvc": "1.0.1",
"Microsoft.AspNetCore.Mvc.Razor.Precompilation.Design": {
"version": "1.0.0-preview1-final",
"target": "package",
"type": "build"
},
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.0.0-preview2-final",
"type": "build"
},
"Microsoft.AspNetCore.Routing": "1.1.0-preview1-final",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
"Microsoft.AspNetCore.StaticFiles": "1.0.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0-preview1-final",
"Microsoft.Extensions.Configuration.Json": "1.0.0",
"Microsoft.Extensions.Logging": "1.1.0-preview1-final",
"Microsoft.Extensions.Logging.Console": "1.0.0",
"Microsoft.Extensions.Logging.Debug": "1.0.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0"
},
"tools": {
"BundlerMinifier.Core": "2.0.238",
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Mvc.Razor.Precompilation.Tools": "1.0.0-preview1-final"
},
"frameworks": {
"net452": { }
},
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},
"publishOptions": {
"include": [
"wwwroot",
"**/*.cshtml",
"appsettings.json",
"web.config"
]
},
"scripts": {
"prepublish": [ "bower install", "dotnet bundle" ],
"postpublish":
[
"dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%",
"dotnet razor-precompile --configuration %publish:Configuration% --framework %publish:TargetFramework% --output-path %publish:OutputPath% %publish:ProjectPath%"
]
}
} |
|
Ok great! Before going to your server try publishing locally to the file system and seeing if that works. |
|
Yes, comes up on my local file system and looks good - actually interesting that the spin up is much faster on my PC than on the hosting service. So, I brought up this core project (based on that MS Template above) on the hosting service and it runs fine (spin up aside). Then, in that same 300 mb memory space, I brought up the two current non-Core projects - my main site and the forum. From there, I bounced around between these projects and all worked well - no more recycling, additional spin-up, or strange error messages as it did before. Response time was very good. I'll look at the log files tomorrow but I don't have any reason to believe there will be anything remarkable. If I may indulge in a little commentary..... In the 60s I started programming in assembler and then switched to PL/1 because it was more productive for our needs. When I could see that PL/1 (which I dearly loved) wasn't going anywhere, I switched to C (and later C++). Then I switched to VB.Net because it was more productive for our needs. When I could see that VB wasn't going anywhere, I switched to C# MVC. I could tell the same kind of story for DB, UI, TP, etc. The point being that developers are always making this dance with tools based primarily upon a combination of productivity and what's going to be supported and enhanced. My sense now is that Core is going to get all of the MS love going forward and all protest to the side, the older .Net stuff will wither away. Right now it also seems that VS2017 is going to be the base requirement for really using Core smoothly. And, my hope is that the kind of guidance you gave me will simply be built into the templates for developers like me who "just want stuff to work". It also seems like project.json will be replaced with MS Build and it's XML will seldom need to be fiddled with for many projects. End of editorial :-) Your help was greatly appreciated and this experience that started out so frustrating has turned out to be a good learning event. Please check here tomorrow, but no comment from me means that there was nothing remarkable in the logs. Thanks again. |
|
Thanks for the story! Did everything work out? |
|
Hi David, Yes, we seen to have overcome a major issue with deployment to a limited memory, shared hosting service. My current project is now pretty far down the road in the non-core version for a rewrite back to Core. But, as projects often go, if I need to redo it for other reasons, I can be much more confident with Core. Certainly, when I see VS2017 RTM I'll start using Core for any new project. Thanks again, and glad you liked my Life Story :-) |
I'm a retired software developer and now only work on volunteer projects so my concerns may only apply to developers working on low budget projects. (here is a sample of the type of projects I do: http://www.bikex.net/) Currently, I'm working on a new project and decided to develop it in CORE (1.1.0) MVC in VS2015. I really liked the coding experience despite a bit of a learning curve. However, the experience of deploying to a shared hosting server forced me to rewrite the project in the older version of the .net framework. I spent a couple of very frustrating days going back and forth with both the tech support and the hosting company management. However, this is not a criticism of the hosting company - I believe they did everything they could to help me. But, they too are frustrated with the reality of Core deployments as it relates to their business model. The basic issue is the need to load numerous memory consuming dlls into an allotment of memory which is based on the price of the hosting plan.
I coded a fairly basic website with no DB and it ran very well on my Dell PC that has plenty of memory. Then I deployed it to a shared hosting service as this will be a very low traffic website. The hosting service is one that I've used several times for other .Net apps and the performance has always been fine. The problem is that these shared hosting services can't provide unlimited memory resources for each customer - it's just not financially feasible for the prices they can charge. The plans at this particular company for memory allotment were 100mb, 300mb, and 500mb for their different plans and pricing levels. The mid range (300 mb cost about $120 a year) was barely adequate to run my Core app but quickly ran out of memory when I added one other small non-core project. Their more expensive plan for 500mb was outside of my budget for this little project. To eliminate the possibility that the code in my project was causing some unique problem, I tested by deploying an unmodified standard MS template Asp.Net Core Web Application (.Net Framework) - the memory problems were the same. Memory consumption was monitor by the hosting company as my applications ran. Once the memory limit was hit, the app was recycled (not sure of these details).
I knew Core took more memory but not to the extent that it was problematic for running on shared hosting services. Had I known this, I wouldn't have gone down the learning path for Core. However, I'm very disappointed that the Core coding features are no longer usable for me - I really did like the coding experience. But the deployment experience is a show stopper for me. After rewriting the Core project in the older version of .Net, my two non-core projects ran very well with no memory issues - I could probably go back to their least expensive plan.
As I'm not interested in deploying to any OS besides Windows, is there now (or will be in the future) a way to use the coding features of Core (like tag helpers, etc) but still have the previous paradigm of shared dlls on the hosting service? Or memory requirements similar to non-Core projects?
The text was updated successfully, but these errors were encountered: