大数据量测试可以分为两种类型：

1. 针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；例如银行或者电信的批量扣款以及充值等
2. 另一种是与并发测试相结合的极限状态下的综合数据测试，例如多个同时进行大数据量查询的场景

 一般的大数据量测试主要针对前者；

    后者尽量放在并发测试中。只是此时的并发测试与单纯的并发测试不同点在于，此时的并发测试要求的基础数据比较多。

在进行大数据量测试的时候需要重点考虑以下几点：

• 业务场景。分析实际业务场景，建立业务模型。
• 根据业务场景设计基础数据量；
• 根据业务场景设计独立处理数据量

进行大数据量测试比较关注的性能指标：

• 耗时；处理耗时；
• 处理笔数；
• 处理效率
• 服务器CPU
• 服务器内存
• 等

查看unix机器的系统名称有如下方法：

1. 用户登陆进去之后第一行返回的字符串如下：

HP-UX dsfinte B.11.23 U ia64 (tc)

其中dsfinte 就是机器名；

1. 输入命令>top回车后，返回系统名：System: dsfinte

闲来无事，做了一个C随机数函数产生随机数的实验；

用的是loadrunner内置的c编译器，代码很简单。

Action()
{
int RandNum;
RandNum = rand() % 100;//生成100之内的随机数
lr_log_message ("The RandNum=%d\n",RandNum);//调试信息
return 0;
}

共运行1000个循环；即生成1000个小于100（0~99）之内的数字

其中生成大于等于50的随机数有493个，占总数的49.3%，；小于50的有507个，占总数的50.7%；

如果访问数量更加的情况下，则会更加具有统计意义。适合性能测试未知用户数量的情况下设计场景。

作者: 郭松    来源: 通信世界

