我已经将现有的asp.net web-api从Azure VM(本地安装了IIS和MSsql)移动到Azure Web应用程序和Azure sql数据库(西欧).我注意到,对于相同的工作负载,两者之间的处理持续时间会急剧增加.在VM上占用10-15ms的任务,在托管服务环境中至少需要150ms.内部处理,不包括往返于vm或web应用程序的网络延迟.两者都有空数据库和相同的代码库.具有相同索引的相同数据库模式.

VM是一个简单的2核/ 7GB SSD机器.但即使我将我的网络应用程序设置为高级4核/ 7GB而我的数据库设置为高级250DTU,性能也不会提高.事实上,它在基本的2核web应用程序和10DTU数据库上是相同的.所以瓶颈必须在其他地方.

我如何找出导致处理速度缓慢的原因？ Web应用程序和数据库显示没有性能警报,也不建议按比例放大.

对每个会话/工作负载运行以下查询,以了解在这些工作负载期间发生的等待类型：

– 你的查询在这里

go

select * 
from sys.dm_exec_session_wait_stats
where session_id = @@spid
order by wait_time_ms desc

最后一个SELECT语句将为您提供当前会话的所有等待.

您还可以启用查询存储.

http://www.sqlcoffee.com/Azure_0010.htm

并运行以下查询以了解在执行期间查询等待的原因

select  wait_category_desc,sum(total_query_wait_time_ms) as [sum ms],count(*) as [interval cnt],avg(avg_query_wait_time_ms) as [avg ms],sum(total_query_wait_time_ms / avg_query_wait_time_ms) as [wait cnt]
from sys.query_store_wait_stats
group by wait_category_desc
order by [sum ms] desc

以下文章将告诉您每个等待类别的含义.

https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-query-store-wait-stats-transact-sql

希望这可以帮助.

我面临以下问题.我有一个ASP Net Core 2 Web应用程序,我想部署到Azure.应用程序身份验证与Azure Active Directory集成,因此当我尝试登录时,会发生以下请求：

GET https://login.microsoftonline.com/ecf3f643-27e5-4aa7-9d56-fd350e1e9c37/oauth2/authorize?client_id=20a2bcb5-0433-4bb4-bba3-d7dc4c533e85&redirect_uri=http://myapplication.mydomain.com/account/signin [...]  200 OK
POST http://myapplication.mydomain.com/account/signin 301 Redirect --> https://myapplication.mydomain.com/account/signin
GET https://myapplication.mydomain.com/account/signin 500 Internal Server Error

第一个GET是正常的Azure Active Directory登录请求.请注意,redirect_uri参数具有协议http.

第二个请求是重定向到redirect_uri,一个带有一些参数的POST.由于我已将Azure配置为仅允许HTTPS流量,因此IIS使用HTTPS重定向到相同的URL.这是第三个要求.请注意,此第三个请求是GET请求,因为HTTP redirection is always a GET request POST请求的所有参数都会丢失,并且身份验证失败会在后端发出HTTP 500错误.

我试图手动将redirect_uri参数中的协议更改为HTTPS,并按预期工作.因此,我唯一需要的是让ASP Net Core意识到协议是HTTPS.

怎么办？我在互联网上搜索了大量的页面而没有明确的答案.

注意：redirect_uri由Kestrel设置.由于Azure App Service将IIS放在我的Kestrel前面并在那里进行SSL终止,因此Kestrel和我的应用程序不知道协议是HTTPS,因此在重定向uri中使用HTTP.

更新1

按照@Bruce的建议,我尝试了示例here,克隆存储库并配置应用程序和AD中所述,并且我能够重现错误.

重定向URI继续使用http协议.如果我只在AD应用程序配置中添加https端点作为回复URL,则会收到错误回复地址’http://testloginad.azurewebsites.net/signin-oidc’与为应用程序配置的回复地址不匹配.如果我将http协议端点添加为回复URL,则会收到如下所示的HTTP 500错误：

System.Exception: Correlation Failed.
   at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.<HandleRequestAsync>d__12.MoveNext()
--- End of stack trace from prevIoUs location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptiondispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.<Invoke>d__6.MoveNext()

我仍然认为问题与Kestrel有关,不知道通过HTTPS完成连接,但我不知道如何将信息传达给它.

