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

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分钟；是没有统计学意义上的差异的。

遇到td star页面白屏问题了。

找了网上网友提供的很多方法，均 不能解决。

最后自己搞定了。

其实很简单，下载了一个td 的插件。

白屏的问题很简单，一般情况下，一个客户端不会一直白屏的，白屏只是IE加载客户端控件的时候出现了问题。

那么就需要一个东东来帮忙加载控件，这个东东就是：tdexplorer。

到mercury 网站上下载安装就行了。

网址是：http://updates.merc-int.com/testdirector/td80/others/tdexplorer/index.html

 

Network Interface 计数器 Bytes Total/sec 是在每个网络适配器上发送和接收字节的速率，包括帧字符在内。Network Interface\\Bytes Received/sec 是 Network Interface\\Bytes Received/sec 和 Network Interface\\Bytes Sent/sec的总和。  Current Bandwidth 指以位/每秒估计的网络接口的当前带宽。 Output Queue Length 为输出数据列队(数据包)的长度。如果这个长于 2，即会出现延缓并且如果可能的话找出并解决瓶颈问题。由于请求是在这个操作由网络驱动程序接口规格(NDIS)列队，这永远会是 0。 Packets/sec 为在网络界面发送和接收数据包的速率。 Packets Outbound Discarded 为选为丢弃的输出数据包的数目，即便没有发现会阻止传输这些数据包的错误。丢弃数据包的可能原因是释放缓冲空间。 Packets Outbound Error 为由于错误不能传输的输出数据包的数目。 Packets Received Discarded 指选定要丢弃的输入数据包的数字，即使没有发现阻碍这些数据包成为可传送到更高层协议的错误。造成丢弃数据包的可能原因是释放缓冲器空间。 Packets Received Error 指输入数据包的数目，这些数据包含阻碍它们成为可传送到更高层协议的错误。 Packets Received/sec 为在网络界面接收数据包的速率。 Packets Sent/sec 为在网络界面发送数据包的速率。 Processor计数器  % Processor Time 指处理器用来执行非闲置线程时间的百分比。计算方法是，测量范例间隔内非闲置线程活动的时间，用范例间隔减去该值。(每台处理器有一个闲置线程，该线程在没有其他线程可以运行时消耗周期)。这个计数器是处理器活动的主要说明器，显示在范例间隔时所观察的繁忙时间平均百分比。这个值是用 100% 减去该服务不活动的时间计算出来的。 通常CPU的平均活动符合应该在80%以下，超过80%表示CPU的处理能力已经达到极限。 % DPC Time 指在范例间隔期间处理器用在缓延程序调用(DPC)接收和提供服务的百分比。DPC 正在运行的为比标准间隔优先权低的间隔。由于 DPC 是以特权模式执行的，DPC 时间的百分比为特权时间百分比的一部分。这些时间单独计算并且不属于间隔计算总数的一部分。这个总数显示了作为实例时间百分比的平均忙时。越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。 % Privileged Time 在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时，此服务经常在特权模式运行，以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。 对系统的调用可以是直接的(explicit)或间接的(implicit)，例如页面错误或中断。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统保护模式之外，还使用处理边界作为分系统保护。某些由 Windows 为您的应用程序所做的操作除了出现在处理的特权时间内，还可能在其他子系统处理出现。这个时间包括CPU维护中断和延迟过程调用的时间。如果该值过高，应该有I/O处理导致大量系统中断。 % User Time 指处理器处于用户模式的时间百分比。用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式。另一个模式为特权模式，它是为操作系统组件设计的并且允许直接访问硬件和所有内存。操作系统将应用程序线程转换成特权模式以访问操作系统服务。这个计数值将平均忙时作为示例时间的一部分显示。 Interrupts/sec 是处理器接收和处理硬件中断的平均速度，单位为每秒事例数。这不包括分开计数的延迟的进程调用(DPCs)。这个值说明生成中断的设备(如系统时钟、鼠标、磁盘驱动器、数据通讯线、网络接口卡和其他外缘设备)的活动。这些设备通常在完成任务或需要注意时中断处理器。正常线程执行因此被中断。系统时钟通常每 10 毫秒中断处理器一次，创建中断活动的背景。这个计数值显示用上两个实例中观察到的值之间的差除于实例间隔的持续时间所得的值。 % Interrupt Time 是处理器在实例间隔期间接受和服务硬件中断的时间。此值间接表示了生成间隔的设备活动， 如系统时钟、鼠标、磁盘驱动程序、数据通讯线路、网络界面卡和其他外围设备。当这些设备完成一项任务或需要管理时，它们通常会中断处理器。中断期间，正常的线程执行会停止。多数系统时钟会每隔 10 毫秒中断处理器，产生间隔活动的背景，在间隔期间，终止正常的线程执行。此计数器显示此平均占用时间为实例时间的一部分。  Process计数器  Private Bytes 指这个处理不能与其他处理共享的、已分配的当前字节数。 Page Faults/sec 指在这个进程中执行线程造成的页面错误出现的速度。当线程引用了不在主内存工作集中的虚拟内存页即会出现 Page Fault。如果它在备用表中(即已经在主内存中)或另一个共享页的处理正在使用它，就会引起无法从磁盘中获取页。 % User Time 指处理线程用于执行使用用户模式的代码的时间的百分比。应用程序、环境分系统和集合分系统是以用户模式执行的。Windows 的可执行程序、内核和设备驱动程序不会被以用户模式执行的代码损坏。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统式保护模式之外，还使用处理边界作为分系统保护。某些由 Windows 为您的应用程序所做的操作除了出现在处理的特权时间内，还可能在其他子系统处理出现。 % Privileged Time 是在特权模式下处理线程执行代码所花时间的百分比。当调用 Windows 系统服务时，此服务经常在特权模式运行，以便获取对系统专有数据的访问。在用户模式执行的线程无法访问这些数据。对系统的调用可以是直接的(explicit)或间接的(implicit)，例如页面错误或间隔。不像某些早期的操作系统，Windows 除了使用用户和特权模式的传统保护模式之外，还使用进程边界作为分系统保护。某些由 Windows 为您的应用程序所做的操作除了出现在进程的特权时间内，还可能在其他子系统进程出现。 % Processor Time 是所有进程线程使用处理器执行指令所花的时间百分比。指令是计算机执行的基础单位。线程是执行指令的对象，进程是程序运行时创建的对象。此计数包括处理某些硬件间隔和陷阱条件所执行的代码。 Virtual Bytes 指处理使用的虚拟地址空间的以字节数显示的当前大小。使用虚拟地址空间不一定是指对磁盘或主内存页的相应的使用。虚拟空间是有限的，可能会限制处理加载数据库的能力。 Working Set 指这个处理的 Working Set 中的当前字节数。Working Set 是在处理中被线程最近触到的那个内存页集。如果计算机上的可用内存处于阈值以上，即使页不在使用中，也会留在一个处理的 Working Set中。当可用内存降到阈值以下，将从 Working Set 中删除页。如果需要页时，它会在离开主内存前软故障返回到 Working Set 中。 Page File Bytes 指这个处理在 Paging file 中使用的最大字节数。Paging File 用于存储不包含在其他文件中的由处理使用的内存页。Paging File 由所有处理共享，并且 Paging File 空间不足会防止其他处理分配内存。 I/O Data Bytes/sec 处理从 I/O 操作读取/写入字节的速度。这个计数器为所有由本处理产生的包括文件、网络和设备 I/O 的活动计数。  PhysicalDisk计数器  Avg. Disk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。 % Disk Time 指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。 Current Disk Queue Length 在收集性能数据时磁盘上当前的请求数量。它还包括在收集时处于服务的请求。这是瞬间的快照，不是时间间隔的平均值。多轴磁盘设备能有一次处于运行状态的多重请求，但是其他同期请求正在等待服务。此计数器会反映暂时的高或低的队列长度，但是如果磁盘驱动器被迫持续运行，它有可能一直处于高的状态。请求的延迟与此队列的长度减去磁盘的轴数成正比。为了提高性能，此差应该平均小于二。一个经验规则是将每一个磁盘的平均请求队列长度保持在2以下。当这个计数器的值超过了每个磁盘2时，系统将出现一个I/O极限。 Split IO/Sec 汇报磁盘上的 I/O 分割成多个 I/O 的速率。一个分割的 I/O 可能是由于请求的数据太大不能放进一个单一的 I/O 中或者磁盘碎片化而引起的。 % Idle Time 汇报在实例间隔时磁盘闲置时间的百分比。 Avg. Disk Bytes/Transfer 指在写入或读取操作时从磁盘上传送或传出字节的平均数。 Disk Read Bytes/sec 指在读取操作时从磁盘上传送字节的速率。 Disk Write Bytes/sec 指在写入操作时传送到磁盘上的字节速度。 Memory计数器  Page Faults/sec 每秒钟出错页面的平均数量。由于每个错误操作中只有一个页面出错，计算单位为每秒出错页面数量，因此这也等于页面错误操作的数量。这个计数器包括硬错误(那些需要磁盘访问的)和软错误(在物理内存的其他地方找到的错误页)。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。当进程请求一块内存但系统无法分配时发生页面错误，该值过高（与未加压时比较）可能有两方面的原因：1、 应用程序已经占用了过多内存，这可以通过增加内存量来解决。2、 应用程序的内存请求过于频繁（如：频繁地创建和销毁对象）。此时要考虑更改设计。 Committed Bytes 指以字节表示的确认虚拟内存。确认内存磁盘页面文件上保留了空间的物理内存。每个物理磁盘上可以有一个或一个以上的页面文件。这个计数器只显示上一回观察到的值；它不是一个平均值。 Available MBytes 计算机上运行的进程的可用物理内存大小，单位是千字节，而不是在 Memory\\Available Bytes 中报告的字节。它是将零的、空闲的和备用内存列表的空间添加在一起来计算的。空闲内存可随时使用; 零内存是为了防止以后的进程看到以前进程使用的数据而在很多页内存中填满了零的内存。备用内存是指从进程的工作集(它的物理 内存)移到磁盘的，但是仍旧可以重新调用的内存。 这个计数器只显示观察到的最后一个值；它不是一个平均值。当这个数值变小时，Windows开始频繁地调用磁盘页面文件。如果这个数值很小，例如小于5 MB，系统会将大部分时间消耗在操作页面文件上。 Pages/sec 指为解决硬页错误从磁盘读取或写入磁盘的速度。这个计数器是可以显示导致系统范围延缓类型错误的主要指示器。它是 Memory\\Pages Input/sec 和 Memory\\Pages Output/sec 的总和。是用页数计算的，以便在不用做转换的情况下就可以同其他页计数如: Memory\\Page Faults/sec 做比较，这个值包括为满足错误而在文件系统缓存(通常由应用程序请求)的非缓存映射内存文件中检索的页。 一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。 Commit Limit 指在不用扩展分页文件的情况下可以使用的虚拟内存的数量。这是用字节来计算的。确认的内存是指保留在磁盘分页文件上的物理内存。在每个逻辑磁盘上可以有一个分页内存。如果扩展分页文件，这个限量将相应增加。这个计数器只显示上一回观察到的值；而不是一个平均值。

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为发送和接收字节的速率，可以通过该计数器值来判断网络链接速度是否是瓶颈，具体操作方法是用该计数器的值和目前网络的带宽进行比较。

  

