对于应用服务器与数据库服务器的测试，关注的性能指标分别是什么呢

最重要的性能指标就应该是SPEC web99。SPEC web99为Web用户提供了用于评测系统用作Web服务器能力的最客观、最具代表性的基准; 而如果是选购应用服务器，关注SPEC jbb200和SAP SD这两个指标就能知道大概其了，因为SPEC jbb200是专门用来评估服务器系统运行Java应用程序能力的基准测试，而SAP SD 的测试结果为客户提供了基本的规模建议。

        常用网络性能指标包括：并发数、响应时间、吞吐量、PV和UV。

        并发数:系统能够同时处理的请求数量，反应系统的负载能力。一般为请求无等待的最佳并发数。最佳并发数，当系统的负载等于最佳并发数时，系统的整体效率最高，没有资源被浪费，请求也不需要等待。最大并发数，系统的负载一直持续，有些请求在处理而有的请求在自己最大的等待时间内等待的时候。最佳并发数需要大于系统的平均负载，最大并发用户数需要大于系统需要承受的峰值负载。

        响应时间:从发出请求到收到响应数据所花费的总体时间，反应系统的快慢，包括网络响应时间和应用程序响应时间两部分。

        吞吐量(Throughput)：单位时间内系统能处理的请求数量，体现系统处理请求的能力，常用量化指标包括QPS（每秒查询数）、TPS（每秒事务数）、HPS（每秒HTTP请求数）：

        （1）QPS：Queries Per Second,每秒查询率。是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

        （2）TPS：Transactions Per Second，每秒处理事务数。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。包括用户请求服务器、服务器内部处理、服务器返回给用户。TPS与QPS类似，差异可以理解为：对于页面的一次访问，形成一个TPS，但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，均计入QPS中，例如：一个页面访问请求服务器3次，则计算1个TPS，3个QPS。

        （3）HPS：Hits Per Second，每秒点击次数，是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和。它一般和TPS成正比关系，是B/S系统中非常重要的性能指标之一。

        页面浏览量(PV)：Page View，即页面浏览量或点击量，用户每次刷新即被计算一次。

        网站独立访客(UV)：Unique Visitor，访问网站的一个电脑客户端为一个访客，00:00-24:00内相同的客户端只被计算一次。

        常用经验公式：

     （1）一般情况下， 及格的 tps = 并发数 / 03，也就是响应时间低于300ms。

     （2）QPS（TPS），并发数、响应时间三者之间的关系是：

        QPS（TPS）= 并发数 / 平均响应时间

      （3）单台服务器每天PV估算公式：

            每天总PV = QPS 3600 6（或8）

      （4）服务器数量估算公式：

        机器数量=峰值时间每秒QPS / 单台机器的QPS

参考

（1）网站的性能指标 https://blogcsdnnet/lrh329678260/article/details/85247019

（2）性能测试指标 https://wwwcnblogscom/evablogs/p/7922042html

不管是虚拟主机还是服务器，我们都知道，它的稳定性很重要，访问速度也有着决定性的作用。一般来说，如果访问速度不好的话，会让网站加载非常慢。壹基比小喻企鹅头像给大家介绍一下租用服务器前怎样检测访问速度。

第一种方法：常见的ping命令。

这个命令与IT打交道的站长并不陌生，一般来说，网站速度不好，或者测试一下是网站问题还是服务器问题，都会使用这个命令进行测试。那么具体怎样检测租用服务器的网络是否通畅无延迟呢？

在电脑中点击开始，运行，然后输入CMD打开DOS命令窗口。然后输入网站网址，或者服务器的IP地址，格式为ping 域名，或者ping IP。使用ping命令后，会反馈一个结果，这个结果基本包括了以下几个信息。

Time，这个是响应时间，时间越小越好，国内服务器响应时间一般在30-80ms之间。

TTL，这个可以判断相关的操作系统，TTL=119，则表示是XP系统，不过这个现在一般不准，毕竟服务器可以修改注册表TTL类型。

数据包发送信息，这个里面有个丢包率，数值越小越好，正常都是显示丢失0。

第二种方法：tracert命令。

测试方法与ping命令类似，只是将ping 换成tracert，不过这个命令可以用来检测终端用户到服务器机房的跳数及响应时间，换句话说，就是可以测试出服务器与全国客户的连接速度。显示时间也是以Ms为单位，时间越短越好。

