软件性能与性能测试第1部分

1、软件性能与性能测试教程 第 1 部分中国软件评测中心 陈 兵本系列教程对软件性能与性能测试这个主题进行了较为全面的介绍和分析。教程分为三个部分： 在第 1 部分，讲解了软件性能的基本知识，介绍了常用的软件性能指标，在分析 影响软件性能因素的同时，以实例清晰讲解了如何提高软件的性能及性能的可扩展性等问 题；在第 2 部分，首先给出了性能测试的基础知识， 然后侧重于从性能工程的角度提出开展 性能测试工作的流程，和进行性能测试工作的策略，以及如何分析性能测试数据；在第 3 部分，从开发的（而不是第 3 方测试）角度，以实例为引导，一步一步地分析讲解在开发环 境下进行性能测试的策略、方法和手段（采用的

2、工具） 。本系列教程可以用作软件开发人员、软件测试人员、软件项目经理、软件质量人员和 需要了解软件性能测试的各级软件管理人员的工作参考手册， 也可作为有志于软件开发和软 件性能测试领域人员的参考资料。 .在 20 世纪 60 年代，计算机资源还十分有限， 效率是被关心的最重要问题。 到了 70 年代计算机迅速发展，程序员意识过分专注于性能会损害程序的可读性 和维护性。因而软件性能和代码调整受到的重视程度有所下降，随着 80 年代微 型计算机的革命，性能限制又把效率问题提出来。在整个90 年代中它被人们关注的程度则逐渐下降。 21世纪初，移动电话和 PDA 等设备上嵌入式软件受到的 内存限制，以

3、及解释型代码的执行时间过长，使效率再度成为了一个热点话题。1. 什么是 软件性能 系统的性能是个很大的概念，覆盖面非常广泛，对一个软件系统而言，包 括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符 合程度；其次性能是软件产品的一种特性，可以用时间来进行度量。通常，对于软件性能的关注是多个层面，用户关注软件性能，系统管理员 关注软件性能， 软件开发人员也关注软件性能， 那么这些不同的关注者所关注的 “软件性能” 的具体内容是不是都完全相同呢？如过不同， 那么不同点在哪里？面我们从三个不同的层面对软件性能做一个简要

4、的介绍（1）用户视角的软件性能从用户角度来说，软件性能就是软件对用户操作的响应时间。（2）管理员视角的软件性能从系统管理员的角度来看，所重点关注的软件系统性能是：系统的响应时 间;系统运行时服务器的状态，如 CPU利用情况、内存使用情况等；系统是否能 够实现扩展；系统支持多少用户访问；系统性能可能的瓶颈在哪里；系统是否支 持7*24小时的业务访问等。（3）产品开发人员视角的软件性能这也是本文的视角，即本文从开发人员的角度来讨论软件性能与性能测试。 从开发人员的角度来说，会关心主要的用户感受一响应时间，因为这毕竟是用户 的直接体验；另外，开发人员也会关心系统的扩展性等系统管理员所关心的内容， 这

5、里指的是性能而不是功能的可扩展性， 这个问题本文的后面讨论；但对开发人 员来说，最想知道的是“如何通过调整设计和代码等等 方法来提高软件的性能表 现”和“如何发现并解决软件设计和开发过程中产 生的由于多用户访问引起的缺 陷”等等，参见表1。表1给出了开发视角的软件性能关注内容。开发人员关心的问题冋题所属环节架构设计是否合理？系统架构数据库设计是否合理？数据库设计代码是否存在性能 方面的冋题？代码系统中是否有不合理的内存使用 方式？代码系统中是否存在不合理的 线程同步方式？设计与代码系统中是否存在不合理的资源竞争？设计与代码从表1中可以看到，问题所 属的关键环节是在代码构建上面。从开发人员的角度

