如何使用jmeter进行并发请求，以监控服务器性能？

　　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文件。所以第二次的结果才是正常的结果。

我们以Windows服务器、Linux服务器和IBM AIX服务器为例，分别说明如下：

Windows监控功能：

1、管理Windows的可用性和性能

2、监控性能统计数据，如CPU利用率、内存利用率、磁盘利用率和应答时间

3、监控Windows系统中运行的进程

4、如果Windows系统或该系统中任何指定的属性出现问题，将基于所配置的阈值生成通知和告警；基于配置自动执行操作

5、能即刻呈现性能图表和报表；并基于可用性、健康状况和连接时间分别显示报表

6、提供历史的和当前的Windows性能指标，以便了解特定时间段内的性能状态

7、监控整体的CPU利用情况，并显示哪些进程正在消耗多少CPU资源

8、监控内存使用情况并检测内存消耗大户

Linux监控功能：

1、管理Linux的可用性和性能

2、监控性能统计数据，如CPU利用率、内存利用率、磁盘利用率和应答时间

3、监控Linux系统中运行的进程

4、如果Linux系统或该系统中任何指定的属性出现问题，将基于所配置的阈值生成通知和告警；并基于配置自动执行操作

5、能即刻呈现性能图表和报表；并基于可用性、健康状况和连接时间分组和显示报表

6、提供历史的和当前的Linux性能指标，以便了解特定时间段内的性能状态

7、监控整体的CPU利用情况，并显示哪些进程正在占用多少CPU资源

8、监控内存使用情况并检测内存消耗大户

IBM AIX监控能力：

1、管理IBM AIX可用性和性能

2、监控诸如CPU利用率、内存利用率、磁盘利用率和应答时间等性能统计数据

3、监控模式包括Telnet和SSH

4、监控AIX系统上运行的进程

5、如果AIX系统或该系统中任何指定的属性出现问题，将基于所配置的阈值生成通知和告警；并基于配置自动执行操作

6、能即刻呈现性能图表和报表；并基于可用性、健康状况和连接时间分组和显示报表

7、提供历史的和当前的AIX性能指标，以便了解特定时间段内的性能状态

8、监控整体的CPU利用情况，并显示哪些进程正在占用多少CPU资源

9、监控内存使用情况并检测内存消耗大户

贴一篇我们内部的文章：

随着浏览器功能的不断完善，用户量不断的攀升，涉及到web服务的功能在不断的增加，对于我们测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么性能测试都要做些什么呢？我们该怎样进行性能测试呢？

性能测试一般会围绕以下这些问题而进行：

1 什么情况下需要做性能测试？

2 什么时候做性能测试？

3 做性能测试需要准备哪些内容？

4 什么样的性能指标是符合要求的？

5 性能测试需要收集的数据有哪些？

6 怎样收集这些数据？

7 如何分析收集到的数据？

8 如何给出性能测试报告？

性能测试的执行过程及要做的事儿主要包含以下内容：

1 测试评估阶段

在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。

首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。

测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等

2 测试准备阶段

在这个阶段，我们要了解以下内容：

a 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？数据库用的是什么？服务用的是什么语言编写的？；

b 服务端功能的内部逻辑实现；

c 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样操作数据库的？

d 服务端与客户端之间是如何进行交互的，即接口定义；

通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。

e 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；

f 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。

g 了解测试环境与线上环境的不同，例如网络环境、硬件配置等

h 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。

i 沟通上线的指标

通过收集以上信息，确定性能测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。

3 测试设计阶段

根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。

用例编写的步骤大致分为：

a 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。

b 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的操作。

c 验证参数化后脚本功能的正确性。

d 添加检查点

e 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等

4 测试执行阶段

根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。

在测试执行过程中，还要不断的关注以下内容：

a web服务的连接速度如何？

b 每秒的点击数如何？

c Web服务能允许多少个用户同时在线？

d 如果超过了这个数量，会出现什么现象？

