. The way to prove the effect of throwing exceptions on performance in. Net core

One 、 Preface

stay .net The community has heard a lot about the conclusion that throwing a lot of exceptions will affect performance , There are all kinds of questions in my heart . It's great to use custom exceptions in projects to handle business , However, I am worried about the performance problems caused by a large number of abnormal businesses . Reviewed various documents , Microsoft officials do not recommend using too many exceptions for performance optimization , So a question arises in my mind .

• Question one ： Whether a large number of business exceptions thrown in the project will affect the performance ？

Two 、 verification

2.1 Use .net 6 Established a simple web api project Add two pressure measuring interfaces

• api The interface code is as follows

/// <summary>
        ///  Normal return data interface 1
        /// </summary>
        /// <returns></returns        
        [HttpGet("Test1")]
        public async Task<IActionResult> Test()
        {
            return Content("1");
        }

        /// <summary>
        ///  Throw exception return interface 2 , There are also global filters 
        /// </summary>
        /// <returns></returns        
        [HttpGet("Test2")]
        public async Task<IActionResult> Test2(string open)
        {
            throw new BusinessException(Model.EnumApiCode.SignWrong);
        }

• The global filter code is as follows

/// <summary>
    ///  Global exception log 
    /// </summary>
    public class ExceptionFilter : IExceptionFilter
    {
        /// <summary>
        /// 
        /// </summary>
        /// <param name="context"></param>
        public void OnException(ExceptionContext context)
        {
            // Do nothing , Go straight back to 1
            context.Result = new JsonResult("1");
        }
    }

    The injected filter code will not be posted here 

• Right now test1 Interface concurrency 200 Pressure test under the condition of , continued 15 The pressure test results of minutes are as follows ：

• To catch exceptions through the global filter and throw a large number of exceptions The pressure measurement results under the same pressure measurement conditions are as follows ：

• Yes test1 and test2 Comparison of pressure measurement results under the same conditions

Interface	tps	cpu	Pressure test conditions
test1	10300 about	cpu Consume 90% about	Concurrent 200, Continuous pressure test
test1	4300 about	cpu Consume 100% about	Concurrent 200, Continuous pressure test

It has been concluded that throwing anomalies does affect performance , And the performance is degraded 60% about , The above is mainly because the exception flow adopts the global filter method , Therefore, it is of little reference significance , Next, further modify the code for pressure test

• Yes test2 The code is modified as follows

/// <summary>
        ///  Throw exception return interface 2 , direct try catch  Do not go through the global filter 
        /// </summary>
        /// <returns></returns        
        [HttpGet("Test2")]
        public async Task<IActionResult> Test2()
        {
            try
            {
                throw new BusinessException(Model.EnumApiCode.SignWrong);
            }
            catch (Exception ex)
            {
                return Content("1");
            }
        }

• And then on the modified test2 Interface pressure test , The pressure test results are as follows ：

Interface	tps	cpu Occupy	Pressure test conditions
test1	10300 about	90% about	Concurrent 200, Continuous pressure test
test1	9200 about	91% about	Concurrent 200, Continuous pressure test

The further conclusion is that try catch The performance is improved after , Compared with normal, there is still a little gap , The global filter has a great impact on performance , It is equivalent to walking through the pipeline , But look at the code test1 and test2 There are still gaps in the code , doubt test2 In the code new A new exception has been added, resulting in a performance difference , Therefore, further code modification and verification

• Yes test1 Code modification , The modified code is as follows ：

/// <summary>
        ///  Normal return data interface 1, But first, new  Out of the blue , Keep up test2  The code is consistent 
        /// </summary>
        /// <returns></returns        
        [HttpGet("Test2")]
        public async Task<IActionResult> Test2(string open)
        {
            var ex= new BusinessException(Model.EnumApiCode.SignWrong);
            return Content("1");
        }

• For the modified test1 The pressure test results of the code are as follows ： Forget the screenshot , Probably with the revised test2 The code pressure test results are similar , Probably tps 9300 about , So I took the last picture and pasted it , understanding

Interface	tps	cpu Occupy	Pressure test conditions
test1	9300 about	90% about	Concurrent 200, Continuous pressure test
test2	9200 about	90% about	Concurrent 200, Continuous pressure test

The further conclusion is that try catch The post code performance is comparable to that of the normal return code , The same , Negligible

2.2 The final conclusion

• The performance of exception and normal code is equal , But the global filter has a big impact on performance , Probably lower 60% about , The global filter has gone through the pipeline , But this conflicts with Microsoft's official performance optimization , Presumably, Microsoft's official consideration is to deal with the exception of the global filter .

• Do not use global filters for business custom exception capture , Outermost layer try catch fall

• For non custom exceptions , Try to follow Microsoft's official advice

  • Use “ Tester - practitioners ” Pattern

  • “ Try - analysis ” Pattern

Finally, a question to be proved

• Question one ： Throw a lot of non custom exceptions , How does the performance compare with the normal return performance ？ For example, string conversion int Don't use TryParse De conversion , The official advice is to reduce such exceptions , Use tryxxx Wait for the operation

The above conclusion personal pressure measurement results , If there is any wrong , Welcome to exchange and correct

• reference

• 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