实时大数据处理性能瓶颈的测试

发表于:2017-12-11 09:54

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:hm_yuweixing    来源:CSDN博客

  曾去一家公司面试,他们就问到我有没有用过什么性能瓶颈的测试工具,当时还真没去好好了解。回来后搜索了一下,发现Interl公司的VTune是一款不错的软件。不过要做到像VTune这样细致的,似乎很难。在我的经验里,要定位到哪个语句最消耗性能,这个似乎并不是很难,而往往是把你把消耗性能的代码去掉,它也提升不了多少,或者是最消耗性能的代码就是系统的最核心的操作,你根本无法去掉,甚至已经没有优化的余地了。
  有的系统在部署的时候,CPU占用率大约60%,内存使用率也不过50%,而再多部署几个相同的进程上去的时候,性能却得不到提高。原本每个进程可以处理5MB的流量,当部署更多的时候,每个进程处理的流量却降低到3MB,CPU和内存利用率更低,如此形成恶性循环。我想对待这样的情况,即使使用VTune测试,也不会找到真正的瓶颈所在。虽然我没有机会去解决这个问题,但我想它极有可能是由于代码中没有注意性能瓶颈的要素,比如在核心处理过程中夹杂着IO,导致线程频繁切换,最终形成的有力使不上的局面。
  一、性能指标
  在实时数据处理过程中,以下三个要素往往是衡量系统性能高低的重要指标。
  1、CPU占用率
  这个往往是领导非常关心的问题,因为涉及到硬件成本问题。如果你的一个进程占满几个CPU资源,那其他进程怎么办?放哪里?领导的想法都是尽可能地使用较少的服务器,部署较多的服务,减少购买服务器的成本,所以不要用霸占CPU资源的手段来提高性能。实时处理不但时间很重要,空间也是一个不可忽视的因素。这里再重复提一下,“经过试验,偶得出的结论是,没有数据需要处理时,才可以短暂地sleep一下,有数据时不应该有任何停顿”,这样基本可以在性能和CPU利用率之间达到一个比较合理的平衡。
  我设计的系统都是流水结构,并且一般都符合一个生产者与一个消费者模式,在这种情况下,我最开始并没有将线程sleep,而是监视生产者与消费者共享的一个FIFO的push和pop过程,发现不可以pop的时间远远大于不可以push的时间,也就是说没有数据的时间远远大于可装入的时间,即消费者速度大于生产者速度。在这种情况下,很有必要将消费者sleep一下,以释放CPU资源。
  2、内存消耗
  在现在64位的机器里,内存的成本问题似乎显得不那么重要了,但是为了抵御波峰,我们需要开辟的内存往往超出我们的想象,有效利用内存在调试阶段就显得很有必要了。至于如何提高内存有效使用率将在后续专题讨论。
  3、流量
  实时流量则是最大的性能指标了,只要在系统的入口和出口流量相当,中间过程无overflow就可以了,一般使用流量计实时显示出来。
  二、测试手法
  在国内估计没有公司能支撑一个团队开发像VTune这样软件,当然我也不可能有这样的机会。曾在领导的要求下,使用windows的QueryPerformanceCounter函数做分布式耗时测试,即通过这个API,把每个核心操作的耗时统计下来,然后比较哪个操作最耗时。做了好几次,每次都花了不少时间,可得出来的结果是核心操作的耗时差异不大,而且是远远小于程序运行的总时间。至于这样的测试,为什么会得出这样的结果,结果是否正确,结论是什么,我不想过多地讨论,但在后来的工作中,我按照自己的思路,注意我在《实时数据处理性能瓶颈》一文中的要点,将一个前端采集系统由原来的30MB提高至4Gb。其实100Gb也无所谓,因为我是并行结构。
  我没有VTune这样牛X和细致,也不想使用所谓的耗时分布测试手段,但我发现我做到以下两点,基本就可以将性能提升一到两个数量级。这两点的测试手法都是把流量计嵌入到代码中,实时地显示出来。
  1、核心流水业务节点测试
  由于这个前端系统已经存在,所以在重构这个系统时,我需要一步一步地来移植已经存在的业务逻辑。每当我完成一个核心处理的移植后,我就进行该段核心业务的性能测试,从而排除后续过程对该段业务过程的影响。在测试前,我首先会将夹杂在逻辑运算中的IO剔除。如果这个地方能满足性能要求,就继续测试下一个流程;如果不行,则会按照《实时数据处理性能瓶颈》中的要点,逐一优化。
  在这一测试过程中,我会监测4个性能指标:
  1) 入口流量    2) 出口流量   3)FIFO溢出次数   4) FIFO利用率
  2、串行逻辑测试
  当上一测试不能满足性能要求后,我会逐一排查其性能瓶颈,将这个核心业务处理的线程分解,理清里面究竟含有几个过程,然后再在里边嵌入流量计,看看瓶颈究竟出在什么地方。当然也会使用排除法,仅运行前面几个过程,尽量缩小范围。
  写到这,就发现测试需要注意的两个事项就是:
  1)降低系统的耦合度    2) 排除异常干扰因素
  三、现象与对策
  在测试与调试过程中,FIFO的溢出异常关键,因为我做的系统中,数据丢失是绝对不可以接受的。其一般表现为两种状态:
  1、快速溢出
  快速溢出则说明该过程是目前这个线程负载不了的,解决方法一般有两种方式,一个就是优化其内部处理过程,提升性能;如果已经优化完了,还不能满足,则需采用并行模式,在上一过程进行数据分流,采用两个相同的线程同时并行地处理该过程。
  2、偶尔溢出
  FIFO在某段时间不溢出,某个时间段溢出,表现的不是很稳定,这一般是由于数据源突然流量增大,FIFO抵御不了这样的波峰,而造成溢出。如果你监控了FIFO的利用率,你就会发现在波峰的时候,FIFO的使用率也非常高,在某个时间就顶不住了。这种情况你只需要将FIFO的size加大就可以了,一直加大到它不溢出为止。当然这有个必要条件就是,你最好将FIFO优化,努力提升其有效使用率,避免FIFO中有大量的空闲区域。
  四、性能指标的监测方式
  性能指标一般是在核心处理过程中计算出来的,如果在核心处理过程中输出,势必影响其效率。我的方法是这样的:
  1) Windows平台
  在核心处理中,将性能指标实时(也不是完全实时,间隔一定的时间)地计算出来,保存在这个核心处理对象中;主线程主要负责UI,一般比较悠闲,所以让主线程去读取核心处理对象的性能指标,并显示在UI上。一写一读,两个线程没有冲突,如此可以解放核心线程的性能指标IO操作。
  2) Linux平台
  Linux采用同样的思想,只不过主线程不是将性能指标实时地显示在UI上(因为Linux多为后台运行),而是写入到一个共享内存,由另外一个进程在需要的时候,实时显示这些性能指标,类似top命令。
相关推荐:
【测试专题】大数据测试正确的打开方式

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号