软件开发的家园,编程爱好者的天地.

现在是:北京时间 2016/4/14 上午11:50:51 星期四

设为首页  |  加入收藏  |  网站地图

代码背后的点滴(2)
发布于:第八基地 来源:互联网 作者:天堂路上 时间:2016-04-24 点击:306

场景二,异步化压力测试的结果中有如下一组结果:

容器

请求服务

请求处理模式

TPS

Nginx+ Jetty

Time.get

同步

1534

Nginx+ Jetty

Time.get

异步

1068

Nginx+ Jetty

User.get

同步

1060

Nginx+ Jetty

User.get

异步

1027
Time.get是不向后中转服务的模拟请求,也就是服务端很快就响应给客户端了,而user.get是真实模拟服务向后请求,有一定消耗。但看这个结果,同样是同步和异步对比,前者性能相差很大,后者相差不大。原因?异步一定有消耗,但这个消耗占整体事务处理时间的比例是多少,这就会放大影响。而TOP大部分服务都要比user.get更加耗时,因此后面才是线上的真实状况。(因此场景模拟是压力测试最重要的条件),这里的关键先生还是要看整个事务处理的消耗点。衍生一下上次电话面试的一个北京的朋友,谈到了NIO,问了他是否做过BIO和NIO的测试比较,什么时候用NIO最好,他还真做过四类测试,有结果,但还是没搞明白为什么:1.传输数据量大,后端服务处理慢。2.传输数据量大,后端服务处理快。3.传输数据量小,后端服务处理慢。4.传输数据量小,后端处理速度快。结果是NIO在4处于劣势。其实BIO释放的够快,那么NIO的异步在整体事务处理消耗就形成了劣势。        

  生命周期         

  场景:在异步分享过程中,谈到了事件驱动的架构设计。原来的流程可以分成很多个步骤,每一个步骤由于处理的需要都会申请必要的资源,不同步骤有些是共享资源,有些是不共享的,那么从资源的生命周期角度来说,一个流程中所有资源的生命周期都是一样,就是整个业务事务的执行周期,对于在一个业务流程中各个步骤很少共享资源的状况,或者有等待外部返回内容的情况时,切割开流程步骤,降低资源生命周期,提升资源利用率,是事件驱动的最大优势。NIO如此,Servlet3规范如此。简单来说就是:按需分配。另一方面我们也能看到,处理都是无状态的,只有输入和输出,无状态的处理更容易复用。看起来这种设计很好,但其实背后还是有不少问题:1.流程复杂化,原来通过程序保证流程的顺序和依赖,现在切割以后,如何驱动,顺序如何保证,如何容错,都给系统增加很大的维护成本。2.异步化后消耗时间必然增大,不论是通过pull主动获取状态变更还是通过push被通知到,都在性能和时间消耗上会有一些付出。因此还是需要依环境而定。 

  瓶颈移动         

  场景一,还是一个同学的优化的案例,当时谈到有个叫做最佳线程数,但是觉得在优化过程中最佳线程数是在变化的,其实很多时候当你觉得任何的结论是不稳定的,那么你需要进一步深入挖掘下去。其实之所以最佳线程数这个值不稳定,关键在于我们如何去优化,找到问题所在。和前面举例一样,系统可以看成各种类型资源池的一个整体,然后由很多个步骤不断申请资源来完成各个步骤,最后返回结果。那么说白了,哪个资源池是流程中处理能力最弱的,他就是问题所在,就是瓶颈,但是通过优化后这个瓶颈可能有所改善,与此同时另一个资源成为漏斗的小口,这时候,瓶颈移动了,优化的预期结果和提升的瓶颈点性能就不吻合了。所以,把带宽,CPU,IO,外部服务,DB,Web线程池等等都看成资源池,找到瓶颈所在去优化,同时在优化过程中不断修正优化目标,达到最后全局优化的效果。         

  场景二,异步化分享中谈到一点,异步化要有全局观。例如A依赖与B系统,组成了一个完整的服务体系,通过异步化方式将A的资源生命周期缩短到只有A处理的时间,B的资源生命周期就是B的处理时间,此时如果A是原有整个系统的瓶颈,那么就会产生雪中送炭的效果,系统整体性能会有所提高(大部分情况下,原因看后面介绍)。如果B是瓶颈,那么就是雪上加霜,更多的水流被放进来,如果B自身没有流量控制,那么系统就会处于不健康的状况,甚至奔溃,系统的整体RT时间可能会增加(A节省的时间小于B增加的时间)。因此这就是系统间瓶颈移动产生的影响,同样也和一个系统一样,考虑优化一定是整体性的考虑,否则问题不会朝着预期的方向解决。

上一篇:代码背后的点滴
对我有帮助
(0)
0%
对我没帮助
(0)
0%
返回顶部
在线反馈
在线反馈