2008年6月16日

今天测试的时候，突然观察到服务器端的PF非常高，物理内存为2G的server，使用到的PF为1.7G。也就是说由于系统内存紧张页面文件交换频繁导致服务器端创建socket连接异常。

重启系统，保持内存正常，那么不会出现这种Error : socket0 - Connection reset by peer. Error code : 10054.

 

根据上篇日志分析的原因，知道这不是导致此问题的唯一原因，希望可以给同仁们参考

 

1. Error : socket0 - Connection reset by peer. Error code : 10054.

 网上通行的解释是：经常出现的Connection reset by peer: 原因可能是多方面的，不过更常见的原因是   ①：服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；②：客户关掉了浏览器，而服务器还在给客户端发送数据；③：浏览器端按了Stop

但是个人经过观察以及监控，服务器端并不繁忙啊。至于客户端，采用的winsockt协议，并不会去关闭浏览器啊

具体的有：

Read Error
Scenario: Mary couldn't make out what Joe was saying anymore, so she hung up rather than lose his messages (data).
A read error occurs when a server cannot successfully read from a user's client. Servers gather information from the client by text, setup, and other items.When the server receives an error when reading from a client, it then disconnects the user, resulting in a read error quit message.

Write Error
Scenario: Mary was trying to talk to Joe but didn't think she was getting through, so she hung rather than lose his messages (data).
A write error occurs when a server cannot successfully write to a user's client. When the server receives information, it usually responds with information of its own. When the server receives an error when writing to a client, it then disconnects the user, resulting in a write error quit message similar to the read error format.