更新2

我使用的Azure Web应用程序的配置：

> Wep App类型：Linux
>应用程序设置：

>堆栈：.NET Core 2.0
>启动文件：dotnet ./WebApp-OpenIDConnect-DotNet.dll
> WEBSITE_HTTPLOGGING_RETENTION_DAYS：5
> ASPNETCORE_ENVIRONMENT：发展
>始终开启：开启
> ARR亲和力：开启

>自定义域名：

>仅限HTTPS：开启

>诊断日志：

> Docker容器记录：文件系统
>配额(MB)：35
>保留期(天)：5

在web.config文件中,我修改了以下行,如下所示：

<aspNetCore processpath="dotnet" arguments="./WebApp-OpenIDConnect-DotNet.dll" stdoutLogEnabled="false" stdoutLogFile="./stdout.log" />

基本上我提出斜杠而不是反斜杠,以避免Linux路径出现问题.

使用默认设置配置其他所有内容.

更新3
根据@Tratcher的要求,我在这里添加了服务器响应的标题(为了简洁起见,我只包括我认为相关的标题,如果你想看到任何其他标题,请随意让我添加它)：

>第一个请求(GET https：//login.microsoftonline.com/ecf …)：

>服务器：Microsoft-IIS / 10.0
> Set-Cookie：ESTSAUTHPERSISTENT = AQAFCCEADDB … sts;路径= /;安全;仅Http
>严格运输安全：max-age = 31536000; includeSubDomains

>第二次请求(POST http://testloginad.azurewebsites.net/signin-oidc)：

>地点：https：//testloginad.azurewebsites.net/signin-oidc
>服务器：Microsoft-IIS / 10.0

>第三次请求(GET https://testloginad.azurewebsites.net/signin-oidc)：

>服务器：红隼

任何请求中都不会出现x-forwarded-proto标头.

请注意,问题的根源可能在第二个请求的重定向中,即将HTTP POST重定向到HTTPS GET.该重定向不应该发生,因为首先应该通过HTTPS请求POST,但是由于第一个请求的redirect_uri中的http协议错误而没有发生.

更新4

我已经确认只有选择的服务计划是Linux服务计划才会出现此问题.如果服务计划是Windows服务计划(使用与UPDATE 1示例完全相同的代码和配置),则根本不会发生此问题.对于问题,这可能是一种解决方法,但不是解决方案. Linux应用程序服务似乎有缺陷.

我自己有问题.我深入研究了Microsoft的Microsoft.AspNetCore.Authentication,并了解了他们如何构建重定向url：

protected string buildredirectUri(string targetPath)
        => Request.Scheme + "://" + Request.Host + OriginalPathBase + targetPath;

由于Web App已经强制使用HTTPS,因此可以使用Startup.cs中的以下代码解决此问题

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
      ForwardedHeaders = ForwardedHeaders.XForwardedProto
});

您只需添加此引用：

using Microsoft.AspNetCore.HttpOverrides;

我已经检查过,当我将ASP.NET5部署到azure web应用程序时,在Web响应中服务器是IIS,所以我想IIS平台处理程序用于将其重定向到Kestrel.所以我想知道是否有可能直接在Kestrel上运行,以及有什么好处/缺点(可能不管它是否在Azure中).我想它会更快一点,因为IIS将从pipline中排除,但我认为它不应该是太多的开销……

在Azure Web App上,您无法绕过IIS.

但在一般情况下,你绝对可以直接运行Kestrel.毕竟它只是dnx web,它正是XPlat版本(Linux,OSX)最终将使用(几乎).

你不使用IIS会失去什么

>安全性(与IIS相比较新的组件)
>轻松设置SSL
>处理文件/缓存和其他东西的内核模块(内核=更快)
>应用程序监控/ Keep-Alive(如果Kestrel崩溃会发生什么)
>多个主机名单端口(80)重用
>等

从不使用IIS获得的收益

>完全控制您的流程
>整体性能更高
>更简单的安装/执行

如果您选择不使用IIS,应该怎么做

如果您对“丢失”点感到满意,我仍然会将您的Kestrel托管在反向代理或Nginx服务器之后.红隼被制作成“生产就绪”,但它不是Nginx或IIS.

据我所知,它不会保持活力.

如果我遗漏了什么,请告诉我.