性能测试开展指导

最新推荐文章于 2024-08-23 15:16:24 发布

huangzhiguo

最新推荐文章于 2024-08-23 15:16:24 发布

阅读量1.4k

点赞数

文章标签：测试应用服务器数据库服务器网络 windows

本文链接：https://blog.csdn.net/huangzhiguo/article/details/1222414

版权

1 编写目的

本文档从性能工程的角度提出开展性能测试工作的流程，和进行性能测试工作的策略，下面我们讨论性能工程的需求阶段、设计阶段、实施阶段、产品部署阶段、维护阶段所要开展的工作，和相应要采取的策略。

2 需求阶段

2.1 性能测试需求的确立

2.1.2 确定性能测试需求的解决方法

在没有需求文档和设计文档的情况下，我们需要对TSP系统上的客户业务使用情况进行分析，提出我们所关注的性能测试需求，并告知业务人员。让业务人员来判断我们的性能需求是否能满足客户的真实要求。

在通过TSP系统分析业务使用状况时，我们可以从以下方面来关注：

1、确定当前系统的业务使用状况：通过TSP的日志记录－客户端模块使用情况了解在某个时间段内，客户执行某个操作的具体情况。

2、了解不同视角的用户性能：

ⅰ）用户视角：

响应时间：用户所能感受到的响应时间，也是用户最重视的性能体验。

确立响应时间的原则： 2/5/10 原则

2：2秒钟用户会觉得是一个很好的体验。

5：5秒钟用户可能会觉得差了一点，还行，比较好。

10：10秒钟是用户所能承受的最大极限。

鉴于不同地区的网络环境，将用户所能承受的响应时间极限定为12～15秒。

此部分需与业务人员讨论。

稳定性：系统长时间运行不会出现错误的能力。

验证方法：系统在满负载的运行8小时，系统是否会出现服务不可用，Connection Refused

HTTP 404,500错误。

ⅱ）系统视角：延迟，系统资源使用状况

延迟：包括数据库延迟和网络延迟

此部分需与DBA及系统部人员讨论。

系统资源使用状况：服务器的CPU使用率是否长期高于80％，达到90％，100％的程度，整个磁盘的I/O是否达到极限。内存的使用数是否只剩下极少的几兆，几十兆。

ⅲ）开发者视角：从代码实现和数据库实现来考虑性能。看看这两方面得到实现是否足够好。

3、了解真正的性能测试需求

方法：ⅰ）识别项目干系人：指的是和项目相关的人，开发人员，设计人员，需求人员，业务人员，上层领导，了解他们对性能测试的考虑。

ⅱ）隐藏在“性能测试”之后的实际想法，比如：是因为开发人员对所完成的代码没有信心，又不愿意做修改，要求我们对其所作的程序进行性能测试，还是设计人员使用了一项新技术，心里没低，所要求作的性能测试，等等。

2.2 确立性能测试目标

2.2.1 确立性能测试目标的原则

1、以“需求”为本

考虑系统需不需要作性能测试，性能测试的内容和范围。

2、测试目标确定的经济性考虑

ⅰ）投入到性能测试的人员是多少？

ⅱ）具备可以确定性能测试需求，制定性能测试方案的人员是多少？可以执行性能测试的人员是多少？

ⅲ）这些人员需要投入多长时间？

ⅳ）所要开发系统的运行环境和设备，这些设备的配置对于性能测试的影响，比如说：tomcat4.1的应用服务器，它的配置文件缺省的jvm的使用空间是 64M ，一个机器的内存为 1G ，我们将jvm的使用空间设置为 512M 对性能测试的影响。

ⅴ）内部的人员无法满足性能测试的要求，通过外聘，采用外聘的方式，公司所能承受的成本是多高。

3、基于风险的测试目标确定

ⅰ）系统如果不做性能测试，会有多大的风险，如果在性能指标上达不到用户的要求会有多大的风险。需要进行评估。

ⅱ）如果做性能测试会有多大的风险，性能测试的投入会有多大，会有多大的风险需要进行评估。

