标签：test1 core 求证 压测 代码 过滤器 net 异常 性能
一、前言
在.net 社区中曾经听到过很多关于大量抛异常会影响性能这样的结论，心中一直就存在各种疑问。项目中使用自定义异常来处理业务很爽，但是又担心大量抛业务异常存在性能问题。
查阅了各种文档，微软官方对性能优化这一块也不建议使用过多的异常，故我心中冒出疑问。
- 疑问一：项目中大量抛出业务异常对性能是否会受到影响？
二、求证
2.1 使用.net 6 建立了一个简单的web api 项目 新增两个压测接口
- api接口代码如下
/// <summary>
/// 正常返回数据接口1
/// </summary>
/// <returns></returns
[HttpGet("Test1")]
public async Task<IActionResult> Test()
{
return Content("1");
}
/// <summary>
/// 抛异常返回接口2 ，同时存在全局过滤器
/// </summary>
/// <returns></returns
[HttpGet("Test2")]
public async Task<IActionResult> Test2(string open)
{
throw new BusinessException(Model.EnumApiCode.SignWrong);
}
- 全局过滤器代码如下
/// <summary>
/// 全局异常日志
/// </summary>
public class ExceptionFilter : IExceptionFilter
{
/// <summary>
///
/// </summary>
/// <param name="context"></param>
public void OnException(ExceptionContext context)
{
//不做任何处理，直接返回1
context.Result = new JsonResult("1");
}
}
这里注入过滤器代码就不贴上来
-
现在对test1 接口并发200的情况下进行压测，持续15分钟的压测结果如下：
-
对通过全局过滤器捕获异常并大量抛出异常 在相同压测条件情况下的压测结果如下：
- 对test1 和test2 同等条件下压测结果对比
| 接口 | tps | cpu | 压测条件 |
|---|---|---|---|
| test1 | 10300左右 | cpu消耗90%左右 | 并发200，持续压测 |
| test1 | 4300左右 | cpu消耗100%左右 | 并发200，持续压测 |
目前得到的结论是抛异常确实影响性能，并且对性能下降了60% 左右,上面主要是异常流程走了全局过滤器方式，故参考意义不大，下面再进一步修改代码进行压测
- 对test2 代码进行修改如下
/// <summary>
/// 抛异常返回接口2 ，直接try catch 不走全局过滤器
/// </summary>
/// <returns></returns
[HttpGet("Test2")]
public async Task<IActionResult> Test2()
{
try
{
throw new BusinessException(Model.EnumApiCode.SignWrong);
}
catch (Exception ex)
{
return Content("1");
}
}
- 再对修改后的test2 接口进行压测，压测结果如下：
| 接口 | tps | cpu占用 | 压测条件 |
|---|---|---|---|
| test1 | 10300左右 | 90% 左右 | 并发200，持续压测 |
| test1 | 9200左右 | 91% 左右 | 并发200，持续压测 |
进一步得到的结论是try catch 后性能有所提高，跟正常相比还有点点差距，全局过滤器对性能影响比较大，相当于走了管道，但是观察代码test1 和test2代码还存在差距，怀疑test2 代码中new 了新异常导致性能差异，故再进一步进行代码修改求证
- 对test1 代码进行修改，修改后的代码如下：
/// <summary>
/// 正常返回数据接口1，但是先new 异常出来，保持跟上面test2 代码一致
/// </summary>
/// <returns></returns
[HttpGet("Test2")]
public async Task<IActionResult> Test2(string open)
{
var ex= new BusinessException(Model.EnumApiCode.SignWrong);
return Content("1");
}
- 对修改后的test1 代码进行压测结果如下：
忘记截图，大概和修改后的test2 代码压测结果相差不大，大概tps 9300左右，故还是拿的上一个图贴出来，谅解
| 接口 | tps | cpu占用 | 压测条件 |
|---|---|---|---|
| test1 | 9300左右 | 90%左右 | 并发200，持续压测 |
| test2 | 9200左右 | 90%左右 | 并发200，持续压测 |
进一步得到的结论是try catch 后性能和正常返回代码性能相当，相差无几，可以忽略不计
2.2 最终结论
- 异常和正常代码性能旗鼓相当，但是全局过滤器对性能影响比较大，大概降低了60%左右，全局过滤器走了管道，但是这跟微软官方的性能优化又有冲突，想必微软官方也是出于对全局过滤器异常处理的考虑吧。
- 不使用全局过滤器进行业务自定义异常捕获，最外层try catch 掉
- 对于非自定义异常，尽量按照微软官方建议
- 使用 “测试者-执行者”模式
- “尝试-分析”模式
最后抛出一个待求证的问题
- 疑问一：大量抛出非自定义异常，性能和正常返回性能对比会如何？比如字符串转换int 不使用TryParse 去转换
以上结论个人压测结果，如有不对，欢迎交流纠正
- 参考文献
- https://docs.microsoft.com/zh-cn/dotnet/standard/design-guidelines/exceptions-and-performance
- https://docs.microsoft.com/zh-cn/aspnet/core/performance/performance-best-practices?view=aspnetcore-6.0#understand-hot-code-paths
标签：test1,core,求证,压测,代码,过滤器,net,异常,性能 来源： https://www.cnblogs.com/jlion/p/16365572.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。