< meta http-equiv="description" content="在一个需求开始开发之前,一个有经验的程序员应该是要先做设计,在架构设计的过程,我们应该要考虑性能,让架构能够支持足够的数据量,保持架构上能在各种场景都不会出现性能问题。各种处 理分别是在什么时机进行也是要在设计的时候就想好的,只有性能出众的架构才是很好的架构。 "/>

怎样系统性地保障软件的性能

[来源] 达内    [编辑] 达内   [时间]2012-09-10

在一个需求开始开发之前,一个有经验的程序员应该是要先做设计,在架构设计的过程,我们应该要考虑性能,让架构能够支持足够的数据量,保持架构上能在各种场景都不会出现性能问题。各种 理分别是在什么时机进行也是要在设计的时候就想好的,只有性能出众的架构才是很好的架构。

  一个正在持续增加新功能的软件,尤其是类似QQ这种做为一个超大规模客户端软件,又随时需要适应用户要求和发展的需求,需要不断的做快速的更新,开发节奏非常快。而且因为我们的用户是海量用户,用户的软硬件环境非常复杂。性能作为软件的用户第一体验,如何去系统性地保障软件的性能,对于QQ来说就变得非常重要。

  那么要让持续开发的软件的性能能够得到保障,应该做些什么呢?

  1、需求阶段开始考虑性能

  首先从需求提出阶段说起,需求提出阶段应该要开始考虑性能问题了,产品经理提出需求之前,必须要系统性地了解哪些因素会影响到软件的性能,这些因素包括但不限于:需求的处理时机,需求的处理数量,需求的处理是否涉及大的IO,网络,以及CPU。尤其是在使用特性上要思考清楚,比如涉及到消息记录的需求,可能要考虑到有的用户的消息记录很大,比如涉及好友列表的需求,可能要考虑到有的用户的好友列表很多等。

  使用时机的话,比如需求是在登录过程中那么可能要考虑该需求是否会影响到登录速度,如果是在登录后的话,是否会造成登录后卡。

  结合这些特征,对于一些从需求侧就可能有问题的需求,要么考虑直接不做这个需求,要么考虑针对不同的使用特征做不同的处理,比如考虑到消息记录可能有很大的情况,那么涉及消息记录的需求尽量不要去读取整个消息记录。有的时候,也可以考虑切换需求处理的时机,比如在更新好友资料的需求,如果是做在登录过程可能是会引起登录过程很慢,那么需求可以修改成登录过程先加载本地数据,登录后某个空闲时机再去做必要的更新。

  2、需求开发阶段如何考虑性能

  在一个需求开始开发之前,一个有经验的程序员应该是要先做设计,在架构设计的过程,我们应该要考虑性能,让架构能够支持足够的数据量,保持架构上能在各种场景都不会出现性能问题。各种处理分别是在什么时机进行也是要在设计的时候就想好的,只有性能出众的架构才是很好的架构。

  在实际开发的过程,要充分考虑用户的使用场景和并发数量,比如开发一个火车票订票系统,如果不考虑春运的时候的特殊情况,那么最终只会在春运的时候系统直接瘫痪。

  可能这个时候有人会问,春运的时候就是有那么多用户在访问,系统就是支持不了那么应该怎么办呢?至少可以从两个方面去解决,一个方面可以考虑在访问量很大的时候,只提供核心订票等业务的支持,而网页上的一些图片什么的完全可以不提供拉取。另一方方面,可以考虑提供给系统最大支持量的用户正常的服务,而可以对一些超出负载的用户提出的服务短期内进行拒绝。设置可以提供一种排队进入的机制。

  3、测试阶段如何关注性能

  在测试阶段我们还需要做什么来保障性能呢?

  首先我想强调的是,测试是保证产品的性能最终是否达标的最后保障,所以这个环节一定要严格要求。

  从信念上来说,只要开发同学有对代码进行修改,那么都是要怀疑可能引入性能问题的,之前我们的一个打开好友聊天窗口的时候卡的一个性能问题,就是因为在桌面快捷图标的时候在打开聊天窗口的过程加了一行代码。

  测试方法上,要注意用接近现实的一些数据来进行测试,包括前面说到的消息记录的大小和好友列表的数目。另外要注意覆盖各种使用场景。最后还有一点尤其要注意的是要注意用多种机器多种网络环境多种软件环境来测 ,机器的话,主要包括性能好的机器和性能差的机器,机器的网络环境的话要考虑网络丢包比较大的一些情况,还要集合局域网广域网以及中国的各大运营商之间的不同网络场景。软件环境的话,一方面包括不同的操作系统,一方面包括同时运行和安装的软件环境,比如杀毒软件,安全软件,或者是同时在运行一些大型游戏的情况。

  当然最好的情况是,建立一系列的自动化测试框架,把一些我们平常关注的重要数据,比如QQ的登录速度,登录后卡不卡,打开好友聊天窗口的速度等等通过自动化跑出来。通过定期进行自动化测试,同时把数据进行各个历史版本横向比较,最后可以做到快速监控,最快速度发现性能问题。

  4、反馈跟踪如何关注性能

  产品发布之后,依然还要继续关注它的性能。一方面由于我们的用户群体非常大,所以难免有些情况和使用场景没有考虑周全,所以最后运营阶段没有问题的版本才是合格的版本。

  我们一般通过定期关注微博,关注产品本身的反馈论坛,以及外面的一些相关论坛来收集信息。同时关注周边的朋友,以及同事的反馈也是一个很重要的方面。

  在用户反馈有问题的时候,应该要及时去处理,处理方法一方面要先了解用户的使用场景和使用情况,另一方面可以给用户一些工具,通过这些工具去记录当时的CPU,内存,IO的使用情况,当时是否界面有无响应等信息。同时工具最好能够记录在有性能问题的时候软件正在忙什么,当时的堆栈以及系统调用函数是什么,有了这些信息就可以快速的解决问题了。

资源下载