2.2.2 确定性能测试目标的方法

我们要确定系统的吞吐量和并发用户数的设计目标可以采用以下三种方式：

l 确定在某个特定时间端内，估计系统会有多少用户同时访问

l 在某个特定的时间端内，正在访问系统的用户的典型操作是什么？哪个页面的访问量最大？

l 在某个特定的时间端内，系统需要处理多少种用户场景

这些数据可以在系统服务器的日志文件、TSP监视数据种找到，也可以通过监视数据库的活动情况来获得。

2.3 不同阶段的性能测试目标

2.3.2 开发阶段的性能测试目标

ⅰ）将开发阶段的性能测试目标作为对系统进行调优的参考：考虑在每个开发阶段，性能是否能够达到标准，考虑当前阶段的性能瓶颈，及其性能瓶颈出现的原因是在于数据库访问（SQL语句或者存储过程写的不够好）还是其他的原因。

ⅱ）用性能测试手段发现系统存在的问题：通过模拟真实场景，发现在现场测试中可能存在的问题，比如说：用户数的突然增加，导致的应用程序崩溃，服务器崩溃的问题。

2.3.3 产品部署阶段的性能测试目标

提供部署方案的参考，确定合适的硬件设备，虽然更高的设备可以获取商业上的利益，但应考虑客户的具体情况。

2.3.4 系统维护阶段的性能测试目标

考察系统的可扩展性：从系统的视角考虑,在用户数扩大，在业务量增大的情况下，是一个怎样的表现。

3 设计阶段

3.1 性能测试方案的确立

在确立性能测试方案之前，需要作的工作

1、确定测试目标和需求

这里的灵活性比较大，与性能测试成败有很大的关系。

2、了解现状

ⅰ）业务使用状况

通过日志记录，在某个时间段内，用户的操作。

ⅱ）了解环境：包括网络条件，服务器条件，软硬件条件，应用服务器环境及各种配置信息。

3、确定需要监控的指标：

ⅰ）CPU使用率

ⅱ）内存使用情况

在此应优先监控应用服务器的性能指标。对于Tomcat或者Weblogic来说，监控他的JVM使用状况，连接池的连接数量，内存使用状况等信息。对于数据库来说监控cache的命中率，索引的使用状况，数据库的连接数。

3.2 用例和场景设计

用例和场景设计的步骤：

1、对业务的分析和分解

2、根据业务确定用例

3、不同用例按照不同的发生比例组成场景

4、了解每个场景的实际意义（对场景执行测试，收集结果）

了解业务的分布情况，根据业务确定用例，在设计用例的时候，根据前期收集的数据，设计不同的场景来组成用例，并了解每个场景的实际意义，执行场景，收集结果数据。

场景设计的例子（主要是根据业务的使用状况）：

l 场景1：10％登录，10％入库，30％订单，20％出库，30％查询（1000用户）——日常

l 场景2：10％登录，90％查询（400用户）——周末盘点

3.3 设定需要监控的资源

设定需要监控的资源主要有一下几个方面：

1、CPU利用率

2、内存使用情况

3、数据库监控

4、JVM使用状况监控

应优先监控应用服务器的性能指标。对于Tomcat或者Weblogic来说，监控他的JVM使用状况，连接池的连接数量，内存使用状况等信息。对于数据库来说，cache的命中率，索引的使用状况，数据库的连接数，具体的监控指标请性能测试工程师，根据性能需求确定。

4 性能测试的应用领域

4．0系统性能测试的主要应用领域是验证能力、性能调优。

1、验证能力包括

ⅰ）验证新的系统，新的架构能否满足用户的需求。

ⅱ）向用户提供性能测试报告，说明系统的性能达到了预期设计的标准。

ⅲ）确定新平台的产品架构，假设以前用ASP，现在用.net，或者换到j2ee平台上，验证新系统架构是否满足性能要求，这个要求不是用户提出来的，也不是直接用户体验的，而是在架构设计过程中要确定的指标。

2、性能调优