第三种方法：比网站加载速度。

可以利用WhichLoadsFasterFastSoft工具测试一下打开网站速度。基本工作原理是通过连接，在浏览器中让两个真实的网页显示出来，反应的结果就是两个网站真实打开速度对比。

第四种方法：网站速度测试工具。

使用GTmetrixgtmetrix有丰富的测量结果，能够提供相关的网站速度提升建议，站长可以根据这些建议优化站点。然后再逐一找到加载速度变慢的原因。

我们知道，一个网站如果在好几秒都打不开，那么基本上都会没有耐心，会关闭页面，而这无形当中就是流失了用户。以上就是租用服务器前对速度的测试方法，希望对站长有一定的帮助。

服务器稳定性是最重要的，如果在稳定性方面不能够保证业务运行的需要，在高的性能也是无用的。

　　正规的服务器厂商都会对产品惊醒不同温度和湿度下的运行稳定性测试。重点要考虑的是冗余功能，如：数据冗余、网卡荣誉、电源冗余、风扇冗余等。

　　一些测试方法主要分以下几种：

　　压力测试：已知系统高峰期使用人数，验证各事务在最大并发数(通过高峰期人数换算)下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应(如：宕机、应用异常中止等)。

　　Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5%-7%作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。

　　Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。

　　另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称(如：lr_rendzvous("same");)在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。

　　稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。

　　根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器(加压机、应用服务器、数据服务器三方性能)，估算最终并发用户人数。

　　场景设计思想：

　　从稳定性测试场景的设计意义，应分多种情况考虑：

　　针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：

　　1)场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。

　　2)场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。

　　测试方法：采用1)Ramp Up-Load all Vusers simultaneously

　　2)Duration-Run Indefinitely

　　3)在Sechedule-勾选Initalize all Vusers before Run

　　容错性测试：通过模拟一些非正常情况(如：服务器突然断电、网络时断时续、服务器硬盘空间不足等)，验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA(自动容灾系统)，还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。

　　问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。

　　测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标(如：事务响应时间、最大并发用户数等)。

　　评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。

　　评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义(如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等)。

　　评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环境下系统所能承受的最大并发用户数。判定标准阀值预先定义(如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等)。取值标准以木桶法则为准(并发数最小的事务为整个系统的并发数)。

　　评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。

　　问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。

　　该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。

提到服务器性能测试，不得不提到很多术语。为了让大家更容易理解，举个生活中的例子：

你中午去“海底捞”吃饭。

我们可以把“海底捞”这个酒楼看成一个被测系统。

你去吃饭，就是对这个被测系统发起请求，对这个系统造成了一定的负载。你带去的人越多，那么这个餐馆就越繁忙，可以说餐馆承受的负载就越大。

你开始点菜。这个时候你隔壁桌的人也开始点菜。那么你们两个对这个系统产生了并发的请求。同时，其他桌有的在吃菜，有的在等菜，这些都是并发进行的事务。一个完整的吃饭事务可以定义成包括：点菜，下单，上菜，买单四个步骤。对于一个C/S的系统来说，可以对应于：建立连接，发送请求，接受应答，断开连接。

影响一个餐馆生意好坏的一个重要原因是上菜速度。上菜速度体现在两个方面：

很多因素会影响上菜速度，比如服务员的个数、厨师的个数。对于一个C/S的系统，服务员相当于是接入层，厨师相当于是后台服务。假如服务员太少，下单很慢，后面的厨师都闲着，那么上菜速度也快不了；假如服务员够多，下单足够快，但是厨师太少，下的单来不及做，同样上菜速度也很慢；如果服务员很多，厨师也很多，但是来的客人很少，那么大部分的服务员和厨师都闲着，资源全部浪费掉了。因此，接入层和后台服务进程个数、以及资源配比，都是需要根据实际情况进行调优的。