对于一个开发比较成熟的业务系统而言，功能相对已经完善，但在大业务量的情况下往往会出现各种异常。对此，需通过对系统进行配置修改或者产品框架调整来优化系统。在优化系统过程中，最有效的手段就是对系统做性能测试，通过测试结果的收集分析，不断进行系统优化，最终达到系统在大业务量情况下稳定运行的目的。
　　一、测试方法
　　测试方法主要通过测试过程中的测试步骤体现出来。测试步骤需根据每次的测试结果不断调整，一个完善的测试方法需要不断地进行性能测试和性能调整。在开始性能调整循环之前，必须确定以下两点：一是建立业务模型，通过统计或数学模型的方法建立起科学的业务模型，如业务流程分布比例、平均负荷、峰值负载等；二是设置性能指标，作为判断设计指标和实际性能处理指标的基准值，总体的系统吞吐量、系统的吞吐效率、响应时延等都是用于测量性能的常用度量标准。
　　确定以上两点后，开始调整循环，这是一系列重复的受控性能试验。重复四个调整循环阶段，直至获得在开始调整过程前建立的系统性能目标。
　　二、测试阶段
　　测试阶段是调整循环操作的起点，此阶段是根据测试的要求进行相关操作，为下一步结果统计提供相应的测试数据。此阶段需要注意测试环境配置、测试用例的操作两个要点。
　　1.测试环境配置
　　不同的测试环境会产生不同的测试结果，因此测试前需要对环境配置进行详细的检查。
　　(1)检查网络连通性。网络畅通是测试能够正常进行的基本前提。
　　(2)检查流量模型是否超出系统负荷。如果将要加的压力大大超出系统的负荷，会对系统产生伤害，并可能在测试过程中出现宕机、告警等异常情况。
　　(3)检查被测系统的系统配置。此系统配置包括软件版本和硬件配置两个方面，不同的系统配置会产生不同的测试结果，故测试之前应对被测系统的配置进行严格核对，检查是否是测试所需的系统配置。
　　(4)检查测试工具的参数配置。在性能测试中，必须利用测试工具来模拟大业务量。对于一个功能相对完善的测试工具，不但能模拟大业务量，而且还能够配置压力递增方式、压力大小、压力持续时间等参数。在测试之前需要根据测试的需求检查相应参数配置是否满足测试要求。
　　2.测试用例操作
　　测试过程中，性能测试主要按照测试用例规定的内容去逐步操作。一般来讲性能测试用例内容大体分成测试环境配置、预置条件、测试步骤、预期结果、判定原则、测试结果六个方面。
　　环境配置是指按照测试的需求配置测试环境，包括网络的组网、系统的参数配置等；测试预置条件是指为了真实模拟一些场景，需要在测试之前在系统中预置一些条件，例如在邮箱系统的性能测试过程中，为了模拟业务开展的实际情况测试，需要在邮件系统中预先存储一些积压的邮件；测试步骤是指在环境配置完成及预置条件完成后，如何对系统加压的过程，一般而言，首先确定压力的生成形式(如阶梯型递增、二次曲线形式递增等)，然后确定压力递增的时间，最后要求压力保持的时间；预期结果是指通过理论及经验分析，对实际测试结果的一个预期指标，此内容是检验测试结果的一个依据；判定原则是制定出一个标准来判断测试是否满足要求，此原则的制定很大程度上依据测试的预期结果；测试结果是根据实际测试情况及参考预期结果和判定原则对测试的一个总体结论，其结论包括此项测试是否通过及测试的相应指标记录两个方面。
　　3.结果统计
　　此过程是调整循环内容中一个承上启下的环节。此环节统计的数据来源于上一次的测试结果，并为下一步的数据分析提供相关数据。
　　结果的统计可以来源于被测系统和测试工具本身两个方面，在统计过程中不但要考虑到从被测系统中统计数据还要兼顾到测试工具本身的数据统计。一般来讲，从被测系统可以直接通过系统的日志统计出系统资源消耗(如CPU、内存的占用率等)；从测试工具本身可以统计出压力的大小、业务处理时延、业务处理成功率等指标。结果统计阶段需要将以上两个方面的数据一并统计出来，为下一步数据分析提供重要依据。
　　4.结果分析
　　通过数据统计收集到系统所需的性能数据后，对这些数据进行分析以确定系统瓶颈。在这里，需要明确的是统计到的体现性能数据仅具有指示性，它并不一定就可以确定实际的瓶颈在哪里，因为一个性能问题可能由多个原因所致。因此，在结果分析阶段需要从系统的角度去分析并查找原因，千万不能走入“头痛医头，脚痛医脚”的误区。在结果分析阶段应该注意到以下几个方面。
　　(1)数据发现的敏感性，能够主动发现一些貌似“合理”的数据问题。
　　(2)数据分析的系统性，能够通过测试数据的表象，从系统的角度对数据进行分析，发现系统瓶颈。
　　(3)数据合理的疑问性，测试工作的目的就是要发现问题，优化系统，所以应该抱着对所有数据怀疑的态度去分析测试数据，这样才能做到不遗漏任何的“可疑”数据。
　　(4)结果分析的分步性，通过测试经验，对于测试结果分析可以分成六步进行，包括观察、初步假设、预测、测试、控制和结论，结论由该过程积累的最佳证据集合所支持的假设组成。
　　三、总结
　　在循环调整的过程中，测试、结果统计、结果分析环节的最终目的是要对系统进行优化。因此，系统优化的依据直接来源于对测试结果的分析。通常来讲，对于一个比较成熟的系统，系统的绝大多数优化工作往往是对系统配置的优化，只有少部分的优化工作是对系统设计的修改。
　　通过对结果的分析，可以大体定位出系统问题出现在哪里，随后对系统配置进行更改及优化。此优化过程大部分的工作是尝试性和不间断性的，需要不断尝试配置参数的改变，然后验证此配置的修改是否达到预期目的。如果没有达到预期目的，需要进一步对配置进行修改和验证。根据以往的测试经验，实现参数配置更改的最重要规则是一次仅实现一个配置更改。这主要是由于系统某一个模块/单元出现问题可能是由多个模块/单元的瓶颈导致的。因此，分别处理每个问题很重要。如果同时进行多个更改，将不可能准确地评定每次更改的影响。
　　实现了配置更改后，必须对修改后的系统进行测试，确定更改对系统所产生的影响。如果幸运，性能提高到预期的水平，这时便可以退出。如果不是这样，则必须重新逐步进行调整循环。
　　综合考虑以上的内容，一个调整循环的流程才算基本完成，根据调整的结果来考虑是否进入下一部调整循环的阶段。

1. 测试环境需要确定。如果是专用网，那么客户端到服务器端的通路故障则一般不会体现；但是如果是门户网站，就像搜狐，访问它的用户遍布全球，各种网络用户都有，这种情况下客户端到服务器端的通路则会是很大故障。单纯的提多少个用户是没有意义的，必须结合一定的环境。
2. 性能测试范围需要确定。比如，要求每秒50个请求，50个请求是什么样子的请求。比如设计的50个请求中，会不会一部分就是简单的浏览；而另一部分则是批量操作？明显的，两个操作不一样，耗时肯定不一样。所有需要详细分析业务模式是什么样子的,根据业务模式详细确定场景。
3. 性能测试的测试结果分析讲究的是一个统计含义的分析。你可以看下你的测试结果属于哪种统计范畴。认为一般情况下不需要严格定义每秒的请求数量。例如，客户有可能要求的是服务器处理100条/分钟.那么我认为，你执行性能测试时间长60分钟，按照要求需要处理6000条数据/60分钟；服务器共处理请求5900条/10分钟与处理6100条/10分钟；是没有统计学意义上的差异的。

1. 内存分析方法
   内存分析用于判断系统有无内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。
   内存分析需要使用的计数器：Memory类别和Physical Disk类别的计数器。内存分析的主要方法和步骤：
   （1）首先查看Memory\Available Mbytes指标
   如果该指标的数据比较小，系统可能出现了内存方面的问题，需要继续下面步骤进一步分析。
注：   在UNIX/LINUX中，对应指标是FREE(KB)
   （2）注意Pages/sec、Pages Read/sec和Page Faults/sec的值