在系统开发过程中，通过性能测试，了解当前系统瓶颈（比如说在于数据库访问，SQL语句或者存储过程写的不够好，或者说数据库设计的问题，索引做的不够好），所选择的应用服务器有问题，或者说代码这一层，业务逻辑实现的不够好，导致它性能的缺陷。以确定问题出现在应用层，数据库层，代码层。

5 实施阶段

5.1 分析影响性能因素的步骤

将影响性能的因素按照以下顺序进行判断：

1、网络状况

2、硬件设备

3、系统/应用服务器/数据库配置

4、数据库设计和数据库访问实现（SQL和SP）

5、业务的程序实现

但是在开发阶段做性能调优时关注的顺序：请更多的关注SQL 一级和代码一级。

若是对于一个实际在线上运行的系统，请直接按照以上5点的顺序。

注：很多的性能问题，是由于应用服务器的配置完全不合理，比如：tomcat4.1的应用服务器，没有修改它的配置文件中缺省的jvm的使用空间。

5.2 开发角度性能问题的原因

1、对所使用的技术不熟悉

这是影响最大的因素。对于.net平台，j2ee平台的架构不熟悉，开发人员对于有哪些架构和哪些模式对于性能会有影响不了解，建议开发部门做一下调研。对于性能测试工程师来说，应多了解一些平台的知识，平台的性能。J2ee的平台和它的性能问题是怎么产生的，如何来调整它的性能。

2、系统架构设计的不合理

3、程序员的实现错误

7 维护阶段

维护阶段的性能测试主要在于考察系统的可扩展性：从系统的视角考虑,在用户数扩大，在业务量增大的情况下，系统是一个怎样的表现。

8 性能测试的策略

鉴于我们当前的性能测试工作开展情况，先对3.0系统进行一个容量测试，确定现有系统所能承受的最大用户数及最大业务处理能力。并将这个结果告知用户，让用户了解当前系统条件下的运行水平，系统所能支撑的最大用户数，每个用户的响应时间是多长。并将结果作为以后进行4.0系统制定性能测试目标的一个参照标准。

9 各阶段所要进行的性能测试

除了需求阶段都需要进行性能测试。其他阶段的性能测试需要依据你的性能测试目标：

9.1 设计阶段的性能测试

在设计阶段的性能测试主要的目的是验证你的架构。验证的方式有两种：

1、在对于系统架构有一个预期的性能目标的情况下，去验证当前架构能否满足预期的性能目标。

2、系统架构是基于以前的架构修改过来的，对于两者进行一个对比测试，了解两种架构各有什么优势。

9.2 实施阶段的性能测试

在实施阶段进行性能测试的目的是为了阶段性的验证系统性能，进行性能调优，并通过系统调优发现系统缺陷。

9.4 维护阶段的性能测试

在维护阶段——考察系统的可扩充性/定位系统缺陷，考察系统的可扩充性用来定位系统的缺陷。

10 系统稳定性的度量

为了验证系统的稳定性，我们需要对系统进行一个可靠性度量，在目前没有一个行业或者国际标准进行可靠性度量的前提下，我们又无法获得确切的用户需求（用户提不出系统稳定性的量化标准），我们可以采用如下方式来验证系统的稳定性。

通过在做性能测试的过程中得到系统稳定性数据的方式来验证系统的稳定性

手段：对一个系统进行一个长时间的运行，观察它的可用内存，cpu使用率有无显著的变化，如果在长时间使用的情况下，cpu，内存无显著变化，则可以认为系统具有稳定性。

11 性能测试的基本概念

1、响应时间：客户端从发送请求的那一刻起到收到应用程序响应的最后一个字节时止而不

得不等待的时间长度。

2、点击数：对每一个对象的请求，比如说：一个页面有五个部分组成，一个框架，四张图片，这样算做5个点击数。

3、页面请求：请求了一个页面，不管这个页面包括了多少对象。

4、吞吐量： i）按照流量来计算的吞吐量，用来衡量网络状况或者应用服务器的处理能力，在指定的时间内，每秒钟字节的出入.

