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

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

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

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

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

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

服务器监控软件和工具可以帮助我们从任何一个地方实时了解服务器的性能和功能。由于复杂的社交网络系统以及我们对于互联网的高度依赖，我们绝不允许那些宝贵的客户因自身系统停运而流失。选用实用的服务器工具和软件是一个明智的决定，能够同时为你带来短期效益和长期效益。下面是10款超实用的服务器监控工具和软件：

1 Simple Server Monitor

Simple Server Monitor是一款成本合理、功能强大、使用方便的服务器监控工具，它会不断监控服务器和Web应用程序的运行状况。

2 Pingdom

Pingdom服务可以监控互联网上多个地方的网站和服务器，确保它们运行正常。你可以使用Pingdom来监控你的公共网站和受密码保护的网站、FTP服务器、电子邮件服务器，以及可以通过互联网来访问的其他各种服务。

3 迈克菲SECURE技术

迈克菲技术可以帮助你应对网上风险。无论你向迈克菲求助是为了扫描安全漏洞、PCI认证还是验证信任标记，它都可以提供简单、有效、成本合理的安全解决方案。

4 interSeptor Pro

interSeptor Pro是一款高级的以太网数据中心和机架监控系统，它可以监控机房和机架的环境状况；而且一旦出现空调系统故障以及可能危及业务连续性的其他情况，就会发出预警警报。

5 AppFirst

AppFirst适用于用任何一门语言编写的每一个应用程序。有了AppFirst，你根本不需要自己的用户告诉你哪里又出了问题。你可以下载这款服务器监控软件的免费试用版。

6 PA Server Monitor

如果在IT部门工作，要处理好工作与生活的关系有些难度。但是PA Server Monitor可以帮助IT人员减轻压力，因为它可以不断监控服务器，同时又不妨碍你处理其他工作。

7 Uptime software

该软件具有虚拟服务器监控、物理服务器监控和云环境监控等功能。这一款服务器监控工具适用于多种平台。可以监控服务、监控应用程序、监控系统资源用量，又没有“企业级”监控工具的那种复杂性。

8 Nimsoft

可以通过监控获得所需的详细信息，以便优化贵企业中重要服务器的性能和可用性。面向服务器的Nimsoft监控解决方案（NMS）支持Windows、iSeries AS400、Netware、Linux和UNIX等操作系统——这一切均借助易于使用的控制台即可实现。NMS可以监控服务器的核心资源（处理器、内存、磁盘、事件日志和计数器等），能够集中管理远程进程和服务（如自动和手动的开始/重启/终止）。你可以下载这款服务器监控工具的免费试用版。

9 Neustar Webmetrics

Webmetrics监控服务让公司企业能够在客户受到影响之前，跟踪、查明、解决和防止Web性能问题。Webmetrics可以测试、监控和测量网站、Web应用程序、Web服务、网络服务和流媒体的性能，从而确保不间断的正常运行时间和性能完整性。

10 Dotcom-Monitor

Dotcom-Monitor是一项高级的网站监控服务，它把监控、报告、通知、上报和分析等功能结合起来，做成最适合贵公司需要的套件，以确保贵公司电子商务的性能和正常运行时间。

　　如果只有两个Guest OS,以规格来看，瓶颈应不会在CPU性能上，反而是硬盘I/O跟网络速度的性能比较有可能，而内存数量及使用规划也要注意。另外如果是无法长期停机的机器，需要评估备份或后备规划，以及后备系统版权授权规定及费用。

　　关键瓶颈是磁盘I/O,并非CPU。需要跟进的事情是﹕

　　1 在旧主机上面，先监测出跑报表所需要的IOPS有多少？并精算VM硬盘。

　　2 如果文档复制会占用主机所有的IOPS,这种工作不适合跟其他VM共享磁盘。

　　所以，如果要拆开，主因并不是CPU不够用（跑报表跟文档复制，根本用不到多少CPU资源），而是磁盘的I/O资源会被文档复制全部占用，造成其他的VM排队等候。