e Web服务能否处理大量用户对同一个页面的请求？

f 如果web服务崩溃，是否会自动恢复？

g 系统能否同一时间响应大量用户的请求？

h 打压机的系统负载状态。

5 测试分析阶段

将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。

6 测试验证阶段

在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响。

想看原文或者有测试其他相关的问题可以关注下 搜狗测试 微信公众号，我们上面有不少关于性能测试分享~

人尽其才、物尽其用”。企业购买服务器当然是为满足特定需要。针对不同需求，我们要关注的性能指标也不同。举例来说，对于数据库服务器，联机事物处理能力是最需着力考察的指标。TPC-C是“事务处理性能委员会”(TPC)负责制订的基准测试指标，考察联机事务处理每分钟吞吐量。而TPC-C测试结果又包括两个指标，一个是流量指标tpmC，这个值越大越好;另一个是性价比指标Price/tpmC，指的是测试系统价格与流量指标的比值，这个值则越小越好。以IBM公司的x366为例子，根据TPC官方网站，TPC-C在线交易基准测试中，x366的流量指标达到了141504tpmC，是4路至强芯片服务器的世界纪录。

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

对于大多数人来说，基准测试指标是一个全新的知识空间 – 许多人在购买服务器时习惯于考虑CPU和内存，以为选定了这些，服务器的性能就差不多了。其实，不同的系统设计技术会对服务器的性能产生巨大影响，用诸多量化指标来衡量比较是十分必要和重要的。

用户都希望系统能24×7×365不停机、无故障地运行，这其实是要求服务器的可用性。而可用性和可管理性是息息相关的。服务器的故障处理技术越成熟，为用户提供的可用性就越高，而这个故障处理技术必须要有良好的管理手段和界面来及时表现:一方面可以通过出现故障时自动执行系统或部件切换以避免或减少意外停机，另一方面要让管理员及时察觉及帮助诊断，才能从根本上解决问题。目前这方面做得较好的是IBMx3架构服务器。它带有一种叫“弹出式光通路诊断面板”的技术，只要轻轻，光通路诊断面板就会以从服务器前端弹出，指示器可以帮助管理员快速地定位和替换故障组件，减少服务器的宕机时间。

以基准测试指标为基准，以理性考量为准绳，二者并行互航，您选择的服务器肯定错不了!

附表:部分服务器性能指标

应用

基准测试

简述

测试中主要考察的部件

联机事物处理

TPC-C

TPC-C是一种考察联机事务处理（OLTP）每分钟吞吐量的基准测试。TPC-C模拟的是完整的计算环境，大量用户针对数据库（如SQL、Server Oracle,DB2）执行并发事务操作。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效参考基准。

全面考察微处理器，内存子系统，磁盘子系统合一些网络组件

电子商务

SPECweb99 SPECweb99用于评测Web服务器能够支持的最大同时连接数的客户端/服务器基准测试。基准负载是由运行HTTP Server的服务器联网的客户端设备上的客户端软件来实现的。为Web用户提供用于评测系统用作Web服务器能力的最客观、最具代表性的基准。

系统的微处理器、内存体系结构和编译器

SPECjbb200 SPECjbb200（Java业务基准）是SPEC第一个用于评估服务器端Java的性能的基准，为Java用户提供用于评测服务器系统运行Java应用程序能力的最客观、最具代表性的基准

1、使用系统性能监视器监视当前SQL的工作性能（控制面板-->管理工具-->性能）可以查看SQL对磁盘、内存的总体占用

2、使用SQL 性能监视器（SQL Profiler）可以查看SQL 的执行事件，读写次数，起始和结束事件等等，可以保存死锁图形。

一、远程连接到Windows服务器，使用windows系统自带工具进行收集性能数据

1、Windows服务器中自带的性能监控工具叫做Performance Monitor,在开始-运行中输入‘Perfmonmsc’，然后回车即可运行。通过界面，控制面板\所有控制面板项\管理工具\性能监视器也能打开

打开后，页面展示

