如何测试服务器的稳定性？

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

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

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

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

　　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资源监控命令等。并在场景运行过程中辅以手工测试。

1 可以用专用工具测试，例如：

Netperf（wwwnetperforg）：网络性能测试。主要针对基于TCP或

UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试，即批量数据传输（bulk data

transfer）模式和请求/应答（request/reponse）模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统

发送数据，以及另外一个系统能够以多块的速度接收数据。Netperf工具以client/server方式工作。

server端是netserver，用来侦听来自client端的连接，client端是 netperf，用来向server发起网络测试。

2 自己写代码测试，参考：

http://kmplayeriteyecom/blog/673226。

首先解释游戏性能测试含义：

性能（performance）：是系统实现其功能的能力。例如，响应时间、吞吐能力、事务处理数；

性能测试：是指在特定负载情况下，确定系统的响应速度和稳定性的表现。它也可以研究、测量、验证系统的其他特征，比如可扩展性、可靠性和资源使用率。通俗的讲：通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求，即在特定的运行条件下验证系统的能力状况。

按手游构成特点，将性能测试分为客户端性能、服务器性能两大块。

客户端性能的关键指标有：CPU占用率、内存占用率、流量耗用量、FPS（每秒传输帧数） 

服务器端性能的关键指标有：响应时间、并发用户数、吞吐量等；

明确测试目标；

了解性能测试需求；

编写性能测试计划；

分析性能测试需求；

编写性能测试方案、设计测试场景；

相关资源准备(人力资源、硬件资源、软件资源)；

测试程序开发；脚本维护、测试数据准备、测试监控准备；

执行性能测试并收集测试结果；

分析结果；

系统调优及再测试；性能测试五大误区

简单推荐2款工具，分别给玩家和开发者。

1    玩家：安兔兔等跑分软件

可以快速将app性能跑出一个整体分。但有个致命问题，无法单独查看单独某个功能、某个时间点的具体数值。缺点是无法定位问题。

2    开发者：WeTest性能测试（腾讯WeTest官方出品）

提供Android版本和云端版本2种性能测试方案，这里着重介绍下本地版本，使用3步即可：

1)     打开WeTest性能测试页面下载WeTest App，并安装；

2)     运行手机上的WeTest App，选择游戏后点“开始测试”；

3)     上传并查看报告

结束测试后，打开WeTest App点击“上传”按钮。

登录wetestqqcom点击“我的主页”里面，左侧的“手游测试报告”，在页面中就会出现“性能测试”结果报告，，就可以查看完整的测试报告；

使用LR对数据库进行性能测试，实际上有多种办法，包括通过现有的数据库协议进行CS模式的先录制后执行的模式，以及通过socket方式向服务器发包方式的测试方式。这些是常规书籍上介绍的比较简单上手的测试方法，但是不具备通用性，受已有协议或socket编程方式的限制，所以需要更为通用的测试方法。

用Java user的协议进行所有数据库性能的测试工作：

Java user 不需要录制，把所有的操作通过java语言进行实现，通过lr调用java的class进行加压批量操作，这样可以不关心被测系统是哪个数据库，只要能够通过jdbc进行访问，就能实现性能测试。

一、测试环境准备

1 被测服务器准备，根据测试目的，搭建需要的数据库服务器，确保数据库能够正常访问，正常操作；

2 Java代码的准备，无论使用哪种IDE，只要能够编写访问数据库的class就可以，形式可以是j2se，也可以是j2ee，因为在操作时只使用class的部分方法，所以j2ee就可以了；

3 LR的脚本调试，把java的class导入到脚本调试模式，根据需要添加事务以及其他操作。

二、编写数据库访问

1 使用myeclipse，创建web project，创建如下图的包目录：

Java文件中包含各种访问数据库的方法。

需要注意的是，class中的方法必须是public static，否则LR中无法调用。由于创建的是j2ee程序，所以不用main函数，在web中就可以进行功能验证。

确认class中的方法编写完成，创建一个webjsp文件，如下：

导入class

声明类，并实例化，直接调用刚才编写的3个方法，因为这3个方法是直接对数据库进行操作，不需要实参，也没有返回值，所以直接实现即可。

此时启动web服务，在浏览器中输入jsp的地址，直接刷新页面，就可以调用这3个方法，如果正确，就会对相应的表进行操作，如果不正确，则需要修改相应的代码。

2 LR脚本准备：

LR脚本实际上就是对访问代码的调用，关键在于需要根据测试场景划分不同的脚本布局。

例如：在myEclipse里，我们只编写了一个class，其中包含三个方法，如果在执行性能测试时，这三个方法相互独立，互不干涉，则最简单的划分方法是，创建三个java user，每个java user中包含一个方法，做三份脚本，场景执行时分别进行调用。如果三个方法之间有相互关系，则需要根据实际情况，把有关联的方法放在一起，具体情况可按实际灵活分配。

因为已经将class文件进行编译发布了，所以可以在“java2postgres\WebRoot\WEB-INF\classes\com\lr\test”目录中找到对应的class文件，

复制这个文件，找到LR的目录：HP\LoadRunner\classes\com\lr\test\ 如果没有文件夹，按相同的内容创建。

在LR脚本中进行引包操作：

将需要执行的java类以及方法，放在action中，可根据实际测试情况和所需要验证的内容，具体调试代码。

在这里可以像编写普通LR脚本一样，添加事务或集合点等内容。

由于是通过JDBC对数据库进行访问，因此要在java user中加载jdbc驱动。

运行时设置中，增加jdbc驱动，需要注意的是java user使用的本地jdk，需要至多16版本，若使用17版本，回放会有错误，这是jdk版本的问题。

