更新后 TFS 2015 缓慢填充传入请求
TFS 2015 slow to populate Incoming Requests after update
我的组织最近应用了 TFS 2015 更新（14.102.25423.0，根据 Web 界面的 'About' 页面），导致 Visual Studio 2015 中的 'My Work' 选项卡占用最多一分钟来填充。我尝试了查询并设法将问题缩小到该选项卡的 'Incoming Requests' 部分的人口。在幕后，这是在执行以下 WIQL 查询。
SELECT [System.Id], [System.Links.LinkType], [System.Title], [System.State], [System.Reason], [System.AssignedTo]
FROM WorkItemLinks
WHERE (Source.[System.TeamProject] = @project and Source.[System.WorkItemType] in group 'Microsoft.CodeReviewRequestCategory' and Source.[System.AssignedTo] <> @me and Source.[Microsoft.VSTS.Common.StateCode] <> '1')
and ([System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward')
and (Target.[System.WorkItemType] in group 'Microsoft.CodeReviewResponseCategory' and (Target.[System.AssignedTo] = @me or Target.[Microsoft.VSTS.Common.ReviewedBy] = @me) and Target.[Microsoft.VSTS.Common.StateCode] <> '2')
ORDER BY [System.CreatedDate] desc, [System.Id] mode(MustContain)
- 我使用 https://www.visualstudio.com/en-us/docs/integrate/api/wit/wiql 中描述的 TFS REST API 重现了缓慢（在 POST 请求的正文中传递上面的 WIQL 查询）。
- 以下代码审查选择器填充速度慢：我的代码审查和请求、传入请求.
- 以下代码审查选择器快速填充：我的代码审查、最近完成, 最近关闭.
- 所有用户都会出现此问题，而不仅仅是我的用户。
- 团队中没有人在同一时间进行过多次代码审查。
- 问题实际上是在一夜之间开始发生的，即周五查询在一秒钟左右完成，周一查询最多需要一分钟。
- 我们的 TFS 环境托管在 Windows Server 2012（非 R2）上。
- 我们的 TFS 环境由 SQL Server 2012, SP3 (11.0.6020) 支持。
- 已按照 Microsoft 说明完成对 TFS2015.3 的升级，未遇到任何问题，日志中也没有消息表明有任何错误。
对于可能导致这种缓慢的原因以及可以检查哪些内容以进一步缩小性能问题，是否有人有任何建议？
Visual Studio 中的团队资源管理器提供了下拉选择器，用于指定想要列出的代码审查状态。可用的选项是：
My Code Reviews and Requests (open)
My Code Reviews (open/mine)
Incoming Requests (open/others)
Recently Closed (closed)
Recently Finished (finished)
(为清楚起见，在上面的每个条目中都注释了状态和所有权。)
根据您对性能问题的描述，由于所有用户都会出现这种情况，因此您的团队中似乎有大量代码审查。当您打开 我的作品 选项卡时，加载各种代码审查会导致性能问题。
对于这种情况，您可以尝试以下变通方法：在该团队资源管理器下拉选择器中切换到 我的代码审查。在此之后，请仔细检查问题是否消失或仍然存在。
在这里回答我自己的问题...我的组织最终通过 Microsoft 升级了这个问题，并最终发现过时的统计信息导致错误的查询计划生成存在问题。用于检索代码审查详细信息的查询每次 运行 都需要 60 多秒。
如果您遇到相同的问题，下面的查询很可能会对性能产生重大影响。
use <collection db name>;
UPDATE STATISTICS [dbo].[tbl_WorkItemCoreLatest] WITH FULLSCAN
use <collection db name>;
UPDATE STATISTICS [dbo].[tbl_WorkItemCustomLatest] WITH FULLSCAN
作为参考，Microsoft Connect 上有我原来的 post 的副本：https://connect.microsoft.com/VisualStudio/Feedback/Details/3107261。 Microsoft 在此 post 中的评论表明很多人都看到了类似的行为。
我的组织最近应用了 TFS 2015 更新（14.102.25423.0，根据 Web 界面的 'About' 页面），导致 Visual Studio 2015 中的 'My Work' 选项卡占用最多一分钟来填充。我尝试了查询并设法将问题缩小到该选项卡的 'Incoming Requests' 部分的人口。在幕后，这是在执行以下 WIQL 查询。
SELECT [System.Id], [System.Links.LinkType], [System.Title], [System.State], [System.Reason], [System.AssignedTo]
FROM WorkItemLinks
WHERE (Source.[System.TeamProject] = @project and Source.[System.WorkItemType] in group 'Microsoft.CodeReviewRequestCategory' and Source.[System.AssignedTo] <> @me and Source.[Microsoft.VSTS.Common.StateCode] <> '1')
and ([System.Links.LinkType] = 'System.LinkTypes.Hierarchy-Forward')
and (Target.[System.WorkItemType] in group 'Microsoft.CodeReviewResponseCategory' and (Target.[System.AssignedTo] = @me or Target.[Microsoft.VSTS.Common.ReviewedBy] = @me) and Target.[Microsoft.VSTS.Common.StateCode] <> '2')
ORDER BY [System.CreatedDate] desc, [System.Id] mode(MustContain)
- 我使用 https://www.visualstudio.com/en-us/docs/integrate/api/wit/wiql 中描述的 TFS REST API 重现了缓慢（在 POST 请求的正文中传递上面的 WIQL 查询）。
- 以下代码审查选择器填充速度慢：我的代码审查和请求、传入请求.
- 以下代码审查选择器快速填充：我的代码审查、最近完成, 最近关闭.
- 所有用户都会出现此问题，而不仅仅是我的用户。
- 团队中没有人在同一时间进行过多次代码审查。
- 问题实际上是在一夜之间开始发生的，即周五查询在一秒钟左右完成，周一查询最多需要一分钟。
- 我们的 TFS 环境托管在 Windows Server 2012（非 R2）上。
- 我们的 TFS 环境由 SQL Server 2012, SP3 (11.0.6020) 支持。
- 已按照 Microsoft 说明完成对 TFS2015.3 的升级，未遇到任何问题，日志中也没有消息表明有任何错误。
对于可能导致这种缓慢的原因以及可以检查哪些内容以进一步缩小性能问题，是否有人有任何建议？
Visual Studio 中的团队资源管理器提供了下拉选择器，用于指定想要列出的代码审查状态。可用的选项是：
My Code Reviews and Requests (open)
My Code Reviews (open/mine)
Incoming Requests (open/others)
Recently Closed (closed)
Recently Finished (finished)
(为清楚起见，在上面的每个条目中都注释了状态和所有权。)
根据您对性能问题的描述，由于所有用户都会出现这种情况，因此您的团队中似乎有大量代码审查。当您打开 我的作品 选项卡时，加载各种代码审查会导致性能问题。
对于这种情况，您可以尝试以下变通方法：在该团队资源管理器下拉选择器中切换到 我的代码审查。在此之后，请仔细检查问题是否消失或仍然存在。
在这里回答我自己的问题...我的组织最终通过 Microsoft 升级了这个问题，并最终发现过时的统计信息导致错误的查询计划生成存在问题。用于检索代码审查详细信息的查询每次 运行 都需要 60 多秒。
如果您遇到相同的问题，下面的查询很可能会对性能产生重大影响。
use <collection db name>;
UPDATE STATISTICS [dbo].[tbl_WorkItemCoreLatest] WITH FULLSCAN
use <collection db name>;
UPDATE STATISTICS [dbo].[tbl_WorkItemCustomLatest] WITH FULLSCAN
作为参考，Microsoft Connect 上有我原来的 post 的副本：https://connect.microsoft.com/VisualStudio/Feedback/Details/3107261。 Microsoft 在此 post 中的评论表明很多人都看到了类似的行为。