2、添加计数器

性能>数据收集器集>用户定义[右击]>新增‘数据收集器集’>手动创建高级>下一步

勾选创建数据日志>性能计数器>下一步

点击“添加”→选择计数器

点击选中的可用计数器>添加>确定

确定>下一步

选择目录后，点击完成

查看新增的计数器，输出地方为日志输出地址

3、选择日志数据源格式

选择用户定义下的数据收集器集>右键属性>性能计数器，日志格式选择“逗号分隔”（即csv格式）

4、开始启动数据采集，选择用户定义下的数据收集器集>右键属性>开始

此时，输出有地址了

5、用EXCEL将数据转换为折线图，并分析性能情况

二、分析性能情况

（1）内存泄露判断

●虚拟内存字节数（VirtualBytes）应该远大于工作集字节数（Workingset），如果两者变化规律相反，比如说工作集增长较快，虚拟内存增长较少，则可能说明出现了内存泄露的情况。

●对于Workingset、Private Bytes、Available bytes这些计数器，如果在测试期间内数值持续增长，而且测试停止后位置在高水平，则也说明存在内存泄露。

●Windows资源监控中，如果Process\PrivateBytes计数器和Process\WorkingSet计数器的值在长时间内持续升高，同时Memory\Available

bytes计数器的值持续降低，则很可能存在内存泄漏。

（2）CPU使用情况

●一般平均不要超过70%，最大不要超过90%（好：70% 、坏：85%、 很差：90%）

（3）tps（每秒处理事务的数量，在SOAPUI中进行统计）

●一般在10-100，不同应用程序具体值不同

三、关于计数器的选择

perfmon的计数器主要分四种：处理器性能计数器、内存性能计数器、磁盘性能计数器以及网络性能计数器。

以下为监控服务器常用的计数器：

常用的性能对象与指标

性能对象

计数器

提供的信息

Processor

% Idle Time

% Idle Time 是处理器在采样期间空闲的时间的百分比

Processor

% Processor Time

% Processor Time 指处理器用来执行非闲置线程时间的百分比。计算方法是，测量范例间隔内非闲置线程活动的时间，用范例间隔减去该值。这个计数器是处理器活动的主要说明器，显示在范例间隔时所观察的繁忙时间平均百分比。

Processor

% User Time

% User Time 指处理器处于用户模式的时间百分比。用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式。

Memory

Available Bytes

Available Bytes显示出当前空闲的物理内存总量。当这个数值变小时，Windows开始频繁地调用磁盘页面文件。如果这个数值很小，例如小于5 MB，系统会将大部分时间消耗在操作页面文件上。

Memory

% Committed Bytes in Use

% Committed Bytes In Use 是 Memory: Committed Bytes 与Memory: Commit Limit之间的比值。(Committed memory指如果需要写入磁盘时已在分页文件中保留空间的处于使用中的物理内存。Commit Limit是由分页文件的大小而决定的。如果扩大了分页文件，该比例就会减小)。这个计数器只显示当前百分比；而不是一个平均值。

Memory

Page Faults/sec

Page Faults/sec是指处理器处理错误页的综合速率。用错误页数/秒来计算。当处理器请求一个不在其工作集(在物理内存中的空间)内的代码或数据时出现的页错误。这个计数器包括硬错误(那些需要磁盘访问的)和软错误(在物理内存的其它地方找到的错误页)。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。这个计数器显示用上两个实例中观察到的值之间的差除以实例间隔的持续时间所得的值。

Network Interface

Bytes Total/sec

Bytes Total/sec是发送和接收字节的速率，包括帧字符在内。

Network Interface

Packets/sec

Packets/sec为发送和接收数据包的速率。

Physical Disk

% Busy Time

% Busy Time指磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。

Physical Disk

Avg Disk Queue Length

Avg Disk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。

Physical Disk

Current Disk Queue Length