ii）用点击数来衡量吞吐量，每个固定的时间段内有多少点击数，用于银行系统。

5、并发用户：从业务上的并发：200人同时在线。

从服务器上的并发：200人同时向服务器发出请求。200人同时做一个提交的操作，服务器接受到多少请求。

6、资源利用率：cpu利用率，内存利用率，磁盘I/O状况等

12 响应时间的分解

响应时间＝网络响应时间＋应用程序响应时间

＝网络延迟N1（数据在网络上传输的时间）＋web服务器请求被处理的时间A1

＋web服务器到database服务器的传输时间N2（如果两台服务器在同一台机器上传输时间就会很短）＋数据库服务器处理数据库请求所耗的时间A2＋database服务器返回请求到web服务器的传输时间N3＋web服务器请求被处理的时间A3＋网络延迟N4

因此，性能的相关性大概为三个部分：网络的延迟、应用服务器处理的延迟、数据库处理的延迟。所以，在开发阶段做性能调优的时候，针对这三个方面进行。

响应时间的获得：用lr可以获得一个完整的响应时间，有两种办法可以获得各部分的数据，

i)自己做一些日志，应用服务器可以接受到的，应用服务器可以接受到的，打开这个日志可以看到他什么时候接受到请求的，来判断网络的延迟是多少，数据库的延迟也可以用同样的方法来做。这种方法的资源消耗比较大，只用于验证已确定的系统中的问题在哪里。

ii)通过各种工具慢慢来做：比如：做某个业务的时候响应速度很慢，可以用排除法来做：第一，猜测是网络的问题，在两个网络之间使用网络测试工具sniffer测试网络延迟，或者用windows操作系统，在windows2000，advanced server也有相应的工具测点对点的延迟。数据库的延迟可以采用将影响性能的SQL语句摘出来，直接在环境下实际运行一下，看实际的处理时间是多少，对于应用服务器的延迟，通过应用服务器本身的日志，或者在应用实现的代码里加一些日志输出来实现。

13 在性能测试中需要注意的问题

13.1 环境设计的问题

1、网络环境

2、软硬件环境

3、环境的维护方案

4、时间同步问题

5、“镜像”环境

时间同步问题：各种服务器部署在不同的机器上，在进行性能测试分析响应时间的时候就需要进行时间同步，通过日志来对比时间，但日志上记录的是本地时间，让日志记录的时间有可比性，需要做时间同步。

同步的方法：在UNIX操作系统上用NTP协议可以做时间同步，在windows系统上可以通过加入域来时间同步，

“镜像”环境的问题：做能力验证的测试的时候，一般要求在现场做，因为这种测试结果和应用服务器网络环境本身会有很大的关系，如果不能做现场测试，

采用的两个解决办法：

i）尽可能的模拟出用户环境：包括网络状况，服务器状况，

ii）和用户去协商：去做现场测试。

13.2 其他需要注意的地方

1、应用服务器的Warm up问题

J2ee应用或者.net应用现在都会涉及本地编译的过程，在第一次做运行的时候，在第一次访问的时候速度会很慢，第二次访问才会快起来，因为从本地Cache中读取信息，所以在应用服务器重启了以后，都必须多测几次，等服务器Warm up后再测试，否则的话，前面的结果没有有效性。整个的结果还会有误差。

2、应用服务器的Cache

在多次测试的过程中，把Cache功能给去掉，或者把cache给清空。

3、浏览器或客户端应用的Cache

客户端和浏览器的cache在录制脚本的时候都应该去掉。

14 确定最小用户负载

14.1 确定最小用户负载的目的

为了全面掌握应用程序的性能――不仅是重压条件下，而且是在更为理想的条件下。这是很重要的，因为应用程序通常将大部分的时间花费在这些低负载条件下。峰值操作通常很少发生。

14.2 确定最小用户负载的方法

从需求上解决，了解业务分布情况，将业务分布情况划分成不同的场景，确定一个负载使用状况最小的场景。执行此场景，观察系统在此场景下的运行状况。