Ping Timeout Error
Scenario: Mary, having been raised in a household with too many kids and always craving attention, keeps asking to make sure that Joe is still on the line and listening. If he doesn't reply fast enough to suit her, she hangs up.
Servers automatically ping users at a preset time. The reason for this is to ensure the client is still connected to the server. When you see "PING? PONG!" results in your status window, it means the server has pinged your client, and it has responded back with a pong to ensure the server that you are still connected. When this does not happen and you disconnect without the server's knowledge, the server will automatically disconnect the user when it does not receive a response, resulting in a ping timeout. Ping timeouts occur to EVERYONE.

Broken pipe Error
Scenario: Mary had picked up a sticky note with a message she needed to relay to Joe, but somehow between her hand and her mouth, the message got misplaced. Mary was trying to talk to Joe but didn't think she was getting through, so she hung up rather than lose his messages (data).
A broken pipe error occurs when the server knows it has a message but can't seem to use its internal data link to get the data out to the socket.

Miscellaneous
Scenario: Lots of other reasons; perhaps the operator broke in and gave Mary a message that made her doubt the validity of the call so she hung up.

情况是了解，但是具体该怎么处理呢？

    前几天进行了监控系统性能测试的相关工作。现在总结一下，并写下感受。

    第一次看到这个系统感觉很怪，他有两级服务器，一台是web 服务器，部署有java应用，一台所谓的二级服务器，也部署有java代码，同时两台机器也都部署有ms sqlserver。web服务器负责提供web访问支持，二级服务器定期收集设备上报的状态。两台服务器还要定期的同步数据，web服务器还要实现定期告警

   这与我先前接触到的系统有很大不同，起码理解上都有问题。所以更要深入研究他们的需求了。首先了解需要加入性能测试的功能范围。

