性能测试过程中需要关注的点有哪些？

Feng.Lee

1051人浏览 · 2025-01-18 16:12:05

Feng.Lee · 2025-01-18 16:12:05 发布

我们在进行性测试过程中，需要注意系统架构的哪些关注点呢？常见的有如下几个，系统资源，操作系统，数据库存储，中间件，应用程序，web服务等。

一、系统资源

系统资源包括CPU，内存，存储介质等，这些是系统运行的基石。虽然不同的应用系统业务不同，但是对系统资源的所求都是一样的，这些硬件资源的利用也相互影响。

一般硬件资源瓶颈的表现如下。

1>CPU利用率过高。

CPU利用率又分为系统CPU利用率(以Linux 系统为例，操作系统占用的CPU)与用户CPU 利用率(用户程序占用的CPU，例如我们运行的应用系统》。

CPU利用率过高的常见原因有：

计算量大，如运算、连接查询、数据统计。

非空闲等待，如IO等待、资源争用(同一资源被不同线程请求，而此资源又需要持一致性，只能释放前一个后再访问下一个，从而导致等待)。

过多的系统调用，系统调用即调用操作系统提供的程序接口，例如，Java项目中写日志，会调用系统接口进行写操作，这样会导致系统CPU使用率比较高。

过多的中断，中断是CPU用来响应请求的机制，例如，键盘的输入、鼠标的单击等都会产生中断。中断是通知CPU有任务需要响应，CPU停下正在执行的程序来响应当的中断。

2>内存吃紧。

内存吃紧的原因比CPU简单得多，多数是过多的页交换与内存泄露。

什么是页交换呢?

我们知道内存是用来缓解磁盘与CPU之间的同步差，在内存中会缓存一些数据，但内存的容量是有限的，内存不够用来存储需要的数据时，操作系统会把原内存中的部分内容释放掉(移除或者存入磁盘)，然后再把需要的内容载入，这个过程就是页交换。

例如，读取一大文件，或者我们常见的大文件下载功能。

Java程序运行在JVM之上，JVM的内存设置也是有限制的。有时候JVM堆内存中有些对象无法回收,久而久之就没有空间来容纳新的对象,最后导致JVM崩溃，这就是内存溢出这种内存对象回收不了的现象就是内存泄露，往往是由于程序原因引起的。

Windows与Linux系统的内存管理机制会有差别。Windows需要保留一定的物理内存供系统使用，并为了缓解内存不足的情况设计了一个虚拟内存机制，把部分物理磁盘空间虚拟成内存使用。如果已经开始使用虚拟内存，多数是物理内存吃紧了。

Linux 则是尽可能地利用所有的内存，例如，开辟内存空间用来缓存数据。但是对于 Linux来说，如果已经开始频繁地使用虚拟内存，也说明物理内存吃紧了。简单、粗暴的方式就增加内存、增加机器；最根本的方法是减少不必要的调用，减少内存资源占用。

3>磁盘繁忙，数据读写频繁。

我们知道，磁介质磁盘的读写是物理动作，所以速度受限。如果频繁地对磁盘进行读写，因为磁盘的瓶颈导致的CPU等待的情况会激增。虽然现在有了SSD，但SSD相当昂贵，因此磁盘的瓶颈问题是相对突出的问题。

4>网络流量过大。

高并发系统由于访问量大，带宽需求会比较大，导致网络拥堵。如一个PV(访问一个页面的单位)100KB，同一时刻10万用户在访问，那么此时占用带宽大约就是:100KBx100000/1024~977MB，换算成bit/s是

977x8/1024~7.6(Gbit/s)

注:有关 Liunx 内存交换可以参考 htps:/www.linux.com/news/all-about-linux-swap-space/76

二、操作系统

操作系统是系统资源的管理平台，不同的操作系统对运行的应用系统会产生不同的影响。我们简单地把系统分为Linux与windows两个阵营。Windows操作系统倾向于将更多功能集成到操作系统内部，并将程序与内核相结合而Linux不同于Windows，它的内核空间与用户空间有明显的界限。

Windows与Linux在内存分配上面也有区别。Linux尽可能地利用可用内存，所以在Linux系统中我们一般不讨论内存利用率，需要考虑Buffer与Cache内存及可用内存，在Windows中我们只看一个可用内存就够了。内存够不够用，不能只看上述这些方面，:在还要结合其他的参数，如用页交换、中断、缺页中断等来分析是内存不够用还是磁盘有性能瓶颈。

另外，操作系统对线程数量一般都是有控制的，这也会影响服务器提供服务的水平。随着64位系统的普及，这方面的影响将变得较小，我们也可以手动调整这个限制。

我们在分析系统性能时，多数是通过事务的响应时间来倒推找出性能瓶颈出现的位置，同时也会监控硬件平台及中间件，通过这些监控信息，我们能够确认硬件平台的性能瓶颈在哪里。例如,过多的CPU中断及等待很有可能就是内存与磁盘有瓶颈;磁盘与内存已经够快够大，那么问题就可能出现在上一层，例如，是程序低效，程序读取或者写入了大量的数据导致内存中页交换频繁，磁盘读写量大。

操作系统要关注的是：

1>系统负载:

Windows是ProcessorQueue Length，Linux是load average。系统负载的意思就是CPU的任务队列长度，什么是任务队列呢?例如，我们的CPU是一核，同时有多个任务请求，此时CPU处理不完，又为了有好的用户体验，我们可以把任务用一个队列来缓存，然后从队列中拿到任务去处理。CPU任务队列是由操作系统来控制的，所以是操作系统层面的监控项。现在多数系统都已经是多CPU、多核，在计算loadaverage时要考虑CPU的个数与核数，例如，主机上有2个CPU，每个CPU又是4核，那么同时可以处理8(2x4-8)个任务。load average大于1时就说明系统已经很繁忙了，为2时已经在排队了，我们本着最大化“压榨”主机性能的前提，建议CPU负载最好小于2;公式为“任务数/(CPU个数x核心数)<2”。当然有些企业为了保证系统的安全，会限制load average，将其控制在0.7以下(我们所说的7分饱)。

2>系统连接数的控制

操作系统为了安全会限制外部及内部建立TCP连接的数量，在服务器环境中，我们需要提供大量的服务，TCP连接数量会很大，此时需要修改TCP连接数的限制。

3>缓存

操作系统一般都会有缓存机制，内存不够时还会有虚拟内存机制，这些都是用来提高 IO 效率的手段。

三、数据库存储

当前，绝大多数应用系统都离不开关系型数据库的支持，系统性能的好坏很大一部分是由数据库系统、应用系统数据库设计及如何使用数据库来决定的。我们简单地把这些应用系统分为OLTP(On-Line Transaetions processing,联机事务处理)与OLAP(On-Line Analytical Processing ，联机分析处理)两种。不同的系统应用决定了不同的设计方法，不同的设计方法将表现出不同的性能。OLTP和OLAP的区别，如下表：

对于 OLTP 类型，常规办法是：

(1)优化业务过程，尽量减少数据请求，不管是读还是写:(2)优化 SQL语句提高效率。对于OLAP 类型，常规办法是:

(1)预处理，例如，物化、多维数据，先把数据放在后台统计，生成一个较小的数据然后程序对物化后的数据进行访问来减小系统压力:

(2)分而治之，例如，并行查询，利用Hadoop处理非结构化数据:

(3)优化语句提高效率。

当前，我们面对的系统大多数都是OLTP类型，经常要关注的是:

(1)慢查询;

(2)大事务;

(3)死锁;

(4)DB Time 高;

(5)磁盘IO等待时间;

(6)对于一些热点数据，可以置入内存，提高响应速度，常见的缓存如memcache、redis等，Hibermate 这种 ORM 模型的框架也提供了二级缓存支持。

近几年，大数据应用技术崛起，各种非关系型数据库也成为主流，例如Redis、HBElasticSearch、MongoDB等。这些数据库的特点鲜明，在各自擅长的领域性能优异，同时会有自己的短板。了解其原理之后对其性能表现能有一个大体印象，更有助于对其进行性分析。

四、中间件

J2EE架构的程序多数运行在 Tomcat、Jboss、WebLogic、WebSphere、Jety等中间件作为Java应用程序容器，中间件有其特定的指标项。

JVM:中间件运行在JVM 之上，我们需要监控JVM 堆内存的使用情况，包括GC频率、线程状态等。Full GC操作是对堆空间进行全面回收，此时是停止响应用求的(当前新版本Open JDK和Oracle JDK的回收算法已经可以做到不停止用户的情况下进行内存回收)，所以须繁地Full GC会影响响应时间。监控线程运行状态可以帮助我们了解到线程的繁忙程度，一般我们要关注的是Blocked状态线程，此状态说明当前线程运行相对较慢，长时间的Blocked可能是因为线程阻塞，进而造成死锁。

Tread pool：为了节省建立连接、销毁连接的资源消耗，中同件在接收用户的请求时设计建立线程池。我们需要监控其使用情况，一般当超过一定的使用率时可以考虑加大链接池数量。

DB Connections pool(数据库连接池)：为了节省程序与DB 建立连接、释放连接的池数量。资源消耗，设计了数据库连接池。我们在测试执行过程中也需要监控其使用情况，当超过定的使用率时可以考虑加大连接数数量。不管是 ThreadPool还是DB Connections Pool，我们都可以通过 netstat 命令统计到其连接数。

五、应用程序(App Server)

当前的系统多采用分层开发的方式，各层分别完成不同工作。分层不但用来简化工作的复杂度，还用工程思想来组织系统开发运作，方便协作，不同的人员各司其职，层次清晰，方便维护及管理。

不同的架构存在着不同的性能短板，抽象层次越高(底层封装程度越高)，则开发效率越高,对开发人员要求越低(基础功能底层已经实现，开发人员专注业务实现)，性能风险越大往往性能风险都会集中在这一层次。

我们常见的SSH(Spring StrutsHibemate)架构是 MVC 模型，结构如下图所示。展现层 Vew(V)负责展现内容，Controller(C)负责请求接收、前台逻辑跳转；Model(M)层实现业务逻辑，返回数据:数据层负责与数据库打交道。这里我们把业务逻辑与数据访问归类到应用程序部分，展现层归到Web 服务层(Web Server)。

在应用程序这一层，性能问题多数表现在程序逻辑混乱、调用复杂，甚至是设计不合理，总而言之就是低效程序或者是相对低效程序。

例如AppServer提供了「接口，性能测试时我们可以直接调用这个接口进行测试，自然可以精确衡量其响应时间，然后分析其性能。不过，一般并不需要这样做，我们可以通过样除法来分析是否是AppServer 的问题。

六、Web服务(Web Server)

按照分层开发的理论,这一层仅是页面跳转控制与结果的渲染(如图5-3 所示的展现层)。

当前前端技术的多样化，展现的内容也更加丰富，内容多也导致了一些前端性能问题。

此层关注的问题如下：

1>页面Size，动态数据、CSS、JS、图片等的大小。

2>隐藏的、无用的数据传输:开发过程中为了方便，会继承一些基类，我们需要考虑成本,最好不要有大对象生成，我们在做SQL查询时，只查询需要的字段，对于无用字段排除，避免不必要的数据传输。

一般，对于Web服务性能优化的方向如下。

1>页面静态化。例如，新浪的新闻，先进行静态化，然后提供访问，减小 DB负扭

(2)缩小页面Size。

图片变得更小。

CSS 合并。

JS 精减等·

3>取消无用请求，以及无用数据传输。

4>对数据做异步处理。事情分为多步，先完成优先级高的事情。这就是异步的好处，体验提高，用户停留时间更长，刺激更多消费。大家可以试用去哪儿网站，我们在这个网查询机票时都是一部分、一部分加载的，采用了动态加载方式(后台以JSON 的方式传输据，前台使用JS动态加载渲染这些数据)，尽量只传输动态数据，并异步处理请求(多个调求分开传输)。

5>智能DNS及CDN加速，让响应数据离用户更近，回避网络瓶颈问题

阅读后若有收获，不吝关注，分享，在看等操作！！！