15 性能测试的两个基本类别

15.1 预备测试

预备测试：最初的试探性测试，让我们能够感受一下应用程序的性能并优化测试环境。

15.2 正式测试

有四个正式的性能测度，我们的分析就建立在这些测度上。可以将这些正式测试按照类型分成如下几个子类：单实例压力测试、持久测试、体系结构测试一旦按照初步测试结果设置好了环境和测试参数（测试脚本、思考时间、采样方法等等），这些因素就必须对任何特定的性能测试都保持不变。如果在某个特定的性能测试中修改任何参数，那么我们就破坏了结果的可比较性，将不得不重新执行测试。

16 性能测试生存周期

l 规划性能分析

l 创建有效的压力脚本

l 执行压力测试

l 分析性能测试数据来确定和解决性能瓶颈

规划性能分析阶段的工作包括收集重要的原始数据，然后根据这些信息制订测试方案。规划阶段收集到的信息至少应该描述两个方面的内容：

l 用来复制一个接近生产环境的测试环境的细节。

l 对该应用程序的使用方式的理解，以及临界性能表现的迹象等。这些信息可以来源于市场预测报告、站点的IIS日志、站点的性能日志和站点功能说明等。

创建高效的压力测试脚本 在收集了所需信息并搭建了测试环境后，下一步就是创建测试脚本，它应该能够准确地模拟站点期望地流量。最有效地方式是根据实况网站中的历史数据结合市场调查或商业分析而得到这些期望数据。

执行压力测试 创建可以模拟最大用户负载的压力测试脚本。

分析性能测试结果

(i)确定性能瓶颈

影响终端用户响应时间的瓶颈包括应用程序和服务器的吞吐量、终端到终端的Internet连接速度以及网络涌塞等。

（ii）检验性能优化结果

分析结果了解系统的性能状况并能够对性能进行提高。

17 后台活动分析

后台活动分析可以用来分析再Web应用程序数据库层上的用户活动情况和性能瓶颈。使用这些信息有助于获得精确的性能测试结果。

17.1 分析Web应用程序的用户活动

用户在Web应用程序中的详细活动信息是记录在数据库中的。我们可以根据自己的业务需求到数据库中去查询用户活动的处理情况。比如：有多少订单被处理、有多少登陆行为发生，以及用户进行了多少次搜索。通过这些简单的查询就可以将这些信息从数据库里提取出来，这些信息将用来帮助制定用户场景（user scenarios）、用户场景比率或其他营销方面的情报。

17.2 分析Web应用程序的后台性能瓶颈

对于现有系统的Web应用程序进行性能测试，可以检查数据库服务器，找出那些花费长时间运行、引起死锁或占用了大量系统资源的SQL语句，从而判断出当前性能的瓶颈在哪里。

方法为使用包括SQL分析器工具跟踪SQL语句的执行情况以及对Web应用程序中的Windows和SQL Server等对象进行监视产生性能监视日志。由SQL语句造成对性能的影响，主要的原因包括：阻塞、索、死锁、有问题的查询以及需要花费大量时间执行的存储过程等。

18 关键性能尺度标准

性能测试的关键尺度包括以下几点：

l 服务器错误的可接受性 压力测试过程中经常会发生服务器错误，在压力测试刚刚开始或正在结束时，错误往往会产生，这是因为发生了大量的突发负荷和未完成的页面请求。

这些错误时由于压力测试而造成的，不大可能在生产环境中发生，因此可以忽略这些错误。

l 服务器利用的可接受性 确定服务器所能承受的最大负荷程度。制定出度量标准，并将这些度量标准形成文档，发布给开发组，支持组，管理组的人员，以后可以根据这个度量标准监视生产环境中的Web服务器，看哪些需求超过了Web服务器的性能要求，然后就可以想办法提高Web应用程序的性能来处理更高的流量。

l 内存泄漏和其他稳定性问题 这种问题往往出现在长时间高负荷的运行情况下。

19 镜像生产环境

