Local Security Authority Process (lsass) heavy CPU load through HTTPS - asp.net-core

I ran into an issue with my API generating a huge CPU load of lsass.exe
The environment :
Windows Server 2016
.NET Core 2.2 (aslo tested with .NET Core 3.0)
In order to investigate it, I created a new ASP.NET Core website using the default template (dotnet new web). I updated Kestrel configuration to look like this :
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.ConfigureKestrel((context, options) =>
{
options.AddServerHeader = false;
options.Listen(IPAddress.Any, 5001, listenOptions =>
{
listenOptions.UseHttps(StoreName.My, "*.mycertificate.domain", false, StoreLocation.LocalMachine);
});
})
.UseStartup<Startup>();
});
Alongisde this website, i created a load test using JMeter in order to hit the website with this load :
When running the test browsing the homepage of the website, the result is having the lsass.exe process to heavily use the CPU close the 100%.
I ran others tests using those configurations and the result is still the same
Kestrel using different ways to load the certificate
IIS using InProcess website with a https binding on the certificate
HTTP.sys
Any ideas on how to configure properly https on aspnet-core to create a heavy load API ?
Thanks for your help

Thanks for the reply, but i tried the below process and it worked. Now my idle CPU usage is always less than 5%.
Go to Settings > System > Notifications & actions
Turn off 'Show me tips about Windows'
Restart

Related

IIS Express and Visual Studio 2019 - 413.1 - Request Entity Too Large

I have a .Net Core 2.2 Service to which I am trying to submit a large-ish request payload (including several base-64 encoded files). Total size is just under 30mb. The controller immediately rejects with error 413.1 - Request Entity Too Large.
I have done a bit of research on the issue, but most solutions focus on modifying uploadReadAheadSize in the full version of IIS (but this is IIS express, running locally in VS), or modifying the web.config file (this .Net Core project does not have one).
The project is not going to be deployed in IIS, so I don't think the solutions I've found would work for me at that point either. How can I make this work locally for debugging purposes?
The default request body size limit is 28.6 MB for .NET Core >2.0
If you are not going to use IIS for your deployment and wanted to make it work for debugging purposes, you can use Kestrel and reset the maximum request body size restriction inside of your Program.cs as shown below
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.UseKestrel(options => { options.Limits.MaxRequestBodySize = null; });
You can know more about Kestrel's configuration options from here
Further, this change has been introduced as a breaking change in the version 2.0 of .NET Core. This announcement talks about the ways to perform this in MVC, Middleware and also globally like I showed above.

Change logging in AspNetCore host while running

Is it possible to change logging level on an AspNetCore 2.2 web host that is already started? In particular I am hosting my API within an application, using the following:
IWebHost host = WebHost.CreateDefaultBuilder()
.ConfigureLogging(logging => logging.SetMinimumLevel(LogLevel.Trace))
.UseStartup<Startup>()
.UseUrls($"http://0.0.0.0:{Constants.ApiPort}", $"http://localhost:{Constants.ApiPort}")
.Build();
Ideally I could call ConfigureLogging again and change the LogLevel or do other things as I can when I'm working with the various "builders" before it is built. Would I need a third-party logging provider or can it be done with the standard Microsoft logging?

Problems with ASP.NET Core site using http.sys and Microsoft Edge

I'm having a ton of problems getting an ASP.NET Core 2.1 web application up and running. I need it to run under http.sys (WebListener) on a shared port (80 or 443). I'd also like it to automatically redirect from http (80) to https (443). Of course, I don't want to hard code the listener addresses for http.sys - I need to pull those from a configuration file, but they're hard coded for now. I reserved the appropriate URLs with netsh, but when I run the app I get a warning:
warn: Microsoft.AspNetCore.Server.HttpSys.MessagePump[0]
Overriding address(es) 'http://sharedhost.vbcoa.com:80/app/, https://sharedhost.vbcoa.com:443/app/'. Binding to endpoints added to UrlPrefixes instead.
The app starts, but I can't browse to it with Microsoft Edge at all. Any other web browser is fine - as long as I disable HTTPS. For some reason, the application is forwarding to port 5001, instead of 443.
I figured all of this out. There are four problems. I'll address them each individually.
When configuring http.sys, a warning is issued about overriding local URLs
The UseHttpSys extension method of IWebHostBuilder accepts an options argument with a UrlPrefixes property. However, this is not where you should configure URLs - even if you're using http.sys. You can hardcode them with the UseUrls extension method of IWebHostBuilder, but it would be better to pull it from configuration, which leads to the second problem:
Configuration should be read from appsettings.json
To specify which URLs you want to run the application on, add them to the "urls" element in appsettings.json, as follows:
{
"Logging": {
"LogLevel": {
"Default": "Warning"
}
},
"AllowedHosts": "*",
"urls": "http://sharedhost.vbcoa.com:80/app/;https://sharedhost.vbcoa.com:443/app/"
}
Then you'll need to create a ConfigurationBuilder object, add the appsettings.json file to it, build the configuration (with the Build method) and tell IWebHostBuilder to use that configuration, with the UseConfiguration extension method:
public static void Main(string[] args)
{
var configBuilder = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json");
var hostBuilder = WebHost.CreateDefaultBuilder(args)
.UseConfiguration(configBuilder.Build())
.UseHttpSys()
.UseStartup<Startup>();
hostBuilder.Build().Run();
}
Redirection goes to port 5001, not 443
HTTPS redirection is specified in the Configure method of Startup - that functionality comes out of the box. However, by default it will forward to port 5001, even if you have another port specified in your bound URLs from above. To override it, you need to inject HTTPS redirection options via a service. That's handled in the ConfigureServices method of Startup. Add the following line to that method:
services.AddHttpsRedirection(options => { options.HttpsPort = 443; });
Microsoft Edge won't show the web app, even though every other browser will
This is a problem with localhost loopback isolation in Windows Store apps. It seems to affect Windows 10 Enterprise, as discussed here: Microsoft Edge is not able to recognize localhost. To correct it, you need to do two things:
Make sure "Allow localhost loopback" is checked in Edge's "about:flags" page.
Launch a Command Prompt or Powershell Prompt as an Administrator and enter the following:
CheckNetIsolation LoopbackExempt -a -n=Microsoft.MicrosoftEdge_8wekyb3d8bbwe
That should do it!