来多少顾客，这是酒楼自己无法控制的，但是酒楼的上菜速度、餐位多少都会制约客流量。一定有一个峰值客流量，当来的客人超过了这个峰值，那么这些客人就会等位，或者是上菜速度超慢让客人无法容忍。容量测试就是通过工具模拟足够多的顾客来吃饭的事务，希望找到这样一个客流量对酒楼产生一定的负载，这个时候酒楼既能接待最多的客户同时也能保证最短的等待时间。更多的，还可以对这个酒楼人员配置和餐位设置等进行调优，以期达到一个最理想的资源利用率和效率。

客流量跟进来的客人多少有关，也跟餐馆的接待能力有关。单方面增加来就餐的顾客，遭到投诉的可能性就越大，上错菜的可能性也越大。

1一个顾客请求的处理耗时，从下单到上菜中间等待的时间，我们称之为响应时间。

2这个餐馆同时为多名顾客上菜的频率，我们称之为吞吐量。

服务器测试方法

服务器测试方法分为两个大方面，性能测试与功能测试。

我们在性能测试方面采用了新的测试方法，主要分为文件测试、数据库性能测试与

Web

性能测试三个

方面。其中，文件性能与数据库性能采用美国

Quest

软件公司的

Benchmark Factory

负载测试和容量规划

软件，

Web

性能测试则使用了

Spirent

公司提供的

Caw WebAvalanche

测试仪。

一、性能测试

1

、文件性能测试方法

Benchmark Factory

软件能按照文件读写的关键指标定制事务。软件最大支持

1000

个虚拟客户。

本次测试环境包括

10

台配置为

PIII800/128MB

内存

/20G

硬盘以上的客户端，它们用来模拟虚拟用户。

控制台为配置是

PIII 850/128MB

内存

/40G

硬盘的

Acer

笔记本电脑。交换机为带有两个千兆

GBIC

接口、

24

个

10/100M

自适应端口的

Cisco 2950

，客户端与控制台通过

100M

网卡连到交换机上，被测服务器则通

过千兆光纤网卡与交换机相连接。

被测服务器均安装带

SP4

的

Windows

2000

Advanced Server

操作系统，在所有三项性能测试中都统一

RAID

级别为

5

。

在具体测试方案设置上，测试软件把决定文件读写操作的关键因素设定为：读

/

写、随机

/

顺序、操作

块大小、对象大小四个。在本次测试中，考虑到我们设有单独的数据库及

Web

测试项目，所以在文件测试

中，我们把目标确定为测试服务器基本的

I/O

性能，这主要由网络接口、系统带宽、磁盘子系统等几大部

分所决定。同时，从几部分的作用看，以大操作块读写大对象文件，小操作块读写小对象文件，较能反映

服务器最基本的

I/O

性能，即“大操作块读写大文件”对系统带宽、缓存的考察，以及“小操作块读写小

文件”对磁盘子系统、网络接口的考察。最终我们确定的四个事务是：

大文件顺序读写

(

操作块

8KB

，对象文件

80% 500KB

、

20% 1MB)

大文件随机读写

(

操作块

8KB

，对象文件

80% 500KB

、

20% 1MB)

小文件随机读

(

操作块

1KB

，对象文件

80% 1KB

、

10% 10KB

、

10% 50KB)

小文件顺序写

(

操作块

1KB

，对象文件

80% 1KB

、

10% 10KB

、

10% 50KB)

每个事务的用户数均以固定步长逐渐增加，

最大可增加到

1000

个虚拟用户。

其中，

“大文件顺序读写”

事务的用户数按照

40

的步长从

1

可增加到

400

个

(

测试至强服务器

)

或

200

个

(

测试

TUALATIN

服务器

)

，其

他事务则将用户数按照

100

的步长从

1

增加至

1000

。我们期望得到其在不同用户数时被测服务器的性能表

现。总体上其走势及峰值反映了该服务器的性能。每项事务均运行三次，每次之间被测服务器进行重启，

最终结果为三次平均值。

2

、数据库性能测试方法

“乘机安全小贴士”安全出行要重视

数据库性能测试同样使用了

Benchmark Factory

软件，测试环境如同文件性能测试。测试时，在被测

服务器上安装

SQL Server 2000

使用企业版。首先在被测服务器上创建新的数据库，通过使用

Benchmark

Factory

预定义的

Database Spec

项目向数据库中创建表，装载数据。在服务器端创建以

CPU

计算为主的

存储过程，通过

10

台客户机模拟用户、按照

40

个虚拟用户的步长递增到

