Bing.com在.NET Core 2.1上运行！
Bing.com在.NET Core 2.1上运行！
相关知识请参考.netCore开发团队博客(https://blogs.msdn.microsoft.com/dotnet/)
Bing.com是一种云服务，运行在遍布全球许多数据中心的数千台服务器上。Bing服务器每秒处理来自全球消费者的数千个用户查询，通过他们的浏览器，使用Microsoft认知服务API的合作伙伴以及个人数字助理Cortana进行搜索。我们的用户要求这些结果具有相关性和速度，因此性能和可靠性是运行Bing等成功云服务的关键组件。
Bing的前端堆栈主要是以MVC模式分层的托管代码编写的。大多数业务逻辑代码都是用C＃编写的数据模型，视图逻辑是用Razor编写的。该层负责将搜索结果数据（编码为Microsoft Bond）转换为HTML，然后将其压缩并发送到浏览器。作为Bing的前端平台的守门人，我们将开发人员的工作效率和功能敏捷性视为我们成功定义中的附加关键组件。数以百计的开发人员依靠这个平台将他们的功能投入生产，他们希望它能像钟表一样运行。
从一开始，Bing.com就在.NET Framework上运行，但它最近已转换为在.NET Core上运行。推动Bing.com采用.NET Core的主要原因是性能（即服务延迟），支持并行和应用程序本地安装，与机器范围的安装（或缺少安装）和ReadyToRun映像无关。为了实现这些改进，我们开始努力使代码在.NET实现中可移植，而不是依赖于仅在Windows上可用且仅与.NET Framework一起使用的库。团队开始使用.NET Standard 1.x，但是减少的API表面为我们的代码迁移带来了非常重要的复杂性。使用.NET Standard 2.0返回的20,000多个API，一切都改变了，我们能够迅速从代码修改转移到测试。在压缩了一些bug后，我们准备将.NET Core部署到生产环境中。
ReadyToRun图像
托管应用程序通常可能具有较差的启动性能，因为首先必须将JIT编译为机器代码。.NET Framework具有预编译技术NGEN。但是，NGEN需要在将执行代码的计算机上执行预编译步骤。对于Bing来说，这意味着NGENing成千上万的机器。随着应用程序在Web服务机器上进行预编译，这与积极的部署周期相结合将导致显着的服务容量减少。此外，运行NGEN需要管理权限，这些权限在数据中心设置中通常不可用或经过严格审查。在.NET Core上，crossgen 工具允许将代码预编译为预部署步骤，例如在构建实验室中，并且部署到生产的映像已准备好运行！
性能
我们的生产数据与.NET Core 2.1中的显着性能改进（与.NET Core 2.0和.NET Framework 4.7.2相比）产生了共鸣。下图跟踪了过去几个月内部服务器的延迟情况。Y轴是延迟（省略实际值），最后的急剧下降（6月2日）是.NET Core 2.1的部署！这一切都提高了34％，这要归功于.NET社区的辛勤工作！
.NET Core 2.1中的以下更改是我们工作负载的显着改进的亮点。它们以降低的影响顺序呈现。
- 矢量化string.Equals（@jkotas）和string.IndexOf/LastIndexOf（@eerhardt）
无论您采用哪种方式切片，HTML渲染和操作都是字符串繁重的工作负载。字符串比较和索引操作是其中的主要组成部分。这些操作的矢量化是我们测量的性能改进的最大贡献者。
- EqualityComparer<T>.Default（@AndyAyersMS）的虚拟化支持
- 软件写入监视并发GC（@ Maoni0和@kouvel）
这导致我们的应用程序中CPU使用率降低。在.NET Core 2.1之前，Windows x64（以及.NET Framework）上的写入监视是使用具有不同性能权衡的Windows API实现的。这个新实现依赖于JIT写屏障，它直观地增加了参考商店的成本，但是这个成本是摊销的，而且在我们的工作量中没有注意到。此改进现在也可以通过2018年5月的安全性和质量汇总在.NET Framework上获得
- 使用calli的方法现在可以内联（@AndyAyersMS和@mjsabby）
我们在代码的性能关键部分中使用ldftn+ calli代替委托（这会产生对象分配），其中需要间接调用托管方法。此更改允许具有calli指令的方法体具有内联条件。我们的依赖注入框架生成这样的方法
- 提高string.IndexOfAny的2＆3 char搜索性能（@bbowyersmyth）
前端堆栈中的常见操作是在字符串中搜索“：”，“/”，“/”以分隔URL的各个部分。这种特殊的外壳改进在整个代码库中都是有益的。
运行时敏捷
最后，在我们的应用程序中拥有运行时的xcopy版本的能力意味着我们能够以更快的速度采用更新版本的运行时。事实上，如果您查看上面的图表，我们将在6月2日（即发布后的两天）的常规应用程序部署中全球范围内进行.NET Core 2.1更新！
这是可能的，因为我们在.NET Core的每日CI构建测试功能和性能的整个版本中运行我们的持续集成（CI）管道。
我们对未来感到兴奋，并与.NET团队密切合作，帮助他们确定未来的更新资格！.NET Core团队很兴奋，因为我们提供了大量的功能测试和额外的大型代码库来衡量实际的性能改进，以及我们致力于为Bing.com用户提供快速结果以及我们自己的开发人员使用最新的软件和工具。