6、来看，可以用 如下五个方面来作为评判性能的标准：1）运算的性能一一哪一个算法的执行性能最好？2）内存的分配一一程序运行时需要耗费多少内存？3）启动的时间一一程序启动需要多长时间？这在 Web项目中的影响不大, 但要注意部分程序需要部署或运行在客户端时的情形（比如Applet程序）。4）程序的可伸缩性在压力负载的情况下，程序的性能如何？5）性能的感知用户在什么情况下会觉得程序的性能不好？ 以上五个方面，在具体的使用场景可以有选择的去评判。关于如何提高系 统性能的问题，我们在下节进行讨论。2. 如何提高程序的性能 要提高软件的性能，我们可以从以下几个方面着手， 使用高性能、速度快的硬件- $ =

7、速度 使用恰当的编程语言和进行编译器优化 设计可扩展的应用程序架构设计方面 选择正确的数据结构和算法 代码调整避免使用较慢的 OS APIs调整、测量（注意是测量而不是测试）、再调整、再测量 （1）从上面的几个方法来看，使用高性能、速度快的硬件很容易理解，也 是决大多数人在碰到性能问题的时候首先会想到的办法。采取这样的方法总是很 有效的吗？（2）使用恰当的编程语言和进行编译器优化也是提高软件性能的方式之 一。例如在使用Intel C+编译器时，编译器选项可以组合。每种优化各有其特 点，尝试着各种优化选项的效果，有时各种优化选项组合使用可能效果更好。使 用时，这些选项加到Project Sett

8、ing对话框中。如图1所示。Project Settings?X图1同样，在原则Java语言构建软件系统时，可以 针对JDK进行调优。例如： 选择合适的JDK版本：不同版本的JDK，甚至不同厂家的JDK可能都 存在着很大的差异，对于性能优化的程度不同。一般来说，尽可能选择 最新发布的稳定的JDK版本。最新的稳定的JDK版本相对以前的JDK 版本都会做一些bug的修改和性能的优化工作。垃圾收集：垃圾收集就是自动释放不再被程序所使用的对 象的过程。当 一个对象不再被程序所引用时，它所引用的堆空间可以被回收，以便被 后续的新对象所使用。垃圾收集器必须能够断定哪些对象是不再被引用 的，并且能够把它们所

9、占据的堆空间释放出来。如果对象不再被使用， 但还有被程序所引用，这时是不能被垃圾收集器所回收的，此时就是所 谓的“内存泄漏”监控应用程序是否发 生了内存泄漏，有一个非常优 秀的监控工具推荐给大家 Quest公司的JProbe工具（这样的工具非 常多，有许多是开源的），使用它来观察程序运行期的内存变化，并可 产生内存快照，从而分析并定位内存泄漏的确切位置，可以精确定位到 源码内。这个工具的使用我在后续的章节中还会做具体介绍。Java堆的优化：Java堆是指在程序运行时分 配给对象生存的空间。通过 -mx/-Xmx和-ms/-Xms来设置起始堆的大小和最大 堆的大小。根据自己 JDK的版本和厂家决

10、定使用-mx和-ms或-Xmx和-Xms。Java堆大小决 定了垃圾回收的频度和速度，Java堆越大，垃圾回收的频度越低，速度 越慢。同理，Java堆越小，垃圾回收的频度越高，速度越快。要想设置 比较理想的参数，还是需要了解一些基础知识的。Java堆的最大值不 能太大，这样会造成系统内存被 频繁的 交换和分 页。所以最大内存 必须 低于物理内存 减去其他应用程序和进程 需要的内存。而 且堆设置的太 大，造成垃圾回收的时间过长， 这样将得不偿失，极大的影响程序的性 能。在效率 方面，程序的效率与 详细设计阶段确 定的算 法的效率直接有关。在 详细设计翻译转换 成源程序代码后，算法效率反映为程序的

11、执行速度和存 储容量 的要求。要从计算 复杂性、内存的使用、 数据依赖 性等多方了解，使用如何实现 算法指导起一个重要作用。而数据的依赖性与指令的选择密切相关，以Intel86x指令结构为例： 选择指令需要实现一种算 法的指令可能对性能有一个大的 影响。因此检测采 用某个算法中的某些指令，像整数加法可能执行两个/s，还执行其 它指令；像整数除法，可能每23Clock才能执行一次。由于不同的 指令有不同的 延迟和吞吐量，指令的速度是一定的。指令输入准备好以后（ 预取来自内存），指令的延迟是要求执行开 始并完成一条指令的时钟数。例如：整数乘大约15-18 Clock。所有， 乘法的响应在它开 始执

