性能测试中Disruptor框架ExceptionHandler使用分享

丈夫欲遂平生志,一载寒窗一举汤。这篇文章主要讲述性能测试中Disruptor框架ExceptionHandler使用分享相关的知识,希望能为你提供帮助。
在使用Disruptor设计新的性能测试模型的过程中,在使用过程中,偶然发现会有一些异常,然后QPS就会不断下降,直到最后QPS能力降为零。经过查询相关资料后发现了一个小坑:com.lmax.disruptor.ExceptionHandler
这个接口实现类是处理消费消息的过程中发生的异常,具体的源码位置在com.lmax.disruptor.WorkProcessor#run,有兴趣的可以看看。下面分享一下部分代码:

catch (final Throwable ex)// handle, mark as processed, unless the exception handler threw an exception exceptionHandler.handleEventException(ex, nextSequence, event); processedSequence = true;

如果大家在使用Disruptor使用默认的方法的话,会使用默认的ExceptionHandler的实现类com.lmax.disruptor.FatalExceptionHandler,它的com.lmax.disruptor.FatalExceptionHandler#handleEventException方法如下:
@Override public void handleEventException(final Throwable ex, final long sequence, final Object event)logger.log(Level.SEVERE, "Exception processing: " + sequence + " " + event, ex); throw new RuntimeException(ex);

最后还是会抛出一个异常,然后造成com.lmax.disruptor.WorkProcessor执行失败,如果消费消息异常比较多的话,基本上消费线程会很快被干掉,最终导致没有消费线程。
回到实际场景,使用消费线程进行并发请求,在之前的实现中都是直接抛出异常,导致BUG的出现。修复的方法也很简单,要不使用Disruptor提供的几种com.lmax.disruptor.IgnoreExceptionHandler或者org.apache.logging.log4j.core.async.AsyncLoggerDefaultExceptionHandler之类的,基本都是日志打印。不过还是喜欢自己实现,这样方便一些,所以下面是我的解决方案。
try dosomething() catth(e)

【性能测试中Disruptor框架ExceptionHandler使用分享】因为随着QPS上升,报错的概率还是挺大的,毕竟是日志流量回放,由于流量文件中部分请求直接回放是会失败的。如果打印日志,即使每秒万分之一的概率,每秒错误QPS就得10+的QPS。不如直接使用专用的日志平台去统计这部分的异常日志。
Have Fun ~ Tester !
  • FunTester2021年总结
  • FunTester原创大赏
  • 性能测试专题【FunTester原创】
  • Groovy语言学习笔记大赏【FunTester】
  • 性能测试中异步展示测试进度
  • 下单延迟10s撤单性能测试
  • 性能测试误差对比研究(四)
  • 如何选择API测试工具
  • 性能框架哪家强—JMeter、K6、locust、FunTester横向对比
  • 左移测试
  • Java& Go三种HTTP客户端性能测试
  • 浏览器测试的三大挑战及解决方案【译】
  • 单元测试再出发
  • 敬畏用户
  • 千万级日志回放引擎设计稿

    推荐阅读