I have developed the same application which delivers a JSON file in 2 different projects. One is based on ASP.Net MVC4 and the other is based on ASP.Net Core 1.1.0.
The JSON generated by my controller is around 5MB.
However when publishing the 2 apps, i have a difference of sizes for this file if it is compressed or not on both plateforms.
For ASP.Net Core, I have also tried to enable the compression middleware in the Startup.cs to see the difference:
services.AddResponseCompression(
options =>
options.MimeTypes = ResponseCompressionMimeTypes.Defaults);
app.UseResponseCompression()
.UseStaticFiles();
This is the summary of my tests for my original 5Mo JSON returned to the client:
Run on Visual Studio, size of my JSON on:
MVC4: 5MB
ASP.Net Core default: 1.3MB
ASP.Net core with compression: 869KB
On my local IIS Express with dynamic and static compression enabled, size of my JSON on:
MVC4: 256KB
ASP.Net Core default: 1.3MB
ASP.Net core with compression: 869KB
On my production IIS server with dynamic and static compression enabled, size of my JSON on:
MVC4: 136KB
ASP.Net Core default: 675KB
ASP.Net core with compression: 869KB
So we can see that for MVC4, we go from a not compressed file to a highly compressed file in production.
For ASP.Net Core, when the compression is enabled in the Startup.cs, the size of the file is constant but not as small as it could be.
For ASP.Net Core, when the compression is not enabled in Startup.cs, the file is gzip by default but I am not sure it is using the compression capabilities of the IIS server.
My question is what could I do to obtain a compressed JSON in ASP.Net Core as small as the one I obtained on my older plateform based on MVC4.
Thank you
Sylvain
Just a wild guess, but there could be something wrong with your baseline experiment. Why is uncompressed json ~5 times bigger in MVC than in Core (5MB vs 1.3MB)? I would start with making sure they are roughly the same.
Coincidentally your core-compressed-by-iis size (675KB) is ~5 times bigger than mvc-compressed-by-iis (136KB).
Is there a chance you mixed up the numbers? That would explain the discrepancy and confirm that IIS compression is about 20% more effective than Core Middleware in your scenario.
My question is what could I do to obtain a compressed JSON in ASP.Net Core as small as the one I obtained on my older plateform based on MVC4.
Looks like you already taking advantage of IIS compression by:
not using Core Middleware (app.UseResponseCompression)
and having dynamic compression enabled in IIS
and a proper content type configured in system.webServer/httpCompression/dynamicTypes
It might also be worth looking at Optimal vs Fastest compression levels in Core Middleware, eg:
services.Configure<GzipCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Fastest;
});
Related
I have deployed two app services
Windows
https://mysamplewinapp.azurewebsites.net/
Linux
https://mysamplelinuxapp.azurewebsites.net/
Going to https://www.giftofspeed.com/gzip-test/ and inputting the URLs in I can see that the Windows one GZIP is enabled, the Linux one GZIP is not enabled.
How do I get Linux app service to support Gzip compressed?
Newest
I carefully compared the differences between webapp deployed under windows and linux.
It is found that the webapp deployed under Linux has very little content in the Response Headers.
In windows.
In Linux.
Suggestion:
So we just need to add Content-Encoding: gzip in Response Headers, then we can solve the issue.
PRIVIOUS
We can enable gzip compression by code.
I don't know what language your webapp is written in. But there must be a way to achieve it through code or configuration files in the project. You need to search by google according to the code language, you can also tell me, I will help you solve it together.
Below test (NodeJS) wen can find my webapp in linux support Gzip compressed.
I have a nuxtjs project deployed in azure webapp linux environment.
I am new to nuxt, and create new demo then deploy it. So I think we can enable gzip compression by code.
So I seacrh gzip in my project.
I'm investigating load times for my Angular app built in dotnet core 3.1 hosted on a Azure Linux web app and have noticed that the javascript files are not compressed:
I've read that by default Azure Web Apps should compress responses and I shouldn't have to do anything to enable this. However, as I am running Kestrel I don't think I can take advantage of server compression, is that correct?
If I can't use server compression I can use Response Compression, but wanted to check that this is the correct course of action? As the javascript files I'm mostly interested in are mostly static, would this middleware be compressing them every time or would it cache them?
Thanks
TL;DR: Does ExcludedTypes in Microsoft.ApplicationInsights.AspNetCore SDK default to Exception and Trace?
I am running an ASP.NET Core 2.2 app with version 2.6.1 Microsoft.ApplicationInsights.AspNetCore SDK. I am reading: https://learn.microsoft.com/en-us/azure/azure-monitor/app/sampling#configuring-adaptive-sampling-for-aspnet-applications where they write that the default values for ExcludedTypes is Trace and Exception, which is just the way i like it, but I am wondering, since the default values is for ASP.NET (actually specified in the application insights config for the host), if these default values also apply for ASP.NET Core applications that doesnt have an application insights config file (all config is done through code).
I know that the SDK is open sourced, but I haven't been able to search through it and find the initial values: https://github.com/microsoft/ApplicationInsights-aspnetcore. Maybe I am just searching for the wrong things.
Update:
Yes, the default ExcludedTypes for asp.net core is Event. There'are 2 places mentionded that:
1.In this article, it says "In ASP.NET Core, exact same default behavior is enabled in code.":
2.In the source code, you can find it's defined here:
First, the default values for ExcludedTypes is not Trace and Exception, it is Event. There is a GitHub issue for that. And I also tested it myself, the default ExcludedType is Event indeed.
For asp.net core, the default ExcludedType should be same as asp.net, you can take a look at this section of the article you provided. I'll try to go through the code to find out what's in the code for asp.net core and will update you later.
Microsoft's ASP.NET Core documentation (https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/modules?view=aspnetcore-2.1#disabling-iis-modules) says
If an IIS module is configured at the server level that must be disabled for an app, an addition to the app's web.config file can disable the module.
but it doesn't explain when/why one would have to disable or remove such a module. Are there specific reasons? Is it recommended to disable any module that doesn't function along with ASP.NET Core?
The whole guiding design philosophy of ASP.NET Core is streamlining your app. ASP.NET Core removes library dependencies that aren't actually used from your build. The whole middleware pipeline exists so that you can include only what you need, etc. This is just one more of thing along those lines.
IIS loads a default set of modules. If you don't actually need those modules for your app, then it's just cruft that adds extra processing to each request. Hence, remove the modules you don't need/aren't utilizing. The goal is to get from request to response in the fewest steps possible, and IIS modules are simply one more of those steps the request has to pass through. That's fine if you need it, but if you don't, you're wasting cycles, resources and time.
I am working on asp.net core webapp hosted on azure and I want to write my Elmah logs to my azure table storage .Many of the examples I looked into are using "API_KEY" and "logbucketId" but I am not sure what they are.
For instance as per elmah docs here https://docs.elmah.io/logging-to-elmah-io-from-aspnet-core/
app.UseElmahIo(
"API_KEY",
new Guid("LOG_ID"),
After installing nuget package, I don't see any API_KEY or LogBucketId in my appsettings.json file.
Where I can find my API_KEY and LogBucket_Id ?
https://github.com/ElmahCore/ElmahCore supports .net core now.
It is not based on Modules or Handlers, but Middleware.
It works fine although still limited.
The async calls are not being used at the moment. But it is quite extensible.
ELMAH doesn't work with ASP.NET Core, since ASP.NET Core doesn't work with HttpModules and HttpHandlers (ELMAH stands for Error Logging Modules And Handlers). ASP.NET Core does include a new (pre-release) diagnostic tool called ELM (Error Logging Middleware - creative, right?). You can find its source and samples here:
https://github.com/aspnet/Diagnostics/tree/release/1.1/src/Microsoft.AspNetCore.Diagnostics.Elm
Another option similar to ELMAH (and ELM) but with more capabilities is Glimpse:
http://getglimpse.com/
I realize neither of these directly answers your question but hopefully you'll find one or both of these alternative tools useful.
You can check ELMAH port to Net.Core version
https://github.com/ElmahCore/ElmahCore
Make sure it is matching your expectation before you use it.
Note: This new extension is in development and doesn't support all Elmah features.
ELMAH doesn't support ASP.NET Core. The documentation you are linking to is from elmah.io. While they have similar names and elmah.io uses ELMAH for some of its integrations, they don't share code or documentation.