操作系统会利用磁盘较好的方式提高系统可用内存量或者提高内存的使用效率。这三个指标直接反应了操作系统进行磁盘交换的频度。
   如果Pages/sec的计数持续高于几百，可能有内存问题。但Pages/sec值不一定就表明有内存问题，可能是运行使用内存映射文件的程序所致。Page Faults/sec说明每秒发生页面失效次数，页面失效次数越多，说明操作系统向内存读取的次数越多。此事需要查看Pages Read/sec的计数值，该计数器的阀值为5，如果计数值超过5，则可以判断存在内存方面的问题。
   注：在UNIX/LINUX系统中，对于指标是(page)si和(page)so.
   （3）根据Physical Disk计数器的值分析性能瓶颈
   对Physical Disk计数器的分析包括对Page Reads/sec和%Disk Time及Aerage Disk Queue Length的分析。如果Pages Read/sec很低，同时%Disk Time和Average Disk Queue Length的值很高，则可能有磁盘瓶颈。但是，如果队列长度增加的同时Pages Read/sec并未降低，则是内存不足。
注：在 UNIX/LINUX系统中，对应的指标是Reads(Writes)per sec、Percent of time the disk is busy和Average number of transactions waiting for service.
2.处理器分析法
   （1）首先看System\%Total Processor Time 性能计数器的计数值
该计数器的值体现服务器整体处理器利用率，对多处理器的系统而言，该计数器提醒所有CPU的平均利用率。如果该值持续超过90％，则说明整个系统面临着处理器方面的瓶颈，需要通过增加处理器来提高性能。
   注：多处理器系统中，该数据本身不大，但PUT直接负载状况极不均衡，也应该视作系统产生处理器方面瓶颈。
   （2）其次查看每个CPU的Processor\%Processor Time 和 Processor\%User   Time 和 Processor\%Privileged Time
Processor\%User   Time 是系统非核心操作消耗的CPU时间，如果该值较大，可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器， Processor\%User   Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。
   （3）研究系统处理器瓶颈
查看 System\Processor Queue Length 计数器的值，当该计数器的值大于CPU数量的总数＋1时，说明产生了处理器阻塞。在处理器的%Process Time很高时，一般都随处理器阻塞，但产生处理器阻塞时，Processor\%Process Time 计数器的值并不一定很大，此时就必须查找处理器阻塞的原因。
%DOC Time 是另一个需要关注的内容，该计数器越低越好。在多处理器系统中，如果这个值大于50％，并且Processor\%Precessor Time非常高，加入一个网卡可能回提高性能。
3.磁盘I/O分析方法
   （1）计算梅磁盘的I/O数
   每磁盘的I/O数可用来与磁盘的I/O能力进行对比，如果经过计算得到的每磁盘I/O数超过了磁盘标称的I/O能力，则说明确实存在磁盘的性能瓶颈。
   每磁盘I/O计算方法
RAID0计算方法：（Reads +Writes)/Number of Disks
RAID0计算方法：（Reads +2*Writes)/2
RAID0计算方法：[Reads +(4*Writes)]/Number of Disks
RAID0计算方法：[Reads +(2*Writes)]/Number of Disks
   （2）与Processor\Privileged Time 合并进行分析
   如果在Physical Disk 计数器中，只有％Disk Time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大，且数值持续超过80％，则可能是内存泄漏。
   （3）根据Disk sec/Transfer进行分析
一般来说，定义该数值小于15ms为Excellent，介于15～30ms之间为良好，30～60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了。
4.进程分析方法
   （1）查看进程的％Processor Time值
   每个进程的％Processor Time反映进程所消耗的处理器时间。用不同进程所消耗的处理器时间进行对比，可以看出具体哪个进程在性能测试过程中消耗了最多的处理器时间，从而可以据此针对应用进行优化。
   （2）查看每个进程产生的页面失效
可以用每个进程产生的页面失效（通过PRCESS\PAGE FAILURES/SEC计数器获得）和系统页面失效(可以通过MEMORY\PAGE FAILURES/SEC计数器获得)的比值，来判断哪个进程产生了最多的页面失效，这个进程要么是需要大量内存的进程，要么是非常活跃的进程，可以对其进行重点分析。
   （3）了解进程的Process/Private Bytes
Process/Private Bytes是指进程所分配的无法与其他进程共享的当前字节数量。该计数器主要用来判断进程在性能测试过程中有无内存泄漏。例如：对于一个IIS之上的 WEB应用，我们可以重点监控inetinfo进程的Private Bytes，如果在性能测试过程中，该进程的Private Bytes计数器值不断增加，或是性能测试停止后一段时间，该进程的Private Bytes仍然持续在高水平，则说明应用存在内存泄漏。
   注：在UNIX/LINUX系统中，对应的指标是Resident Size
5.网络分析方法
   （1）Network Interface\Bytes Total/sec为发送和接收字节的速率，可以通过该计数器值来判断网络链接速度是否是瓶颈，具体操作方法是用该计数器的值和目前网络的带宽进行比较。