1.  收集设备状态是个什么概念？即二级服务器定期收集所有数据库内有的atm的设备状态，处理，存储。当然不是主动收集，而是设备自动上报，时间间隔是5分钟。也就是说到5分钟定时到期的时候，设备会自动上报状态，当然是以约定好的报文的形式。那么操作很简单。创建连接、发送报文、关闭连接。当然，一台设备是不会给服务器产生任何压力的，毕竟报文size很小，毕竟时间有间隔，不是频繁操作。但是如果设备达到一定规模，比如5000台，比如10000台，这个时候就是比较可观的了。
2. 告警怎么实现的？原来设备上报状态，二级服务器进行处理、存储，通过web服务器sqlserver的作业定时同步一个表，那么这个表包含什么呢？包含设备上报的状态。然后，web服务器上的告警定期检查状态，如果触发了告警，则push。
3. 大规模数据操作。包括各种日结交易，各种导入交易。

事实证明，如果将范围分解清楚，做起事情来是会事半功倍的。攻克了这些理解难点，那么我大概有了这么一个测试计划。既然我们的目标是真实模拟实际情况，看现有server设备现有系统版本确认系统是否能够正常响应。

    我需要模拟状态上报，另外还要加上很多web操作，还有日结操作。最终场景是，这次操作都存在的情况下，系统是否能够正常响应，不会出现堆积，丢失，无法响应的状况。

    模拟状态上报。我采取了winsockt协议，其实好简单，就是一个简单creat sockt；send data；然后clost socket。难点到在于data.ws数据的组织。

     脚本如下：