性能测试的环境应该尽可能地接近实际生产中的环境，包括服务器的性能和配置、网络环境、系统的负载均衡方案和后台数据库等。通过镜像生产环境，可以确保测试结果的准确性。

注：即使无法模拟出生产环境的硬件情况，依然可以发现许多存在于代码和系统架构中的瓶颈。虽然理想状态下测试环境应尽可能地接近生产环境，实际上在能搭建地任何测试环境中测试都是有意义的。

20 用户思考时间的问题

创建测试脚本的时候，可以选择使用用户思考时间，主要考虑到用户在访问系统过程中的思考时间，因此能帮助我们更好地模拟实际情况下的应用程序使用情况，但在对新框架的测试中，因为只需验证框架的稳定性和框架所能承受的并发用户数及页面响应时间就不需考虑用户的业务使用情况。另外，使用用户思考时间会降低客户端能够产生的最大负载量，会影响到对最大负荷下系统的性能表现的计算结果。而且，如果客户端发送请求的能力本身就存在不足的话，将更加难以发现性能瓶颈，因为瓶颈往往是在系统承担最大负载时表现出来的。

21 确定负载增加的标准

确定压力测试需要进行的程度，首先需要指定一个标准，确定何时达到适当的压力级别。我在这里举一些可能的测试标准的例子：

l 当一定数量的错误出现在事件或Web服务器的日志中时，停止继续增加负载。

l 不断增加负载，直到吞吐量开始下降。

l 给CPU利用率设置一个极限值（框架中考虑80％～90％）

l 给内存的利用率设置一个极限值。

l 给页面响应时间设置一个极限值

l 根据业务需要事先确定Web应用程序能够处理的每秒请求数或同时连接数

22 性能参数介绍

22.1 处理器性能参数

l ％Processor Time 指处理器执行非空闲线程时间的百分比。这个计数器是处理器活动的主要指示器。它通过在每个采样间隔中计算处理器用于执行空闲处理进程的时间，并且用采样持续时间减去该值得出。（每台处理器有一个闲置线程，该线程在没有其他线程可以运行时消耗周期）可将其视为采样间隔期间用于做有用工作的百分比。这个计数器显示在采样间隔期间所看到的忙时平均值，这个值是用100％减去该服务不活动的时间计算出来的。

l ％Privileged Time 指处理器执行授权模式下的线程所耗时间的百分比。调用Windows系统服务时，该服务将经常运行在授权模式下，以便访问系统私有数据。这些数据受到保护，运行在用户模式下的线程无法访问它们。可以显式或隐式调用系统服务，比如页面错误或中断。与早期的操作系统不同，Windows除了使用授权模式和用户模式外，还使用进程分界线来保护子系统。应用程序可能需要Windows操作系统去代表它们执行某项工作，这些工作除了会出现在进程的授权时间内，还可以出现在其他子系统的进程中。

l ％User Time 处理器执行用户模式进程下的线程或其他非操作系统进程线程所耗时间的百分比。应正确区分System和Processor对象的％User Time和％Privileged Time。它们衡量的都是非空闲时间，而它们的和就是总的非空闲时间。

22.2 处理器瓶颈的解决办法

1、往系统中增加更快或更多的处理器，这个方法的缺点是在成本方面它不是最经济的。

2、分析软件以找出产生瓶颈的进程和部分。

22.3 内存性能参数

l Page faults/sec 每秒钟错误页面的平均数目。之所以用每秒错误页面的数目来衡量，是因为在每个错误操作中只有一个页面出错，因此它也等同于页面错误操作数。这个计数器包括硬错误（那些需要磁盘访问的）和软错误（在物理内存的其他地方找到的错误页面）。许多处理器可以在大量软错误的情况下继续工作。但是，硬错误（需要访问磁盘）将导致明显的延迟。

l Available Bytes 是当前计算机上可用于运行进程有效物理内存的字节数量。Pages/sec是指由于硬错误而从磁盘读取的页数，或由于页面错误而为了给工作集挪出空间而向磁盘写入的页数。