HPCS采用Windows Server 2008的Windows部署服务（Windows Deployment Services）技术，提供了改进的部署，更加快速的微软消息传递接口（Microsoft Message Passing Interface，MS-MPI）提供了新的NetworkDirect支持，先进的作业调度和基于Microsoft System Center 2007用户界面（UI）的新管理接口，能支持Windows PowerShell尡为首选的脚本接口。性能测试是个非常广泛的概念，如果从被测系统的角度看，可以分为客户端性能测试、服务器端性能测试；如果只做服务器的性能测试，可以细分为负载测试、压力测试、并发测试、稳定性测试、容量测试等。
你说的LR，应该是说服务器性能测试，我这边就从服务器性能测试的角度分析一下，服务器性能测试到底要做哪些事情看
主要步骤是分三步：
一、设计测试方案
测试方案就是在你理解服务器架构的基础上，根据服务器的性能基线，设计出的一个详细测试方案，内容包含你要测的服务器需要测试哪些场景，是单个场景还是多个场景混在一起的综合场景，测试完成之后，最终需要达到什么样的一个性能指标，另外还需要设计出一个机器人的行为逻辑，这个行为逻辑尽可能去真实的模拟用户的行为逻辑，一般可以根据封测时的运营数据。
二、机器人开发
根据上一步设计出的测试方案，进行机器人代码的开发。
市面上可选择的机器人比较多，如果你用LR，LR是支持用C语言、java语言开发插件，在LR的代码中动态加载进来即可进行充分的压测，LR的缺点就是只能在windows机器上运行，如果你的服务器部署在IDC机房，PC机跟服务器之间的上行带宽有限的情况下，压力很难上的去。
这里提下性能测试的工具，WeTest压力测试： ,机器人都是部署在IDC机房的，会根据你的服务器选择距离最近的一个节点去产生压力，你只需要写下机器人代码，填写服务器IP即可开始压测。
三、数据分析
在服务器性能测试过程中，可能会反复测试，测到达到服务器的性能指标为止。在此期间，你需要定位到服务器的性能瓶颈在哪里，CPU、内存、网络、IO这四个系统方面的瓶颈，还是代码写的有问题。这个数据分析的过程是非常有技术含量的一件事情，需要去了解服务器内核，需要去了解代码是如何实现的。数据分析完成后，再输出一份有技术含量的报告，就完美了！Windows性能计数器--磁盘性能分析Disk
Physical Disk：
单次IO大小
AvgDisk Bytes/Read
AvgDisk Bytes/Write
IO响应时间
AvgDisk sec/Read
AvgDisk sec/Write
IOPS
DiskReads/sec
DiskWrites/sec
DiskTransfers/sec
IO吞吐率
DiskBytes/sec
DiskRead Bytes/sec
DiskWrite Bytes/sec
磁盘有两个重要的参数：Seek time、Rotational latency。
正常的I/O计数为：①1000/(Seek time+Rotational latency)075，在此范围内属正常。当达到85％的I/O计数以上时则基本认为已经存在I/O瓶颈。理论情况下，磁盘的随机读计数为125、 顺序读计数为225。对于数据文件而言是随机读写，日志文件是顺序读写。因此，数据文件建议存放于RAID5上，而日志文件存放于RAID10或 RAID1中。
附：
15000 RPM：150随机IOPS
10000 RPM：110随机IOPS
5400 RPM：50随机IOPS
下面假设在有4块硬盘的RAID5中观察到的Physical Disk性能对象的部分值：
Avg DiskQueue Length 12 队列长度
Avg DiskSec/Read 035 读数据所用时间ms
Avg DiskSec/Write 045 写数据所用时间ms
DiskReads/sec 320 每秒读数据量
DiskWrites/sec 100 每秒写数据量
Avg DiskQueue Length，12/4=3，每块磁盘的平均队列建议不超过2。
Avg DiskSec/Read一般不要超过11～15ms。
Avg DiskSec/Write一般建议小于12ms。
从上面的结果，我们看到磁盘本身的I/O能力是满足我们的要求的，原因是因为有大量的请求才导致队列等待，这很可能是因为你的SQL语句导致大量的表扫描所致。在进行优化后，如果还是不能达到要求，下面的公式可以帮助你计算使用几块硬盘可以满足这样的并发要求：
Raid 0 -- I/Os per disk = (reads +writes) / number of disks
Raid 1 -- I/Os per disk = [reads +(2 writes)] / 2
Raid 5 -- I/Os per disk = [reads +(4 writes)] / number of disks
Raid 10 -- I/Os per disk = [reads +(2 writes)] / number of disks
我们得到的结果是：(320+400)/4=180，这时你可以根据公式①来得到磁盘的正常I/O值。假设现在正常I/O计数为125，为了达到这个结果：720/125=576。就是说要用6块磁盘才能达到这样的要求。
但是上面的Disk Reads/sec和Disk Writes/sec是个很难正确估算的值。因此只能在系统比较忙时，大概估算一个平均值，作为计算公式的依据。另一个是你很难从客户那里得到Seek time、 Rotational latency参数的值，这也只能用理论值125进行计算。
前言
作为一个数据库管理员，关注系统的性能是日常最重要的工作之一，而在所关注的各方面的性能只能IO性能却是最令人头痛的一块，面对着各种生涩的参数和令人眼花缭乱的新奇的术语，再加上存储厂商的忽悠，总是让我们有种云里雾里的感觉。本系列文章试图从基本概念开始对磁盘存储相关的各种概念进行综合归纳，让大家能够对IO性能相关的基本概念，IO性能的监控和调整有个比较全面的了解。
在这一部分里我们先舍弃各种结构复杂的存储系统，直接研究一个单独的磁盘的性能问题，藉此了解各个衡量IO系统系能的各个指标以及之间的关系。
几个基本的概念
在研究磁盘性能之前我们必须先了解磁盘的结构，以及工作原理。不过在这里就不再重复说明了，关系硬盘结构和工作原理的信息可以参考维基百科上面的相关词条——Hard disk drive（英文）和硬盘驱动器（中文）。
读写IO(Read/Write IO) *** 作
磁盘是用来给我们存取数据用的，因此当说到IO *** 作的时候，就会存在两种相对应的 *** 作，存数据时候对应的是写IO *** 作，取数据的时候对应的是读IO *** 作。
单个IO *** 作
当控制磁盘的控制器接到 *** 作系统的读IO *** 作指令的时候，控制器就会给磁盘发出一个读数据的指令，并同时将要读取的数据块的地址传递给磁盘，然后磁盘会将读取到的数据传给控制器，并由控制器返回给 *** 作系统，完成一个写IO的 *** 作；同样的，一个写IO的 *** 作也类似，控制器接到写的IO *** 作的指令和要写入的数据，并将其传递给磁盘，磁盘在数据写入完成之后将 *** 作结果传递回控制器，再由控制器返回给 *** 作系统，完成一个写IO的 *** 作。单个IO *** 作指的就是完成一个写IO或者是读IO的 *** 作。
随机访问(Random Access)与连续访问(Sequential Access)
随机访问指的是本次IO所给出的扇区地址和上次IO给出扇区地址相差比较大，这样的话磁头在两次IO *** 作之间需要作比较大的移动动作才能重新开始读/写数据。相反的，如果当次IO给出的扇区地址与上次IO结束的扇区地址一致或者是接近的话，那磁头就能很快的开始这次IO *** 作，这样的多个IO *** 作称为连续访问。因此尽管相邻的两次IO *** 作在同一时刻发出，但如果它们的请求的扇区地址相差很大的话也只能称为随机访问，而非连续访问。
顺序IO模式(Queue Mode)/并发IO模式(BurstMode)
磁盘控制器可能会一次对磁盘组发出一连串的IO命令，如果磁盘组一次只能执行一个IO命令时称为顺序IO；当磁盘组能同时执行多个IO命令时，称为并发IO。并发IO只能发生在由多个磁盘组成的磁盘组上，单块磁盘只能一次处理一个IO命令。
单个IO的大小(IO ChunkSize)
熟悉数据库的人都会有这么一个概念，那就是数据库存储有个基本的块大小(Block Size)，不管是SQL Server还是Oracle，默认的块大小都是8KB，就是数据库每次读写都是以8k为单位的。那么对于数据库应用发出的固定8k大小的单次读写到了写磁盘这个层面会是怎么样的呢，就是对于读写磁盘来说单个IO *** 作 *** 作数据的大小是多少呢，是不是也是一个固定的值？答案是不确定。首先 *** 作系统为了提高 IO的性能而引入了文件系统缓存(File System Cache)，系统会根据请求数据的情况将多个来自IO的请求先放在缓存里面，然后再一次性的提交给磁盘，也就是说对于数据库发出的多个8K数据块的读 *** 作有可能放在一个磁盘读IO里就处理了。还有对于有些存储系统也是提供了缓存（Cache）的，接收到 *** 作系统的IO请求之后也是会将多个 *** 作系统的 IO请求合并成一个来处理。不管是 *** 作系统层面的缓存还是磁盘控制器层面的缓存，目的都只有一个，提高数据读写的效率。因此每次单独的IO *** 作大小都是不一样的，它主要取决于系统对于数据读写效率的判断。
当一次IO *** 作大小比较小的时候我们成为小的IO *** 作，比如说1K，4K，8K这样的；当一次IO *** 作的数据量比较的的时候称为大IO *** 作，比如说32K，64K甚至更大。
在我们说到块大小（Block Size）的时候通常我们会接触到多个类似的概念，像我们上面提到的那个在数据库里面的数据最小的管理单位，Oralce称之为块(Block)，大小一般为8K，SQL Server称之为页(Page)，一般大小也为8k。在文件系统里面我们也能碰到一个文件系统的块，在现在很多的Linux系统中都是4K（通过 /usr/bin/time -v可以看到），它的作用其实跟数据库里面的块/页是一样的，都是为了方便数据的管理。但是说到单次IO的大小，跟这些块的大小都是没有直接关系的，在英文里单次IO大小通常被称为是IO Chunk Size，不会说成是IO Block Size的。
IOPS(IO per Second)
IOPS，IO系统每秒所执行IO *** 作的次数，是一个重要的用来衡量系统IO能力的一个参数。对于单个磁盘组成的IO系统来说，计算它的IOPS不是一件很难的事情，只要我们知道了系统完成一次IO所需要的时间的话我们就能推算出系统IOPS来。
现在我们就来推算一下磁盘的IOPS，假设磁盘的转速(Rotational Speed)为15K RPM，平均寻道时间为5ms，最大传输速率为40MB/s（这里将读写速度视为一样，实际会差别比较大）。
对于磁盘来说一个完整的IO *** 作是这样进行的：当控制器对磁盘发出一个IO *** 作命令的时候，磁盘的驱动臂(ActuatorArm)带读写磁头(Head)离开着陆区(LandingZone，位于内圈没有数据的区域)，移动到要 *** 作的初始数据块所在的磁道(Track)的正上方，这个过程被称为寻址(Seeking)，对应消耗的时间被称为寻址时间(SeekTime)；但是找到对应磁道还不能马上读取数据，这时候磁头要等到磁盘盘片(Platter)旋转到初始数据块所在的扇区(Sector)落在读写磁头正上方的之后才能开始读取数据，在这个等待盘片旋转到可 *** 作扇区的过程中消耗的时间称为旋转延时(RotationalDelay)；接下来就随着盘片的旋转，磁头不断的读/写相应的数据块，直到完成这次IO所需要 *** 作的全部数据，这个过程称为数据传送(DataTransfer)，对应的时间称为传送时间(TransferTime)。完成这三个步骤之后一次IO *** 作也就完成了。
在我们看硬盘厂商的宣传单的时候我们经常能看到3个参数，分别是平均寻址时间、盘片旋转速度以及最大传送速度，这三个参数就可以提供给我们计算上述三个步骤的时间。
第一个寻址时间，考虑到被读写的数据可能在磁盘的任意一个磁道，既有可能在磁盘的最内圈（寻址时间最短），也可能在磁盘的最外圈（寻址时间最长），所以在计算中我们只考虑平均寻址时间，也就是磁盘参数中标明的那个平均寻址时间，这里就采用当前最多的10krmp硬盘的5ms。
第二个旋转延时，和寻址一样，当磁头定位到磁道之后有可能正好在要读写扇区之上，这时候是不需要额外额延时就可以立刻读写到数据，但是最坏的情况确实要磁盘旋转整整一圈之后磁头才能读取到数据，所以这里我们也考虑的是平均旋转延时，对于10krpm的磁盘就是(60s/15k)(1/2)= 2ms。
第三个传送时间，磁盘参数提供我们的最大的传输速度，当然要达到这种速度是很有难度的，但是这个速度却是磁盘纯读写磁盘的速度，因此只要给定了单次IO的大小，我们就知道磁盘需要花费多少时间在数据传送上，这个时间就是IOChunk Size / Max Transfer Rate。
现在我们就可以得出这样的计算单次IO时间的公式：
IO Time = Seek Time + 60 sec/Rotational Speed/2 + IO ChunkSize/Transfer Rate
于是我们可以这样计算出IOPS
IOPS = 1/IO Time = 1/(Seek Time + 60 sec/Rotational Speed/2 + IOChunk Size/Transfer Rate)
对于给定不同的IO大小我们可以得出下面的一系列的数据
4K (1/71 ms = 140 IOPS)
5ms + (60sec/15000RPM/2) + 4K/40MB = 5 + 2 + 01 = 71
8k (1/72 ms = 139 IOPS)
5ms + (60sec/15000RPM/2) + 8K/40MB = 5 + 2 + 02 = 72
16K (1/74 ms = 135 IOPS)
5ms + (60sec/15000RPM/2) + 16K/40MB = 5 + 2 + 04 = 74
32K (1/78 ms = 128 IOPS)
5ms + (60sec/15000RPM/2) + 32K/40MB = 5 + 2 + 08 = 78
64K (1/86 ms = 116 IOPS)
5ms + (60sec/15000RPM/2) + 64K/40MB = 5 + 2 + 16 = 86
从上面的数据可以看出，当单次IO越小的时候，单次IO所耗费的时间也越少，相应的IOPS也就越大。
上面我们的数据都是在一个比较理想的假设下得出来的，这里的理想的情况就是磁盘要花费平均大小的寻址时间和平均的旋转延时，这个假设其实是比较符合我们实际情况中的随机读写，在随机读写中，每次IO *** 作的寻址时间和旋转延时都不能忽略不计，有了这两个时间的存在也就限制了IOPS的大小。现在我们考虑一种相对极端的顺序读写 *** 作，比如说在读取一个很大的存储连续分布在磁盘的文件，因为文件的存储的分布是连续的，磁头在完成一个读IO *** 作之后，不需要从新的寻址，也不需要旋转延时，在这种情况下我们能到一个很大的IOPS值，如下
4K (1/01 ms = 10000 IOPS)
0ms + 0ms + 4K/40MB = 01
8k (1/02 ms = 5000 IOPS)
0ms + 0ms + 8K/40MB = 02
16K (1/04 ms = 2500 IOPS)
0ms + 0ms + 16K/40MB = 04
32K (1/08 ms = 1250 IOPS)
0ms + 0ms + 32K/40MB = 08
64K (1/16 ms = 625 IOPS)
0ms + 0ms + 64K/40MB = 16
相比第一组数据来说差距是非常的大的，因此当我们要用IOPS来衡量一个IO系统的系能的时候我们一定要说清楚是在什么情况的IOPS，也就是要说明读写的方式以及单次IO的大小，当然在实际当中，特别是在OLTP的系统的，随机的小IO的读写是最有说服力的。
传输速度(Transfer Rate)/吞吐率(Throughput)
现在我们要说的传输速度（另一个常见的说法是吞吐率）不是磁盘上所表明的最大传输速度或者说理想传输速度，而是磁盘在实际使用的时候从磁盘系统总线上流过的数据量。有了IOPS数据之后我们是很容易就能计算出对应的传输速度来的
Transfer Rate = IOPS IO Chunk Size
还是那上面的第一组IOPS的数据我们可以得出相应的传输速度如下
4K: 140 4K = 560K / 40M = 136%
8K: 139 8K = 1112K / 40M = 271%
16K: 135 16K = 2160K / 40M = 527%
32K: 116 32K = 3712K / 40M = 906%
可以看出实际上的传输速度是很小的，对总线的利用率也是非常的小。
这里一定要明确一个概念，那就是尽管上面我们使用IOPS来计算传输速度，但是实际上传输速度和IOPS是没有直接关系，在没有缓存的情况下它们共同的决定因素都是对磁盘系统的访问方式以及单个IO的大小。对磁盘进行随机访问时候我们可以利用IOPS来衡量一个磁盘系统的性能，此时的传输速度不会太大；但是当对磁盘进行连续访问时，此时的IOPS已经没有了参考的价值，这个时候限制实际传输速度却是磁盘的最大传输速度。因此在实际的应用当中，只会用IOPS 来衡量小IO的随机读写的性能，而当要衡量大IO连续读写的性能的时候就要采用传输速度而不能是IOPS了。
IO响应时间(IOResponse Time)
最后来关注一下能直接描述IO性能的IO响应时间。IO响应时间也被称为IO延时(IOLatency)，IO响应时间就是从 *** 作系统内核发出的一个读或者写的IO命令到 *** 作系统内核接收到IO回应的时间，注意不要和单个IO时间混淆了，单个IO时间仅仅指的是IO *** 作在磁盘内部处理的时间，而IO响应时间还要包括IO *** 作在IO等待队列中所花费的等待时间。
计算IO *** 作在等待队列里面消耗的时间有一个衍生于利托氏定理(Little’sLaw)的排队模型M/M/1模型可以遵循，由于排队模型算法比较复杂，到现在还没有搞太明白（如果有谁对M/M/1模型比较精通的话欢迎给予指导），这里就罗列一下最后的结果，还是那上面计算的IOPS数据来说：
8K IO Chunk Size (135 IOPS, 72 ms)
135 => 2400 ms
105 => 295 ms
75 => 157 ms
45 => 106 ms
64K IO Chunk Size(116 IOPS, 86 ms)
135 => 没响应了……
105 => 886 ms
75 => 246 ms
45 => 146 ms
从上面的数据可以看出，随着系统实际IOPS越接近理论的最大值，IO的响应时间会成非线性的增长，越是接近最大值，响应时间就变得越大，而且会比预期超出很多。一般来说在实际的应用中有一个70%的指导值，也就是说在IO读写的队列中，当队列大小小于最大IOPS的70%的时候，IO的响应时间增加会很小，相对来说让人比较能接受的，一旦超过70%，响应时间就会戏剧性的暴增，所以当一个系统的IO压力超出最大可承受压力的70%的时候就是必须要考虑调整或升级了。
另外补充说一下这个70%的指导值也适用于CPU响应时间，这也是在实践中证明过的，一旦CPU超过70%，系统将会变得受不了的慢。很有意思的东西。
从上一篇文章的计算中我们可以看到一个15k转速的磁盘在随机读写访问的情况下IOPS竟然只有140左右，但在实际应用中我们却能看到很多标有5000IOPS甚至更高的存储系统，有这么大IOPS的存储系统怎么来的呢？这就要归结于各种存储技术的使用了，在这些存储技术中使用最广的就是高速缓存(Cache)和磁盘冗余阵列(RAID)了，本文就将探讨缓存和磁盘阵列提高存储IO性能的方法。
高速缓存(Cache)
在当下的各种存储产品中，按照速度从快到慢应该就是内存>闪存>磁盘>磁带了，然而速度越快也就意味着价格越高，闪存虽然说是发展势头很好，但目前来说却还是因为价格问题无法普及，因此现在还是一个磁盘作霸王的时代。与CPU和内存速度相比，磁盘的速度无疑是计算机系统中最大的瓶颈了，所以在必须使用磁盘而又想提高性能的情况下，人们想出了在磁盘中嵌入一块高速的内存用来保存经常访问的数据从而提高读写效率的方法来折中的解决，这块嵌入的内存就被称为高速缓存。
说到缓存，这东西应用现在已经是无处不在，从处于上层的应用，到 *** 作系统层，再到磁盘控制器，还有CPU内部，单个磁盘的内部也都存在缓存，所有这些缓存存在的目的都是相同的，就是提高系统执行的效率。当然在这里我们只关心跟IO性能相关的缓存，与IO性能直接相关的几个缓存分别是文件系统缓存(FileSystem Cache)、磁盘控制器缓存(DiskController Cache)和磁盘缓存(DiskCache,也称为DiskBuffer)，不过当在计算一个磁盘系统性能的时候文件系统缓存也是不会考虑在内的，因此我们重点考察的就是磁盘控制器缓存和磁盘缓存。
不管是控制器缓存还是磁盘缓存，他们所起的作用主要是分为三部分：缓存数据、预读(Read-ahead)和回写(Write-back)。
缓存数据
首先是系统读取过的数据会被缓存在高速缓存中，这样下次再次需要读取相同的数据的时候就不用在访问磁盘，直接从缓存中取数据就可以了。当然使用过的数据也不可能在缓存中永久保留的，缓存的数据一般那是采取LRU算法来进行管理，目的是将长时间不用的数据清除出缓存，那些经常被访问的却能一直保留在缓存中，直到缓存被清空。
预读
预读是指采用预读算法在没有系统的IO请求的时候事先将数据从磁盘中读入到缓存中，然后在系统发出读IO请求的时候，就会实现去检查看看缓存里面是否存在要读取的数据，如果存在（即命中）的话就直接将结果返回，这时候的磁盘不再需要寻址、旋转等待、读取数据这一序列的 *** 作了，这样是能节省很多时间的；如果没有命中则再发出真正的读取磁盘的命令去取所需要的数据。
缓存的命中率跟缓存的大小有很大的关系，理论上是缓存越大的话，所能缓存的数据也就越多，这样命中率也自然越高，当然缓存不可能太大，毕竟成本在那儿呢。如果一个容量很大的存储系统配备了一个很小的读缓存的话，这时候问题会比较大的，因为小缓存的数据量非常小，相比整个存储系统来说比例非常低，这样随机读取（数据库系统的大多数情况）的时候命中率也自然就很低，这样的缓存不但不能提高效率（因为绝大部分读IO都还要读取磁盘），反而会因为每次去匹配缓存而浪费时间。
执行读IO *** 作是读取数据存在于缓存中的数量与全部要读取数据的比值称为缓存命中率(ReadCache Hit Radio)，假设一个存储系统在不使用缓存的情况下随机小IO读取能达到150IOPS，而它的缓存能提供10%的缓存命中率的话，那么实际上它的IOPS可以达到150/(1-10%)=166。
回写
首先说一下，用于回写功能的那部分缓存被称为写缓存(WriteCache)。在一套写缓存打开的存储中， *** 作系统所发出的一系列写IO命令并不会被挨个的执行，这些写IO的命令会先写入缓存中，然后再一次性的将缓存中的修改推到磁盘中，这就相当于将那些相同的多个IO合并成一个，多个连续 *** 作的小IO合并成一个大的IO，还有就是将多个随机的写IO变成一组连续的写IO，这样就能减少磁盘寻址等 *** 作所消耗的时间，大大的提高磁盘写入的效率。
读缓存虽然对效率提高是很明显的，但是它所带来的问题也比较严重，因为缓存和普通内存一样，掉点以后数据会全部丢失，当 *** 作系统发出的写IO命令写入到缓存中后即被认为是写入成功，而实际上数据是没有被真正写入磁盘的，此时如果掉电，缓存中的数据就会永远的丢失了，这个对应用来说是灾难性的，目前解决这个问题最好的方法就是给缓存配备电池了，保证存储掉电之后缓存数据能如数保存下来。
和读一样，写缓存也存在一个写缓存命中率(WriteCache Hit Radio)，不过和读缓存命中情况不一样的是，尽管缓存命中，也不能将实际的IO *** 作免掉，只是被合并了而已。
控制器缓存和磁盘缓存除了上面的作用之外还承当着其他的作用，比如磁盘缓存有保存IO命令队列的功能，单个的磁盘一次只能处理一个IO命令，但却能接收多个IO命令，这些进入到磁盘而未被处理的命令就保存在缓存中的IO队列中。
RAID(Redundant Array Of InexpensiveDisks)
如果你是一位数据库管理员或者经常接触服务器，那对RAID应该很熟悉了，作为最廉价的存储解决方案，RAID早已在服务器存储中得到了普及。在RAID的各个级别中，应当以RAID10和RAID5（不过RAID5已经基本走到头了，RAID6正在崛起中，看看这里了解下原因）应用最广了。下面将就RAID0，RAID1，RAID5，RAID6，RAID10这几种级别的RAID展开说一下磁盘阵列对于磁盘性能的影响，当然在阅读下面的内容之前你必须对各个级别的RAID的结构和工作原理要熟悉才行，这样才不至于满头雾水，推荐查看wikipedia上面的如下条目：RAID，StandardRAID levels，Nested RAID levels。天互数据 为您解答
服务器测试方法
服务器测试方法分为两个大方面，性能测试与功能测试。
我们在性能测试方面采用了新的测试方法，主要分为文件测试、数据库性能测试与
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
模拟实际的用户发出
>一般情况下，我们可能想测试一下服务器上的文件（用户上传的或者后台写入的）是否可以被外网访问到，以进一步测试文件下载等功能。
我原本想尝试从服务器的任意目录访问文件，但是经过数次的尝试，网上教的通过修改Tomcat路径映射和自定义XML来进行文件映射都不能成功访问到目标文件。
最后查到，把文件放在Tomcat的ROOT目录下，就可以用服务器域名+“/”+“文件名（带后缀）”直接访问到文件，亲测成功，。
性能测试 在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。 应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。
并发性能测试是重点
并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务 *** 作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。
当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候，尤其是以后在生产环境中实际使用起来，用户往往会产生疑问，这套系统能不能承受大量的并发用户同时访问 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。
举例说明：电信计费软件
众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤，但当成百上千的终端，同时执行这样的 *** 作时，情况就大不一样了，如此众多的交易同时发生，对应用程序本身、 *** 作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力，预见软件的并发承受力，这是在软件测试阶段就应该解决的问题。
大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。
如何模拟实际情况呢 找若干台电脑和同样数目的 *** 作人员在同一时刻进行 *** 作，然后拿秒表记录下反应时间？ 这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况，这样就需要压力测试工具的辅助。
测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力，就为最终用户规划整个运行环境的配置提供了有力的依据。
并发性能测试前的准备工作
测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的 *** 作系统、数据库及其他应用软件构成的环境。
一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。
测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。
测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。
在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。
模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。
并发性能测试的种类与指标
并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、时，监控到>
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）