.net core 抛异常对性能影响的求证之路

虚幻大学 xuhss 335℃ 0评论

? 优质资源分享 ?

学习路线指引(点击解锁) 知识定位 人群定位
? Python实战微信订餐小程序 ? 进阶级 本课程是python flask+微信小程序的完美结合,从项目搭建到腾讯云部署上线,打造一个全栈订餐系统。
?Python量化交易实战? 入门级 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

一、前言

在.net 社区中曾经听到过很多关于大量抛异常会影响性能这样的结论,心中一直就存在各种疑问。项目中使用自定义异常来处理业务很爽,但是又担心大量抛业务异常存在性能问题。
查阅了各种文档,微软官方对性能优化这一块也不建议使用过多的异常,故我心中冒出疑问。

  • 疑问一:项目中大量抛出业务异常对性能是否会受到影响?

二、求证

2.1 使用.net 6 建立了一个简单的web api 项目 新增两个压测接口

  • api接口代码如下
        /// 
        /// 正常返回数据接口1
        /// 
        ///  Test()
        {
            return Content("1");
        }

        /// 
        /// 抛异常返回接口2 ,同时存在全局过滤器
        /// 
        ///  Test2(string open)
        {
            throw new BusinessException(Model.EnumApiCode.SignWrong);
        }
  • 全局过滤器代码如下
    /// 
    /// 全局异常日志
    /// 
    public class ExceptionFilter : IExceptionFilter
    {
        /// 
        /// 
        /// 
        /// 
        public void OnException(ExceptionContext context)
        {
            //不做任何处理,直接返回1
            context.Result = new JsonResult("1");
        }
    }

   //全局过滤器注入
   services.AddControllers()
       .AddMvcOptions(option =>
       {
             option.Filters.Add();
 });
  • 现在对test1 接口并发200的情况下进行压测,持续15分钟的压测结果如下:
    d65776b32273f1759e6d169f1d3629d6 - .net core 抛异常对性能影响的求证之路
  • 对通过全局过滤器捕获异常并大量抛出异常 在相同压测条件情况下的压测结果如下:
    a42ce06eeaa74423fef07029d7a9abe7 - .net core 抛异常对性能影响的求证之路

  • 对test1 和test2 同等条件下压测结果对比
接口 tps cpu 压测条件
test1 10300左右 cpu消耗90%左右 并发200,持续压测
test1 4300左右 cpu消耗100%左右 并发200,持续压测

目前得到的结论是抛异常确实影响性能,并且对性能下降了60% 左右,上面主要是异常流程走了全局过滤器方式,故参考意义不大,下面再进一步修改代码进行压测

  • 对test2 代码进行修改如下
       /// 
        /// 抛异常返回接口2 ,直接try catch 不走全局过滤器
        /// 
        ///  Test2()
        {
            try
            {
                throw new BusinessException(Model.EnumApiCode.SignWrong);
            }
            catch (Exception ex)
            {
                return Content("1");
            }
        }
  • 再对修改后的test2 接口进行压测,压测结果如下:

a6cd08e821a71f4878ec89d6a205cafa - .net core 抛异常对性能影响的求证之路

接口 tps cpu占用 压测条件
test1 10300左右 90% 左右 并发200,持续压测
test1 9200左右 91% 左右 并发200,持续压测

进一步得到的结论是try catch 后性能有所提高,跟正常相比还有点点差距,全局过滤器对性能影响比较大,相当于走了管道,但是观察代码test1 和test2代码还存在差距,怀疑test2 代码中new 了新异常导致性能差异,故再进一步进行代码修改求证

  • 对test1 代码进行修改,修改后的代码如下:
        /// 
        /// 正常返回数据接口1,但是先new 异常出来,保持跟上面test2 代码一致
        /// 
        ///  Test2(string open)
        {
            var ex= new BusinessException(Model.EnumApiCode.SignWrong);
            return Content("1");
        }
  • 对修改后的test1 代码进行压测结果如下:
    b181603427d1d26b1c9954a3daa0a1b8 - .net core 抛异常对性能影响的求证之路
    忘记截图,大概和修改后的test2 代码压测结果相差不大,大概tps 9300左右,故还是拿的上一个图贴出来,谅解
接口 tps cpu占用 压测条件
test1 9300左右 90%左右 并发200,持续压测
test2 9200左右 90%左右 并发200,持续压测

进一步得到的结论是try catch 后性能和正常返回代码性能相当,相差无几,可以忽略不计

2.2 最终结论

  • 异常和正常代码性能旗鼓相当,但是全局过滤器对性能影响比较大,大概降低了60%左右,全局过滤器走了管道,但是这跟微软官方的性能优化又有冲突,想必微软官方也是出于对全局过滤器异常处理的考虑吧。
  • 不使用全局过滤器进行业务自定义异常捕获,最外层try catch 掉
  • 对于非自定义异常,尽量按照微软官方建议
    • 使用 “测试者-执行者”模式
    • “尝试-分析”模式

最后抛出一个待求证的问题

  • 疑问一:大量抛出非自定义异常,性能和正常返回性能对比会如何?比如字符串转换int 不使用TryParse 去转换

以上结论个人压测结果,如有不对,欢迎交流纠正​

转载请注明:xuhss » .net core 抛异常对性能影响的求证之路

喜欢 (0)

您必须 登录 才能发表评论!