　　在虚拟化软件的选择上，如果是VMware ESX（i），可以透过vSphere Client或vCenter新增Resource pool,来设定Guest OS的CPU资源。

　　可以测试一下：报表跑数据大量择取的时候，使用“Windows工作管理员/处理程序”查看CPU与内存以及I/O的状态。

　　虽然将它们放在同一台主机，但是文档服务给它一个完全独立的磁盘子系统，不跟其他VM共用，那这样就不会有以上的顾虑，还是可以放在一起。

　　例如，你可以买一台SAN给文档服务的VM专用，但另买一台SAN给其他的VM共用，最后，数据库的问题还是要回到IOPS上来。我遇过80%以上想做虚拟化的新手，都不知道原本旧主机上数据库的瓶颈是在Disk I/O。一般说来，跑ERP报表吃掉1,000~3,000 IOPS是很常见的状况，这代表RAID至少要5到15颗以上来组合，才足够应付这样的IOPS。

　　根据以往的经验，在看到这个数据之前，用户都一直认为瓶颈是CPU,所以要换新主机来提升CPU,但看过监测数据之后才知道，其实瓶颈都在IOPS。

　　补充一下，一般状况下，一颗SATA硬盘的IOPS只有70到80左右，一颗15K SAS硬盘的IOPS,大约200到240左右。组成RAID多颗硬盘时，IOPS会跟着你的硬盘数量而增加，例如使用96颗硬盘组成RAID-5的一台Dell MD3200i,实测数据上，IOPS可以高达40,000。

　　21 测试环境

　　作者使用了Tomcat作为Web服务器进行测试，被测试的内容是一个jsp文件和一个servlet，jsp文件调用JavaBean、打印相关信息，servlet接受用户参数、调用javabean、输出相关信息。详细的内容请参考作者提供的JMeterwar的内容。

　　22 安装启动JMeter

　　大家可以到通过http://apachelinuxforumnet/dist/jakarta/jmeter/binaries/jakarta-jmeter-191zip下载JMeter的release版本，然后将下载的zip文件解压缩到C:/JMeter（后面的文章中将使用%JMeter%来引用这个目录）目录下。

　　现在，请使用%JMeter%/bin下面的jmeterbat批处理文件来启动JMeter的可视化界面，下面的工作都将在这个可视化界面界面上进行操作。下面的是JMeter的可视化界面的屏幕截图。

　　图一： JMeter打开时的屏幕截图

　　图一： JMeter打开时的屏幕截图

　　23 建立测试计划（Test Plan）

　　测试计划描述了执行测试过程中JMeter的执行过程和步骤，一个完整的测试计划包括一个或者多个线程组(Thread Groups)、逻辑控制（Logic Controller）、实例产生控制器（Sample Generating Controllers）、侦听器(Listener)、定时器（Timer）、比较（Assertions）、配置元素（Config Elements）。打开JMeter时，它已经建立一个默认的测试计划,一个JMeter应用的实例只能建立或者打开一个测试计划。

　　现在我们开始填充一个测试计划的内容，这个测试计划向一个jsp文件和一个servlet发出请求，我们需要JMeter模拟五个请求者（也就是五个线程），每个请求者连续请求两次，下面的章节介绍了详细的操作步骤。

　　24 增加负载信息设置

　　这一步，我们将向测试计划中增加相关负载设置,是Jmeter知道我们需要模拟五个请求者，每个请求者在测试过程中连续请求两次。详细步骤如下：

　　1 选中可视化界面中左边树的Test Plan节点，单击右键，选择Add'Thread Group，界面右边将会出现他的设置信息框。

　　2 Thread Group有三个和负载信息相关的参数：

　　Number of Threads： 设置发送请求的用户数目

　　Ramp-up period： 每个请求发生的总时间间隔，单位是秒。比如你的请求数目是5，而这个参数是10，那么每个请求之间的间隔就是10／5，也就是2秒