12、行以后有可利用的 15-18 Clock。指令的吞吐量是开始执行相同的指 令之前处 理器要求等 待的时钟 数。指令的吞吐量总是少于或等于指 令的延迟。乘法的吞吐量是 5Clock，意味着新的乘法可能开始执行每5Clock，即使它 花费 15-18Clock去响应任何指定的乘法。指令流水线引起吞吐 量和延迟 的 Clock 数是不同的。数据的依赖性和指令的平行性数据的依赖性影响处理器的同 步执行指令的能力，它能提高算法的性能。Pentium处理器是能够每个Clock执行六条指令但由于指令流的问题，同步执行 指令数经常是较低的。理想的情况如 图2所示：乘法：a=u*v b=w*x c=y*z051

13、0152025a=u*v b=w*x5ClockC=y*Z吞吐量|I'15ClOck"图2延迟图2这是假设这些指令之间没有数据依赖性存在，允许它们同时进行，只 有指令的延迟和吞吐量的限定。在实际情况下，数据依赖性往往存在，并且这会使结局有巨大的不同，如 图3所示：规则在图3中，数据的依赖性和延迟限制指令的平行性对算法性能来说是关键 的限制因素。补充指令平行性规则对各个已存在的处理器家族已有说明，但用数 据依赖性和延迟解释能产生一个稍微好些的执行指令，可以忽略补充指令平行性乘法： a=w*x*y*z051015202530w*xy*zwx*yzI 1】 I35Clock吞吐量数

14、据的依赖性对于线程的监控可以借助很多工具来完成，图4是采用JProfiler对线程进 行的监控例子亟 JPFtsfll酎 EAnlniated Bezier Curve DemoCPU viewt亠口凶 ecsHan Edit ProlMer Viswc Windmu lie Ip4 © 越渤& &心 ProflriQ-AviewsHeap wdteThread vlevMSvMviews图4(3) 设计可扩展的应用程序：指的是软件性能上的可扩展。这点可能会使 很多读者感到很困惑，难道还有哪些设计会 造成使用更高速度的硬件不能提高软 件的性能吗？答案是肯定的，如果一个

15、软件设计的不具备可以扩展性，那么在 4 个、8个CPU的机器上运行会 比在1个CPU的机器上运行的速度 快不了多少。 让我们用一个例子来说明这个问题。这是一个SMPT服务器的例子，为了说明问题，我们 将该邮件服务器的实 现进行高度抽象(实际要复杂的多)。这个服务器的基本功能就是：发邮件，来 邮件后进行处理，分析邮件发给谁，如果发给是本机的邮箱的人员就给把它直接 拷贝到一个邮箱中去。如果是传送的另外一个SMPT服务器的，就通过TCPIP 把它给转发出去。高度抽象后的抽象SMPT服务器/ Read SMTP commands/data from sockets-首先把邮件从 sockets读进来I