400

个用户，执行该存储过程。

结果是以获得的每秒事务数

(TPS)

衡量服务器的数据库事务处理能力。

整个测试分为三次，

每次之间重新启

动被测服务器，最终取三次平均值作为评价结果。

3

、

Web

性能测试方法

Web

性能测试工具是由

Spirent

公司提供的

Caw WebAvalanche

。

WebAvalanche

模拟实际的用户发出

HTTP

请求，

并根据回应给出具体的详细测试结果。

它有以下特点：

能够模拟成百上千的客户端对服务器发

出请求

;

能够模拟真实的网络应用情况，

比如网站在高峰期的访问量应该是动态的维持，

有新客户端的加入，

同时也有原客户的离去，

访问量不是固定不变的

;

可以产生

20000

个连接

/

秒请求量，

足以满足测试的需要

;

测试项目丰富，有访问请求的成功失败数，有

URL

和页面的响应时间，有网络流量数，还有

HTTP

和

TCP

协

议的具体情况。

测试时，被测服务器与

WebAvalanche

上都装有千兆光纤网卡，两网卡通过光纤直接连接。监控端

(

配

置为

PIII 1GHz/128M

内存

/20G

硬盘

)

安装了带

SP4

的

Windows 2000 Server,

该监控端与

WebAvalanche

通

过交叉线直连。在监控端通过

Web

浏览器配置

WebAvalanche

，在被测服务器安装了

SQL Server 2000

企业

版，并用微软的

IIS

建立了

Web

服务器。

测试分为静态性能与动态性能两部分。主要是因为在实际的

Web

应用中，有的站点静态内容居多，提

供的服务也绝大多数是静态的，

因此，

他们就会特别的关心服务器静态性能

;

同样，

有的站点提供的服务交

互性的内容居多，他们就会更关心服务器的动态性能。

被测网站中页面大小及静态、动态页面所占比例均参照实际网站得出，整个网站静态、动态页面所占

比例是

70%

和

30%

，使用的动态页面类型为

ASP

。请求页面样本的文件大小分布比例与整个网站的相同。

静态性能测试模拟发出的均是静态页面请求。在测试动态性能时，动态页面的访问请求占

20%

，其余

80%

为静态页面请求。我们根据实际的

Web

服务器一天中的运行情况建立了一个服务器页面请求模型，该

模型由

4

个阶段组成，第一阶段是预热阶段，

WebAvalanche

发出的请求量由

0

慢慢上升到

200;

第二阶段

是逐步加压阶段，请求量逐步累加到最大值

8200;

第三阶段是动态维持阶段

;

第四阶段是下降阶段，请求量

由最大值迅速下降为

0

。其中，最大请求量略大于实际服务器能够提供的事务处理量。

被测服务器的静态与动态测试分别测试三遍，每遍之间被测服务器和测试仪均重启，结果取三次的平

均值。由此可见，此服务器测试方法立志于最终结果的准确性。

二、功能测试

在功能测试方面，我们对被测服务器的可扩展性、可用性以及可管理性进行了综合评价，其中可扩展

性包括硬盘、

PCI

槽以及内存等的扩展能力，可用性包括对热插拔、冗余设备

(

如硬盘、电源、风扇、网卡

等

)

的支持，可管理性则指的是服务器随机所带的管理软件。

我们在对服务器进行总体评价时，综合了性能、功能和价格三方面因素，依据《网络世界》所做的用

户调查结果，分别给予不同权重，性能占

50%

，功能占

40%

，而价格则占

10%

。在分析性能时，数据库性能

占其中的

50%

，而文件性能占

30%

，

Web

性能占

20%

。

综上所述，这种全新的服务器测试方法更够更准确更直接的对服务器进行测试，而且数据更加精确。

希望能给又需要的读者朋友带来一定的帮助

。

谢谢采纳。

目录结构

通过前文 性能测试需求分析 对性能测试的必要性评估之后，敏捷开发团队确定利用开源工具JMeter实施性能测试工作。根据被测对象的应用特性，首先需要获取 具体的性能测试需求 。

对于相对规范的产品，产品团队一般会给出相对明确量化的性能测试要求，如下表所示：