Current Disk Queue Length指在收集操作数据时在磁盘上未完成的请求的数目。它包括在快照内存时正在为其提供服务中的请求。这是一个即时长度而非一定间隔时间的平均值。多主轴磁盘设备可以一次有多个请求操作，但是其它同时发生的请求为等候服务。这个计数器可能会反映一个暂时的高或低的列队长度，但是如果在磁盘驱动器存在持续负载，可能值会总是很高。请求等待时间与这个列队的长度减去磁盘上的主轴成正比。这个差值应小于2才能保持良好的性能。

Logical

Disk

% Free Space

% Free Space 是所选定的逻辑磁盘驱动器上总的可用空闲空间的百分比。

Logical

Disk

Free Megabytes

可用的 MB 显示磁盘驱动器上尚未分配的空间。

 以下为监控进程常用的计数器：

Process对象的主要指标

性能对象

计数器

提供的信息

Process

% Privileged Time

% Privileged Time 是在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时，此服务经常在特权模式运行，以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。对系统的调用可以是直接的(explicit)或间接的(implicit)，例如页面错误或间隔。

Process

% Processor Time

% Processor Time 是所有进程线程使用处理器执行指令所花的时间百分比。指令是计算机执行的基础单位。线程是执行指令的对象，进程是程序运行时创建的对象。此计数包括处理某些硬件间隔和陷阱条件所执行的代码。

Process

% User Time

% User Time 指处理线程用于执行使用用户模式的代码的时间的百分比。应用程序、环境分系统和集合分系统是以用户模式执行的。Windows 的可执行程序、内核和设备驱动程序不会被以用户模式执行的代码损坏。

Process

Creating Process ID value

Creating Process ID value 指创建该进程的父进程号。

Process

Elapsed Time

该进程运行的总时间(用秒计算)。

Process

Handle Count

由这个处理现在打开的句柄总数。这个数字等于这个处理中每个线程当前打开的句柄的总数。

Process

ID Process

ID Process 指这个处理的特别的识别符。ID Process 号可重复使用，所以这些 ID Process 号只能在一个处理的寿命期内识别那个处理。

Process

IO Data Bytes/sec

处理从 I/O 操作读取/写入字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Data Operations/sec

本处理进行读取/写入 I/O 操作的速率。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Other Bytes/sec

处理给不包括数据的 I/O 操作(如控制操作)字节的速率。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Other Operations/sec

本处理进行非读取/写入 I/O 操作的速率。例如，控制性能。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Read Bytes/sec

处理从 I/O 操作读取字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Read Operations/sec

本处理进行读取 I/O 操作的速率。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

IO Write Bytes/sec

处理从 I/O 操作写入字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备。

Process

IO Write Operations/sec

本处理进行写入 I/O 操作的速率。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。

Process

Page Faults/sec

Page Faults/sec 指在这个进程中执行线程造成的页面错误出现的速度。当线程引用了不在主内存工作集中的虚拟内存页即会出现 Page Fault。如果它在备用表中(即已经在主内存中)或另一个共享页的处理正在使用它，就会引起无法从磁盘中获取页。

Process

Page File Bytes

Page File Bytes 指这个处理在 Paging file 中使用的最大字节数。Paging File 用于存储不包含在其他文件中的由处理使用的内存页。Paging File 由所有处理共享，并且 Paging File 空间不足会防止其他处理分配内存。

Process

Page File Bytes Peak

Page File Bytes Peak 指这个处理在 Paging files 中使用的最大数量的字节。

Process

Pool Nonpaged Bytes

Pool Nonpaged Bytes 指在非分页池中的字节数，非分页池是指系统内存(操作系统使用的物理内存)中可供对象(指那些在不处于使用时不可以写入磁盘上而且只要分派过就必须保留在物理内存中的对象)使用的一个区域。这个计数器仅显示上一次观察的值；而不是一个平均值。

Process

Pool Paged Bytes

Pool Paged Bytes 指在分页池中的字节数，分页池是系统内存(操作系统使用的物理内存)中可供对象(在不处于使用时可以写入磁盘的)使用的一个区域。这个计数器仅显示上一次观察的值；而不是一个平均值。

