问题描述
我正在尝试评估.NET Core 2中开发的Web API的基准RPS.这是到目前为止我已经执行的步骤
I'm trying to gauge baseline RPS for a Web API developed in .NET Core 2. Here are the steps I've followed so far
- 使用VS模板中的Microsoft生成的新的/空的Web API项目
- 添加了一个新的Controller，该Controller执行基本的您好，您的api端点正在工作"响应，没有逻辑，也没有其他I/O处理
- 作为应用程序服务部署到Azure.对于服务计划，选择P3(P3 = 400总ACU，7GB，$ 800/月)，并将实例数设置为最多20个.
- 加载了JMeter并设置了HTTP Request负载测试以模拟负载峰值.我发现高于530个并发请求的任何内容，如果在此高峰期间尝试在浏览器中发出请求，就会开始收到JMeter报告的HTTP错误和延迟的响应.
- 对于为什么我配置的计算能力/规模无法在基准.net核心2控制器上同时处理530个以上的请求，我感到困惑.我试图得到一个答案，如果这是正常的.想知道我是否可能缺少一些优化点?我使用基线.NET Core Web服务实现，因为我想从我肯定无法进一步优化的代码库入手，因此我可以首先关注计算需求.
如果这些是Azure上托管的基准.NET Core 2 Web服务的预期结果，则我们将不得不花费更多的钱，因为我们希望能够处理3000多个并发请求，在尖峰期间响应时间/等待时间不超过30秒.就自动负载平衡而言，峰值在我们的实例中是随机出现的.我无法详细说明，但是绝对没有办法确定这些峰值何时会达到，这是一个非常独特的业务案例，但不可避免.
If these are the expected results for a baseline .NET Core 2 web service hosted in Azure, then it looks like we're going to have to spend a lot more money as we're hoping to be able to handle over 3000 concurrent request without response time/latency going above 30 seconds during spikes. As far as auto-load balancing goes, the spikes come at random times in our instance. I can't get into details but there is absolutely no way to determine when these spikes will hit, it's a pretty unique business case, but unavoidable.
我还想知道JMeter是否是验证这些结果的最佳工具.这似乎是一个受人尊敬的工具，如果有人对其他负载测试工具有好运，请推荐.
I'm also wondering if JMeter is the best tool to validate these results. It seems a respected tool, If anyone has had luck with other load testing tools please recommend.
这是我从Startup.cs启动配置/服务时要做的所有事情
Here is all I have going on in the configuration/service startup from Startup.cs
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseHsts();
}
// TO DO: build whitelist
// app.UseCors(
// options => options.WithOrigins("http://example.com").AllowAnyMethod() );
app.UseCors(options => options.WithOrigins("*").AllowAnyMethod());
app.UseHttpsRedirection();
app.UseMvc();
}
还有
public void ConfigureServices(IServiceCollection services)
{
// ADDCors during test stages
services.AddCors();
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
}
推荐答案
.NET内核在处理高RPS方面非常不错.运行这些类型的测试和设计应用程序时，有很多因素可能会基于以下因素，但不仅限于此.
.NET core is very decent in terms of handling high RPS . There are many factors when you run these sort of tests and design application which could based of the following but not limited to.
.NET Core版本
您只是提到您正在使用.NET Core2.只是要知道有多个.NET Core 2.X版本，并且.NET 2.0和.NET 2.2之间存在相当大的性能差异.如果您想了解更多有关性能差异的信息，请在下面的链接中关注Microsoft的Jon Galloway. https://www.youtube. com/watch?v = 04SmFYwLPwM& feature = youtu.be& list = LLxfaEBq0Fa7eiKokf98ojxA& t = 167
You simply mentioned you are using .NET Core 2. Just to be aware there are several .NET Core 2.X versions and there is considerable performance difference between.NET 2.0 and .NET 2.2 . If you want to find out more about performance difference please follow Jon Galloway's from Microsoft in the following link.https://www.youtube.com/watch?v=04SmFYwLPwM&feature=youtu.be&list=LLxfaEBq0Fa7eiKokf98ojxA&t=167
基准标记
您可能会根据个人经验找到不同的基准，但是我更喜欢由社区运营的techempower. https://www.techempower.com/benchmarks/
You may find different bench marks based on personal experiences but i prefer techempower which is run by community. https://www.techempower.com/benchmarks/
性能测试工具
JMeter是出色的性能测试工具，您提到的响应时间非常高，理想情况下应以毫秒为单位，因此某些事情不正确，因此绝对需要进行调查.您可以使用Azure性能测试工具来验证您的测试.蔚蓝性能测试工具可为您提供更深入的见解. https://docs.microsoft.com/zh-CN/azure/devops/test/load-test/app-service-web-app-performance-test?view=vsts
JMeter is nice Performance testing tool and the response time you mentioned is very high which should ideally be in milliseconds so some thing is not right and definitely needs investigation. You can use Azure Performance test tool to validate your tests. The azure performance test tool give you deeper insights. https://docs.microsoft.com/en-us/azure/devops/test/load-test/app-service-web-app-performance-test?view=vsts
处理尖峰
在使用Azure Web Apps测试峰值时，您需要了解一些注意事项.如果您知道自己的Web负载，则Azure Web Apps是一个不错的选择.使用Azure Web应用程序处理峰值可能是具有挑战性的.您需要知道峰值是否导致新实例进行配置，新VM可能需要花费几分钟的时间来处理请求，并且通常您必须过度配置VM来处理峰值，这可能是代价高昂的选择.
When you are testing spikes with Azure Web Apps, you need to be aware of few things. Azure Web Apps is good choice if you are aware of your web load. Handling spikes with Azure Web apps could be challenging. You need to be aware if your spike is causing the new instance to provision it may take few minutes for the new VM to handle the requests and normally you have to over provision the VMs to handle spikes which could be costly choice.
您希望使用容器(例如Docker)+ Orchestrator(例如Azure Kubernetes)或无服务器(Azure函数)或同时使用这两种方法来处理峰值，它们是专门为此设计的，几乎可以立即调整为峰值.
you would prefer Containers (e.g. Docker) + Orchestrator (e.g. Azure Kubernetes) or Serverless (Azure Functions) or both to handle the spikes and they specifically are designed for this and adjust to spikes almost instantly.
当您设计应用程序以处理高RPS时，它可能基于但不限于您选择的区域，选择的云服务(Azure Web应用程序，容器，无服务器，VMS)，智能缓存，数据库，扩展指标和选择语言.没有一个答案，这实际上取决于您要实现的目标.
When you architect application to handle high RPS it could be based on following but not limited to Region you select, choice of Cloud service (Azure Web Apps, Containers, Serverless, VMS) , Intelligently caching , Database , Scaling metrics and choice of language. There is not single answer and is really depends on what you are trying to achieve.
其他工具和测试
Microsoft的应用程序见解是一种非常强大的工具，可以使您对性能测试有更深入的了解.在使用Azure进行测试时，请始终置备应用程序见解以验证结果.
Application insights from Microsoft is very powerful tool to get a deeper look into your performance testing. When you are testing with Azure, always provision Application insight to validate your results.
运行不同的测试组合，例如更长的用户启动时间，超额配置的Azure Web Apps实例，选择的操作系统(Linux和Windows)，具有不同的监视工具的组合以获取可比较的结果.
Run different test combinations like higher user ramp up time , Over provision Azure Web Apps instances , Choice of OS (Linux and windows), have combination of different monitoring tools to land on some comparable results.
希望有帮助！
这篇关于我对作为Azure应用服务(P3)托管的.NET Core 2 Web API的基准RPS有什么期望?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！