操作完成之后，按F5或点击运行，进行脚本回放，实际此时也对数据库进行了操作，可以直接查询对应的表，检查功能是否正确。

三、执行性能测试

已经有了java user的脚本，和普通web性能测试一样，设计场景、执行测试、收集报告、分析性能瓶颈即可。

网络性能主要有主动测试，被动式测试以及主动被动相结合测试三种方法

1主动测量是在选定的测量点上利用测量工具有目的地主动产生测量流量注入网络，并根据测量数据流的传送情况来分析网络的性能。

主动测量在性能参数的测量中应用十分广泛，因为它可以以任何希望的数据类型在所选定的网络端点间进行端到端性能参数的测量。最为常见的主动测量工具就是“Ping”，它可以测量双向时延，IP 包丢失率以及提供其它一些信息，如主机的可达性等。主动测量可以测量端到端的IP 网络可用性、延迟和吞吐量等。因为一次主动测量只是查验了瞬时的网络质量，因此有必要重复多次，用统计的方法获得更准确的数据。

要对一个网络进行主动测量，则需要一个面向网络的测量系统，这种主动测量系统应包括以下几个部分：

- 测量节点：它们分布在网络的不同端点上，进行测量数据包的发送和接收，若要进行单向性能的测量，则它们之间应进行严格的时钟同步；

- 中心服务器：它与各个测量节点通信，进行整个测量的控制以及测量节点的配置工作；

- 中心数据库：存储各个节点所收集的测量数据；

- 分析服务器：对中心数据库中的数据进行分析，得到网络整体的或具体节点间的性能状况

在实际中，中心服务器，中心数据库和分析服务器可能位于同一台主机中。

主动测量法依赖于向网络注入测量包，利用这些包测量网络的性能，因此这种方法肯定会产生额外的流量。另一方面，测量中所使用的流量大小以及其他参数都是可调的。主动测量法能够明确地控制测量中所产生的流量的特征，如流量的大小、抽样方法、发包频率、测量包大小和类型(以仿真各种应用)等，并且实际上利用很小的流量就可以获得很有意义的测量结果。主动测量意味着测量可以按测量者的意图进行，容易进行场景的仿真，检验网络是否满足QoS 或SLA 非常简单明了。

总之，主动测量的优点在于可以主动发送测量数据，对测量过程的可控制性比较高，比较灵活机动，并易于对端到端的性能进行直观的统计；其缺点是注入测量流量本身就改变了网络的运行情况，即改变了被测对象本身，使得测量的结果与实际情况存在一定的偏差，而且注入网络的测量流量还可能会增加网络的负担。

2被动测量是指在链路或设备（如路由器，交换机等）上对网络进行监测，而不需要产生流量的测量方法。

被动测量利用测量设备监视经过它的流量。这些设备可以是专用的，如Sniffer，也可以是嵌入在其它设备(如路由器、防火墙、交换机和主机)之中的，如RMON, SNMP 和netflow 使能设备等。控制者周期性地轮询被动监测设备并采集信息(在SNMP 方式时，从MIB 中采集)，以判断网络性能和状态。被动测量主要有三种方式：

- 通过SNMP 协议采集网络上的数据信息，并提交至服务器进行处理。

- 在一条指定的链路上进行数据监测，此时数据的采集和分析是两个独立的处理过程。这种方法的问题是OC48（25Gbit/s）以上的链路速度超过了 PCI 总线（64bit，33MHz）的能力，因此对这些高速链路的数据采集只能采用数据压缩，聚合等方式，这样会损失一定的准确性。

- 在一台主机上有选择性的进行数据的采集和分析。这种工具只是用来采集分析网络上数据包的内容特性，并不能进行性能参数的测量，如Ethereal 等工具。

被动测量非常适合用来测量和统计链路或设备上的流量，但它并不是一个真正的 QoS 参数，因为流量只是当前网络（设备）上负载情况的一个反映，通过它并不能得到网络实际的性能情况，如果要通过被动测量的方法得到终端用户所关心的时延，丢包，时延抖动等性能参数，只能采用在被测路径的两个端点上同时进行被动测量，并进行数据分析，但这种分析将是十分复杂的，并且由于网络上数据流量特征的不确定性，这种分析在一定程度上也是不够准确的。只有链路带宽这个流量参数可以通过被动测量估算出来。

被动测量法在测量时并不增加网络上的流量，测量的是网络上的实际业务流量，理论上说不会增加网络的负担。但是被动测量设备需要用轮询的方法采集数据、陷阱(trap)和告警（利用SNMP 时），所有这些都会产生网络流量，因此实际测量中产生的流量开销可能并不小。

另外，在做流分析或试图对所有包捕捉信息时，所采集的数据可能会非常大。被动测量的方法在网络排错时特别有价值，但在仿真网络故障或隔离确切的故障位置时其作用会受到限制。

总之，被动测量的优点在于理论上它不产生流量，不会增加网络的负担；其缺点在于被动测量基本上是基于对单个设备的监测，很难对网络端到端的性能进行分析，并且可能实时采集的数据量过大，且存在用户数据泄漏等安全性问题。

3主动、被动相结合测试

主动测量与被动测量各有其有缺点，而且对于不同的参数来说，主动测量和被动测量也都有其各自的用途。对端到端的时延，丢包，时延变化等参数比较适于进行主动测量；而对于路径吞吐量等流量参数来说，被动测量则更适用。因此，对网络性能进行全面的测量需要主动测量与被动测量相结合，并对两种测量结果进行对比和分析，以获得更为全面科学的结论。

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

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

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

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

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

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

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

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

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

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

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