16、f (ReadFile( ) / various housekeep ing removed / Parse SMTP recipients and other headers- 分析读进来的邮件，先分析头 文件(地址，来源的信息)If (!ParseSMTPHeaders( )/ han dle errors/ Parse bodies-然后分析文件的 bodiesIf (!ParseSMTPBodies( ) / handle errors / Local delivery or rout ing做判断If (LocalDelivery( )- 本机 Deliver( ); 拷到一个目录下

17、 else 下一极SMTP服务器Route();转发到另外的SMTP服务器/ Send SMTP response through SocketIf (WriteFile( ) / various housekeeping skips写文件或Socket穿到另外的服务器传统的线程的设计方法是这样做的：1 thread to receive and dispatch SMTP request64 worker threads doing(: 64 个工作线程去做剩余的 4 个步骤)Parse SMTP headersParse SMTP bodiesLocal deliveryRouting每一

18、个线程都一步一步的依次做这 4 个步骤，然后在做下一个，不断的 重复。这样的设计其性能就不具备可扩展性，如 果感到邮件服务器的处理能力不 够，通过增加 CPU 是无法提高其处理能力的，为什么呢？前面在讲到效率的时 候，我们说要从内存的使用等方面进行考虑。下面我们看看相关硬件对这个设计 的影响。我们都知道，对于存 储来说，存取速度的快慢从高到低的顺序是：L1 cache ->L2 cache-RAM ->。因此，如果我们的代码从硬盘上读入进入cache后能够 很好的在cache存放，你的程序的不断的被重用，不断的被执行的运行，你的效 率就会非常的高。而如果你的大不分程序都要经常从硬盘

19、、从内存读入后执行， 那么你的程序效率当然就会很低了。而且你也知道，虽然这些年CPU、内存的 速度增长很快，但是硬盘的读写速度并没有多大的提高。这里有个比喻：如果1 秒钟可以清零一个寄存器这样的简单操作，那么：在L1 cache中操作-只需要1秒（1倍）在 L2 cache 中操作 -需要 4 秒（plus 3 seco nds extra work - 7咅）在RAM 中操作-需要25-150秒（24倍-150倍）在磁盘中操作-则需要3个周（2,000,000倍）因此我们的设计应该充分的利用cache或内存，这样程序的效率才能够得到 高性能。SMPT服务器的全新设计是：1 thread to

20、 receive and dispatch SMTP request与原来的设计一样）2 worker thread per CPU剩余的 4 个步骤，每个步骤对应一个队列，线程每一次都把一个队列的 全部工作都做完后，才做其它的步骤。Parse SMTP headers/bodiesLocal deliveryRoutingSocket send and file I/O这样一来，有什么好处呢？很显然，对于每一个步骤来说，数据是不一样的，但是程序是相同的，每次都处理一个队列中的所有内容，因此程序得到了不 断的重用。图5给出了两个设计的效果比较。Overall Performa neerep6

21、8 SMTP Server ThreadsTraditi onalThreads30000250002000015000100005000024Number of CPUs图5(4) 代码的调整：代码优化的方法有许多，针对不同的环境、编程语言等都有特定的有关 优 化方法，可以参照相关资料，例如在Java编程方面可以看看Java Performanee Tunin g(O'Reilly)这本书。代码是要在个 编程过程中不 断进行调整的，因 此调整、测量、再调整、再 测量。通过不断的测量找出需要进行性能优化的部位，那么在开发中如何进行 测量，采用怎样样的方法、工具就显得极为重要了，这方面的

22、问题我们将在本文 的后面详细讲述。持续性能检测、监视和改进代码，这样容易做到性能优化，而 且还可以有效的发现和 改进性能。而等到最后才开始优化性能，会变得更困难和 费时。3. 有关软件性能的基础知识(1) 多进程多进程是在同一个系统中执行多个进程或程序的能 力，多进程的主要好处 是提高系统的吞吐量。某些应用依赖多进程去优化吞吐量。女口：同时有许多用户 登录系统从硬件的角度，提高性能最容易的方法是在主板上放入多于一个的CPU,这 样不同的CPU既可以承担不同的工作，又可以使它们 平行运行，做相同的工作。在一个对称多进程环境中，CPU共享相同的内存，在一个CPU中运行的代 码可能影响另一个CPU使

23、用内存，其结果会受影响。如：你不能确定早先你给 变量设定的值仍是原值，因另一个CPU可能对它做了操作。（2）多线程多线程是一个进程在相同的 地址空间里同时执行多道 线程，这些线程有不 同的执行路径和独立的堆栈，也可能线程有相同的执行 路径而操作不同的数据。 如：一个线程打印，一个线程计算并存或同一个应用计算用多个 线程，各自有不 同的数据等。系统支持多线程可以改进各个应用的性能。（3）加速加速是调整后的性能与 原性能之比，或它是基线的测量性能和优化后的性 能的典型计算之比。当你设置调整目标和测量改进性能时，它是有用的。加速通常有两种表示方法：Baseli neTimeTime =Optimiz

24、edTimeOptimizedTimeRate=Baseli neTime（4）可测量性可测量性是隐藏在应用和系统中的一种能 力，由增加资源数量来提高性能。 女口：向系统中加入更多的处理器、更多的RAIDs、或更多的磁盘组成RAID， 应用程序性能会更好。两种可能的方法检验是否应用是可计量的：ase 1固定负载，用增加CPU提高性能 增加CPU，增加负载来维持性能（5）“Amdahl定律的图形表示和公式Phase 2图61Speed-Up =（1- Fract ion Enhan ced）+ Fract ion EnhancedSpeed-Up of Fract ionEnhanced如果仅有

25、一半的执行时间被优化，2倍的加速是不可能的4. 主要丿性能指标稚类(1) 并发用户数(Concurrent users supported并发用户数是指在某一给定时间内，某个特定点上进行会话操作的用户数 网站的公式网站并发用户数公式如下：网站并发用户数 =RPS + SBC + Thi nki ng Time这里：RPS (Request Per Second ) 每秒请求数(吞吐量)SBC (Simulta neous Browser connections) 并发连接数Thi nking Time平均用户思考时间(2) 响应时间(Response time or latency响应时间指的

26、是客户端发出请求到得到响应的整个过程所经历的时间。例 如从初始的请求到回应下载的完成(刷新整个网页)之间的时间，参见图7。图7你可以测试在服务器上和在客户端上的响应时间：服务器端的响应时间 (Late ncy measured at the server) 这个时间指的是服务器完成请求执行的时间，不包括客户端到服务器端的反应(请求和反应在网络上的通讯时间)客户端的响应时间(Latency measured at the client) 这个反应时间等于客户端的请求队列加上服务器的反应时间和网络的反应时间。你可以用各种各样的方法来测试反应时间。常用的有两种方法：首字节响应时间（度量首字节的响应时

27、间，指向服务器发送请求与接收到响应的第一个字节之间的时间）和末字节响应时间（度量末字节的响应 时间，指向服务器发送请求与接收到响应的最后一个字节之间的时间。 ） 通过测量响应时间，您能知道您的应用程序是否因为响应时间太久以至于 不能响应请求。（3）吞吐量（Throughput 吞吐量是指单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力。一般来说，吞吐量由负载（如用户的数量）或使用什么类型的应用程序来 决定（举个例子，下载文件比浏览网页需要更高的吞吐量）。如吞吐量用请求数/ 秒或页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或处理的业 务数/小时等单位来衡量。从网络

28、的角度来说，也可以用字节数/天等单位来考察 网络流量。（4）资源利用率资源利用率是指系统资源的使用程度，比如服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。1）内存（Memo）内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁， 说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数 据块从RAM移动到磁盘的过程，其目的是为 了释放内存空间。尽管某些页交换 使操作系统能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降 低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请 从以下的参数指标开始：Comimtte d Byt

29、es in Use （正在使用的字节的百分比）：是MemoryComirtte d Byte s 与 MemoryComirt Li m t 之间的百分比比值, 即已分配给物理RAM用于存 储或分配给页面文件的虚拟内存。Availabl e Byte s （可用物理内存数）：显示了物理内存的剩余量。该值 低于4MB,并且达到分钟级时，表明内存不足Rage Faults/sec （每秒钟的缺页数）：该数值反映了有多少个请求的信 息不在物理内存中对应的位置上。该值偶尔高时，表明有线程竞争，持 续走高时，表示可能有内存瓶颈。Pages/ sec （显示 page in put/ sec 和 page

30、 output/ sec 的总和）：page in put/ sec反映的是物理内存的短缺情况；page output/ sec显示从物 理内存中调出的信息量，反映了计算机的繁忙程度。一般如果 Page /sec 持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内 存，以减少换页的需求（你可以把这个数字乘以 4k 就得到由此引起的 硬盘数据流量）°Page / sec的值很大也不一定 就表明内存有问题，而 可能是运行使用内存映射文件的程序所致。由于过多的页交换要使用大 量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁 盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必 须跟踪磁盘使