Process

Priority Base

这次处理的当前基本优先权。在一个处理中的线程可以根据处理的基本优先权提高或降低自己的基本优先权。

Process

Private Bytes

Private Bytes 指这个处理不能与其他处理共享的、已分配的当前字节数。

Process

Thread Count

在这次处理中正在活动的线程数目。指令是在一台处理器中基本的执行单位，线程是指执行指令的对象。每个运行处理至少有一个线程。

Process

Virtual Bytes

Virtual Bytes 指处理使用的虚拟地址空间的以字节数显示的当前大小。使用虚拟地址空间不一定是指对磁盘或主内存页的相应的使用。虚拟空间是有限的，可能会限制处理加载数据库的能力。

Process

Virtual Bytes Peak

Virtual Bytes Peak 指在任何时间内该处理使用的虚拟地址空间字节的最大数。

Process

Working Set

Working Set 指这个处理的 Working Set 中的当前字节数。Working Set 是在处理中被线程最近触到的那个内存页集。如果计算机上的可用内存处于阈值以上，即使页不在使用中，也会留在一个处理的 Working Set中。当可用内存降到阈值以下，将从 Working Set 中删除页。如果需要页时，它会在离开主内存前软故障返回到 Working Set 中。

Process

Working Set Peak

Working Set Peak 指在任何时间这个在处理的 Working Set 的最大字节数。

　公司使用的服务器是linux的操作系统，之前很长一段时间监控系统参数都是使用top等linux命令来监控

　　这样做的好处

　　1可以非常容易的监控的系统的状态

　　2实时性非常强

　　不足之处

　　1不能和loadrunner其他的图表进行合并，造成了很难在事后分析出系统的问题

　　2监控系统的数据无法直接保存，供下次参考使用

　　最近终于说服了公司的sa，让我能在性能测试环境做必要的设置，因为之前sa一直认为我要做的事情会对系统的安全性造成影响。

　　现在我来介绍一下如何在linux设置来完成loadrunner对服务器性能的监控

　　A验证服务器上是否配置了rstatd守护程序

　　1 rup 127001

　　2find / -name rpcrstatd

　　3/usr/sbin/rpcinfo -p

　　B下载rpcrstatd

　　http://sourceforgenet/projects/rstatd

　　C打开端口映射

　　1执行 setup命令

　　这时会弹出一个类似图形化的界面，光标移动到System services，回车。在新界面中找到portmap项，空格选中。然后选择OK，再选择quit。

　　2/etc/rcd/initd/portmap start //启动portmap

　　D编译安装rstatd

　　/configure

　　make all-am

　　make install-am

　　E起rstatd服务

　　/usr/local/sbin/rpcrstatd

　　F安装xinetd服务

　　yum install xinetdi386

　　/sbin/service xinetd restart

　　好了，liunx中的设置基本上都已经设置完了，接下来只要到loadrunner中加上对相应服务的监控就可以了

芯片组与主板即使采用相同的芯片组，不同的主板设计也会对服务器性能产生重要影响。网卡服务器应当连接在传输速率最快的端口上，并最少配置一块千兆网卡。对于某些有特殊应用的服务器（如FTP、文件服务器或视频点播服务器），还应当配置两块千兆网卡。硬盘和RAID卡硬盘的读取/写入速率决定着服务器的处理速度和响应速率。除了在入门级服务器上可采用IDE硬盘外，通常都应采用传输速率更高、扩展性更好的SCSI硬盘。对于一些不能轻易中止运行的服务器而言，还应当采用热插拔硬盘，以保证服务器的不停机维护和扩容。磁盘冗余采用两块或多块硬盘来实现磁盘阵列；网卡、电源、风扇等部件冗余可以保证部分硬件损坏之后，服务器仍然能够正常运行。热插拔是指带电进行硬盘或板卡的插拔操作，实现故障恢复和系统扩容。