可以看出，上表给出的性能指标比较明确。性能测试活动实施过程中，测试工程师只需收集随机购买商品的 [ 响应时间、访问成功率、并发数、CPU使用率、内存使用率 ] 等相关指标的监测数据，与表中的量化指标比对即可。满足相关指标，则测试通过；若未满足，则需要进行问题分析定位，最终进行调优与回归，直至达到性能测试需求。

以本次项目为例，产品团队并未指明性能测试需求，那么测试工程师如何分析提取量化的性能指标呢？

从用户应用角度考虑，若被测对象 常用的业务 的性能存在瓶颈，则很可能引起客户的反感。以登录功能为例，输入用户名和密码，点击登录按钮到显示成功登录信息，若耗时1min，用户绝对无法忍受。用户 不常用的功能 ，如年度报表汇总功能，一个季度甚至是一年才使用一次，等几分钟or更长时间也有可能被接受。

So，不同的应用频率，决定了用户的使用感受，也决定了测试的需求。

针对本次ECShop电商系统而言，商城用户经常使用的功能，且存在大量用户使用的业务有：用户注册、登录、随机浏览商品、购买业务等，而其他功能则相对用户较少。若电商系统已经正式运营，则可从系统 运营日志 中分析具体的数据。若尚未上线运营，则需要 调研用户 or根据 自身经验 进行分析获取。

根据 [JPT_01]性能测试需求分析 中的描述，分析哪些是用户常用or交易占比超过80%的业务；从运营及项目组角度分析，哪些业务相对重要，然后确定为 业务测试点 。

综合分析，本次项目实践以 用户登录、随机浏览并购买商品 为测试点。确定业务测试点后，即可进行详细的业务需求分析，从而明确性能测试指标。

不同的被测对象，不同的业务需求，可能有不同的指标需求，但大多数测试需求中都包含以下几种性能指标：

目前，大多数软件系统客户端与服务器交互的过程，如下：

因此，不同的视角，衡量的响应时间指标也各不相同。实际测试过程中，需明确以什么视角验证被测对象的性能。

大多数情况下，性能测试响应时间主要以客户端发出请求，直至接收到服务端的响应数据过程中所消耗的时间作为参考。

严格来讲： 响应时间=呈现时间+网络传输时间+服务器端响应时间+应用延时时间

Tips：

不建议尝试在公网进行性能测试，原因如下：

① 可能影响现网用户 。实施性能测试过程中，可能产生大量压力与垃圾数据，从而破坏生产环境，导致缺陷的产生，影响实际的业务。

② 压力模拟可能无法体现真实场景 。实施性能测试时，利用压测工具模拟大并发数，会产生大量业务数据。因负载生成器与服务器所在的网络不同，or服务器特定的网络安全设置，导致压力数据无法达到被测服务器，整个网络环境不可控，从而导致测试失败。

有一种情况除外，模拟固定带宽网络访问的场景，可在局域网中使用限制带宽的手段进行测试。

总之，需要遵循一个原则： 在测试过程中，任何资源都必须可控。

衡量方式：

其中，[字节数 / 单位时间] 的计算方式，与当前的网络带宽比较，可找出网络方面的问题。

吞吐量计算：例如1分钟内系统可以处理1000次转账交易，则吞吐量为1000/60=167 (次/秒)

一个系统的高效运行，除了软件性能要求外，还需要对硬件资源进行监控。若用户需求、项目组or其他利益相关方均未提出性能指标要求，则可参考行业经验，CPU使用率≤80%、内存使用率≤80%、网络带宽占用≤50%

PS：

80%只是作为一个经验参考值，最终的性能测试指标需要经过项目相关各方评审才能确定

通过上述业务数据分析，最终得到本次项目测试的性能需求指标，如下：

例如，测试银行营业系统的并发处理性能，有100个网点，上午10:00-11:00的一个小时高峰期里，要求能支持50000笔开户业务，其中成功率不低于98%，也就是需要成功开户49000笔，其他的1000笔可能是超时，或者其他错误导致未能开户成功。

根据上述各指标，结合被测对象本身的业务情况，进行测试需求及指标分析：

通过对预设业务目标的分析，可得出以下数据：

计算业务量的分解数据：

综上，需要测试ECShop电商平台在2h内支持5w用户登录、随机浏览商品进行购买的业务。