起航学习网

- 让每个人都能学到最前沿新知识、新技能!
起航学习网
当前位置: 起航学习网 > 人在职场 > 实时大数据处理性能瓶颈的测试

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

时间:2021-05-02 15:46:49来源:深圳软件开发测试培训学校 作者:软件开发测试培训网 已有: 名学员访问该课程

前言: 曾去一家公司面试,他们就问到我有没有用过什么性能瓶颈的测试工具,当时还真没去好好了解。回来后搜索了一下

曾去一家公司面试,他们就问到我有没有用过什么性能瓶颈的测试工具,当时还真没去好好了解。回来后搜索了一下,发现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命令。

软件开发测试人才四大魅力元素

——就业竞争小

——高薪没商量

——就业质量高

——无性别歧视

套用狄更斯那句话说:对于急需软件开发测试人员的企业来说,这是一个最坏的时代,但对软件开发测试人才来说,这是一个最好的时代。“随着软件市场的成熟,人们对软件作用的期望值也越来越高,软件的质量和功能可靠性也正逐渐成为人们关注的焦点。”

文章出自:http://www.epx365.cn/jyzn/202179553.html

文章标题:实时大数据处理性能瓶颈的测试



免责声明:本站文章均由入驻起航学习网的会员所发或者网络转载,所述观点仅代表作者本人,不代表起航学习网立场。如有侵权或者其他问题,请联系举报,必删。侵权投诉

(责任编辑:深圳学历教育网)
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
------分隔线----------------------------
发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
培训学校
IT培训网 访问该机构站点 报名留言 加为好友 用户等级:注册会员 用户级别:10 机构名称:IT培训网 联 系 人:罗老师 联系电话:13783581536 联系手机:13783581536 在线客服:起航学习网客服 在 线 QQ:起航学习网客服 电子邮件: 网站域名:http://www.cnitedu.cn 注册时间:2016-07-18 11:07 最后登录:2021-05-02 14:05