　　Loop Count： 请求发生的重复次数，如果选择后面的forever（默认），那么 请求将一直继续，如果不选择forever，而在输入框中输入数字，那么请求将重复 指定的次数，如果输入0，那么请求将执行一次。

　　根据我们演示例子的设计，我们应该将Number of Threads设置为5，Ramp-up period设置为0（也就是同时并发请求），不选中forever，在Loop Count后面的输入框中输入2，设置后的屏幕截图如下：

　　图二：设置好参数的Thread Group。

　　图二：设置好参数的Thread Group。

　　25 增加默认Http属性（可选）

　　实际的测试工作往往是针对同一个服务器上Web应用展开的,所以Jmeter提供了这样一种设置, 在默认Http属性设置需要被测试服务器的相关属性，以后的http请求设置中就可以忽略这些相同参数的设置,减少设置参数录入的时间。

　　我们这里将采用这种属性。你可以通过下面的步骤来设置默认http属性：

　　1 选中可视化界面中左边树的Test Plan节点，单击右键，选择Add'config element'http request defaults，界面右边将会出现他的设置信息框。

　　2 默认http属性的主要参数说明如下：

　　protocal：发送测试请求时使用的协议

　　server name or ip：被测试服务器的ip地址或者名字

　　path： 默认的起始位置。比如将path设置为／jmeter，那么所有的http请求的url中都将增加／jmeter路径。

　　port number： 服务器提供服务的端口号

　　我们的测试计划将针对本机的Web服务器上的Web应用进行测试，所以protocal应该是http，ip使用localhost，因为这个web应用发布的context路径是／jmeter，所以这里的path设置为／jmeter，因为使用Tomcat服务器，所以port number是8080。设置后的屏幕截图如下：

　　图三： 测试计划中使用的默认Http参数

　　图三： 测试计划中使用的默认Http参数

　　26 增加Http请求

　　现在我们需要增加http请求了，他也是我们测试的内容主体部分。你可以通过下面的步骤来增加性的http请求：

　　1 选中可视化界面中左边树的Thread Group节点，单击右键，选择Add'sampler'http request，界面右边将会出现他的设置信息框。

　　2 他的参数和25中介绍的http属性差不多，增加的属性中有发送http时方法的选择，你可以选择为get或者post。

　　我们现在增加两个http 请求，因为我们设置了默认的http属性，所以和默认http属性中相同的属性不再重复设置。设置后的屏幕截图如下：

　　图四：设置好的jsp测试请求

　　图四：设置好的jsp测试请求

　　图五：设置好的Servlet测试请求（带参数）

　　图五：设置好的Servlet测试请求（带参数）

　　27 增加Listener

　　增加listener是为了记录测试信息并且可以使用Jmeter提供的可视化界面查看测试结果，里面有好几种结果分析方式可供选择，你可以根据自己习惯的分析方式选择不同的结果显示方式，我们这里使用表格的形式来查看和分析测试结果。你可以通过下面的步骤来增加listener：

　　1 选中可视化界面中左边树的Test Plan节点，单击右键，选择Add'listener'view result in table，界面右边将会出现他的设置信息和结果显示框。

　　2 你可以设置界面上面的filename属性设置将测试结果保存到某个文件中 界面下面将使用表格显示测试结果，表格的第一列sampleno显示请求执行的顺序和编号，url显示请求发送的目标，sample－ms列显示这个请求完成耗费的时间，最后的success列显示改请求是否成功执行。

　　界面的最下面你还可以看到一些统计信息，最关心的应该是Average吧，也就是相应的平均时间。

　　28 开始执行测试计划

　　现在你可以通过单击菜单栏run -> Start开始执行测试计划了。下面这两个图是作者第一次、第二次执行该测试计划的结果图:

　　大家可以看到第一次执行时的几个大时间值均来自于jsp request，这可以通过下面的理由进行解释：jsp执行前都需要被编译成class文件。所以第二次的结果才是正常的结果。