Aurelia .NET Core - Browser sync not working on .NET Core

I followed this tutorial on how to use Aurelia/Aurelia CLI with .NET Core.
Changes that I had to make:
Had to target a specific version for Microsoft.DotNet.Watcher.Tools, (dotnet watch run command didn't work)
Changed aurelia.json => build => targets => output value from "." to "wwwroot/scripts", (port:9000 didn't work, errormessage: "Cannot GET / to the server", port 5000 served by .NET Core worked however).
tasks => run.js => browsersync => server => basedir value from ['.'] to ['./wwwroot'], (Fixed browser sync not working on port:9000, however still doesn't work on port:5000 served by .NET Core)
1. How can I make the Browser sync work on port:5000 served by .NET Core?
It must be something in the run.js file. I have tried:
let serve = gulp.series(
build,
done => {
browserSync({
open: false,
port: 9000,
logLevel: 'silent',
proxy: {
target: 'localhost:5000'
}
}, function(err, bs) {
let urls = bs.options.get('urls').toJS();
console.log(`Application Available At: ${urls.local}`);
console.log(`BrowserSync Available At: ${urls.ui}`);
done();
});
}
);
..with no success..
2. Does it matter if I develop on port:5000 or port:9000?
3. What's the point in hosting Aurelia in .NET Core?
Should I only use .NET Core for WepAPI etc?
I think you're going about this in a very unorthodox way.
Just keep going with what you have. The standard is to host the .NET Core project on port 5000 and Browser Sync on port 9000.
You can't host the .NET Core project and the Browser sync on the same port, and messing with the .NET Core project just to move Browser sync to port 5000 is just a lot of work for no benefit.
You develop an Aurelia application, whatever port you decide to host it on doesn't matter at all :)
I wanted to offer an alternative as most tutorials focus on developing on Node. Also, I personally like the MSFT ecosystem, and when I'm going live with any site, it's in Azure. So for me it makes more sense.
I recommend you use whatever technology that makes you productive and whatever makes sense regards to your choice of production environment.

Sitefinity 6.2 site too slow on first load

We're running a Sitefinity 6.2 site on IIS 7.5. For some reason, the site is extremely slow on first load(above 90Sec). There are not many images (Only 4 png's, the largest being 163KB) that could slow down the site. We've tried rebuilding the database indexes to no avail.
There are a couple of other Sitefinity websites of older versions on the web server. We've not had this problem with the older versions.
Any help is greatly appreciated.
IIS's application pool by default is set to go to sleep if there site is not being used. This ensures that the resources are returned to the system for other sites.
Busy sites therefore don't experience this lag on 'waking up'.
Watch this video to illustrate how you can make the Sitefinity site 'always' available.
http://www.youtube.com/watch?feature=player_embedded&v=zRqMAVnOUhw.
Alon
Firewater Interactive
http://www.firewater.net
We've had this issue with all our Sitefinity sites, the first hit takes a long time for the site to get going. What we've done to combat this is run a task in task scheduler every five minutes that runs a C# exe which sends off a web request to each site:
static void Main(string[] args)
{
var sitefinitySites = new List<Uri>
{
new Uri("http://www.example.com")
};
using (var client = new WebClient())
{
foreach (var site in sitefinitySites)
{
try
{
client.DownloadString(site);
}
catch (WebException ex)
{
//send an email or something because the site might be down
}
}
}
}
What about IIS "Always Running" feature
http://developers.de/blogs/damir_dobric/archive/2009/10/11/iis-7-5-and-always-running-web-applications.aspx