#include "lrs.h"

Action()
{

//定义了一个int型的变量rca，主要是为了调试脚本时确认soket连接是否建立成功。

/*

我分别加了3个transction，主要是为了确认如果大并发的情况下，是否会造出交通拥堵。事实证明这是非常有效的，因为我从我的测试监控平台可以看到，很明显的压力大服务器资源 不够的情况下，申请建立一个socket连接也是非常困难的。

*/
int rca;

lr_start_transaction("CreatSocket");

rca =lrs_create_socket("socket2", "TCP", "LocalHost=0", "RemoteHost=*.*.*.8:6030", LrsLastArg);

lr_end_transaction("CreatSocket", LR_AUTO);

if (rca==0)
lr_output_message("Socket is succesfully created!");

lr_start_transaction("SendMessage");

lrs_send("socket2", "buf0", LrsLastArg);

lr_end_transaction("SendMessage", LR_AUTO);

//关闭连接

lr_start_transaction("CloseSocket");

lrs_close_socket("socket2");

lr_end_transaction("CloseSocket", LR_AUTO);

//think_time是为了实现5分钟上报的定时。
lr_think_time(300);
    return 0;

}

而我的data.ws则如下：

采用了两个参数化。一个TerminalNum来标志设备，多少列即多少台设备。一个是读卡器状态，是我用来控制每台报文insert的规模以及触发告警使用的。

;WSRData 2 1

send buf0 319
 "0319020100<TerminalNum>000000<ReadCareStatus>0000000000000O0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"

-1a

    这是我前段时间不在项目的时候对公司测试组进行的性能测试培训讲义。
    写的不是特别好，依托的基本工具是loadrunner，注重基本概念理解，参考了牛人们的经验并糅合个人理解，比较详细的解释了如何组织一个性能测试。并且由于时间原因，有些章节没有铺开讲解。
    现发表出来和大家共享，欢迎大家提问交流
   

    昨天进行了测试前脚本的调试。
    在我运行并发用户2500个的时候，controller发生了一个error，即“负载生成器当前正在运行该类型的最大数量的 Vuser”。当时很是摸不着头脑。
    由于我的客户端是xp+sp2，采取的协议的winsocket.思路很简单，就是模拟一个客户端给一个server定时发一个格式已经定义好的报文，编辑脚本时候的测试都是通过的。结果在运行大并发的时候出了此错。
    开始的时候担心是不是xp系统对与建立socket连接是否有限制。后来实在找不着相关的依据。就又回头来看错误信息。
    结果发现了刚刚忽视的Message Code 84401；查找帮助文件得到以下故障点描述以及修复操作步骤。
英文原文如下：
Check that the number of Vusers that you have assigned to run in the scenario does not exceed the number of Vusers that you are licensed to run. If it does, reduce the number of Vusers assigned in the scenario.
Check the number of Vusers defined for the load generator: In the Controller, open the Load Generators dialog box (Scenario > Load Generators), and click Details. Click the Vuser Limits tab to view the maximum number of Vusers set for each Vuser type. Increase this number if necessary (provided you have additional licensed Vusers), or reduce the number of Vusers defined in the scenario goal.
翻译如下：
检查你计划在场景中运行的VU的数量是否超过你的license允许运行的VU的数量。
如果超过了，则需要减少在场景中分配的VU个数。
如果未超过，则检查负载生产前定义的VU数量：
   在controller中，打开负载生成器会话窗体（场景——>负载生成器），然后点击详细信息。继而点击Vuser Limits标签来查看为各种类型VU设置的最大数目。必要的话增大这个数目（前提是你有得到许可license的VU），或者在场景目标中减少VU运行的数量。

    并且奉上具体设置界面截图，希望对大家有些帮助。