-
监控windows资源说明
2009-03-26 09:37:10
1、通用指标（指Web应用服务器、数据库服务器必需测试项）:
* ProcessorTime: 指服务器CPU占用率，一般 平均达到70%时，服务就接近饱和；
* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
* Physicsdisk Time : 物理磁盘读写时间情况；
2、Web服务器指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；
3、数据库服务器指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Butter Cache hit ：数据库Cache的命中情况； -
性能测试指标与性能计数器
2009-03-26 09:33:26
性能测试指标与性能计数器2008/12/04 20:18
【IT168技术文章】今天，我先把我整理的一些计数器及其阈值要求等贴出来，这些计数器是针对我对windows操作系统，C/S结构的sql server数据库及WEB平台.net产品测试时的一些计数器；大家可以继续补充，作过unix平台上oracle数据库测试及J2EE架构及WEBLOGIC方面测试的朋友，也希望把自己使用的计数器贴出来，让大家分享。性能测试的响应时间：
确立响应时间的原则：
2：2秒钟用户会觉得是一个很好的体验。
5：5秒钟用户可能会觉得差了一点，还行，比较好。
10：10秒钟是用户所能承受的最大极限。
一physicalDisk
1.disk time 该值大就有问题
若%Disk Time值较大，而Processor\Privileged Time的值适中，则可判断存在磁盘问题。
若Processor\Privileged Time较大，持续超过80%，则可能是内存泄漏。
2.avg disk sec/transfer 该值超过60，磁盘存在问题
3.disk queue length
二Processor (分析cpu)
1.processor time （Processor_Total）<85%
2.privileged time (（Processor_Total）)
3.use time(（Processor_Total）)
4. processor queue length<2
5.interrupts/sec
processor time=%privileged Time +%user Time
其次查看每个CPU的User Time计数器的值。该值体现在是消耗CPU的数据库操作,
若应用服务器的%User Time值较大，可以考虑是否能通过算法优化等方法降低这个值。
若数据库服务器的%User Time值较大，可考虑对数据库系统进行优化。
System\Processor Queue Length计数器的值。当该值大于CPU数量的总数+1时，说明存在处理器方面的问题。
如果 （Processor XXX）:某进程独占cpu
1.processor time （Processor XXX）<85%
2.privileged time (（Processor_XXX）)
3.use time(（Processor_XXX）)
Thread:
ContextSwitches/Sec
如果5000*CPU<次数<15000*CPU,而网络吞吐量低，说明CPU忙于切换线程，CPU利用率高。
三内存方法
Available Mbytes （可用内存率不少于15%）
CommittedBYtes （内存泄漏监控）
1.pages/sec 正常值<２０ 从磁盘读取或写入的页面数
pages Read/sec<５ 越低越好，此值过大表明是磁盘读而不是缓存读
pages Faults/sec、 页面错误，表明数据不能再内存中立即使用
Cacge Bytes<50% 可用物理内存
2.pool nonpaged Bytes 内核模式
Process（XXX）
Private Bytes 某进程独占的内存字节
Working Set 某进程使用的内存页
Handle Count 句柄数
.pool nonpaged Bytes 内核模式
四system
1. threads
好了，先说这些了，希望通过这个专题，最终能让大家对自己的测试结果进行分析。
Memory: 内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
Available Mbytes:可用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。
page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
page read/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5. 越低越好。大数值表示磁盘读而不是缓存读。
由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器：
Physical Disk\ % Disk Time
Physical Disk\ Avg.Disk Queue Length
例如，包括 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将 Physical Disk\ Avg.Disk sec/Transfer 和 Memory\ Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。
Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。
Cache Bytes：文件系统缓存（File System Cache），默认情况下为50%的可用物理内存。如IIS5.0 运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视 Memory\ Available Bytes 和 Memory\ Committed Bytes，以观察内存行为，并监视您认为可能在泄露内存的进程的 Process\Private Bytes、Process\Working Set 和Process\Handle Count。如果您怀疑是内核模式进程导致了泄露，则还应该监视 Memory\Pool Nonpaged Bytes、Memory\ Pool Nonpaged Allocs 和 Process(process_name)\ Pool Nonpaged Bytes。
Pages per second :每秒钟检索的页数。该数字应少于每秒一页。
Process：
%Processor Time: 被处理器消耗的处理器时间数量。如果服务器专用于sql server，可接受的最大上限是80-85%
Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。
%Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。
此外，跟踪计算机的服务器工作队列当前长度的 Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。
% DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
Thread
ContextSwitches/sec: (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。
Physical Disk:
%Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。
Avg.Disk Queue Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘。
Average Disk Read/Write Queue Length:指读取(写入)请求(列队)的平均数。
Disk Reads(Writes)/s: 物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
Average Disksec/Read: 指以秒计算的在此盘上读取数据的所需平均时间。
Average Disk sec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。
Network Interface：
Bytes Total/sec :为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较
SQLServer性能计数器：
Access Methods(访问方法) 用于监视访问数据库中的逻辑页的方法。
Full Scans/sec(全表扫描/秒) 每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及S Q L查询是否可以被优化。
Page splits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。
Buffer Manager(缓冲器管理器)：监视 Microsoft® SQL Server? 如何使用： 内存存储数据页、内部数据结构和过程高速缓存；计数器在 SQL Server 从磁盘读取数据库页和将数据库页写入磁盘时监视物理 I/O。 监视 SQL Server 所使用的内存和计数器有助于确定： 是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。 是否可通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
SQL Server 需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理 I/O 会耗费大量时间。尽可能减少物理 I/O 可以提高查询性能。
Page Reads/sec：每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理 I/O 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。
Page Writes/sec (.写的页/秒) 每秒执行的物理数据库写的页数。
Buffer Cache Hit Ratio. 在“缓冲池”（Buffer Cache/Buffer Pool）中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自 SQL Server 实例启动后对高速缓存的查找总数。经过很长时间后，这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。通常，可以通过增加 SQL Server 可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定，但比率最好为90% 或更高。增加内存直到这一数值持续高于90%，表示90% 以上的数据请求可以从数据缓冲区中获得所需数据。
Lazy Writes/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。
Cache Manager(高速缓存管理器) 对象提供计数器，用于监视 Microsoft® SQL Server? 如何使用内存存储对象，如存储过程、特殊和准备好的 Transact-SQL 语句以及触发器。
Cache Hit Ratio(高速缓存命中率，所有Cache”的命中率。在SQL Server中，Cache可以包括Log Cache，Buffer Cache以及Procedure Cache，是一个总体的比率。) 高速缓存命中次数和查找次数的比率。对于查看SQL Server高速缓存对于你的系统如何有效，这是一个非常好的计数器。如果这个值很低，持续低于80%，就需要增加更多的内存。
Latches(闩) 用于监视称为闩锁的内部 SQL Server 资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。
Average Latch Wait Ti m e ( m s ) (平均闩等待时间(毫秒)) 一个SQL Server线程必须等待一个闩的平均时间，以毫秒为单位。如果这个值很高，你可能正经历严重的竞争问题。
Latch Waits/sec (闩等待/秒) 在闩上每秒的等待数量。如果这个值很高，表明你正经历对资源的大量竞争。
Locks(锁) 提供有关个别资源类型上的 SQL Server 锁的信息。锁加在 SQL Server 资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。例如，如果一个排它 (X) 锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。尽可能少使用锁可提高并发性，从而改善性能。可以同时监视 Locks 对象的多个实例，每个实例代表一个资源类型上的一个锁。
Number of Deadlocks/sec(死锁的数量/秒) 导致死锁的锁请求的数量
Average Wait Time(ms) (平均等待时间(毫秒)) 线程等待某种类型的锁的平均等待时间
Lock Requests/sec(锁请求/秒) 每秒钟某种类型的锁请求的数量。
Memory manager:用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视 SQL Server 实例所使用的内存有助于确定：
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQL Server 必须从磁盘检索数据。
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或 SQL Server 内部结构来提高查询性能。
Lock blocks:服务器上锁定块的数量，锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
Total server memory：sql server服务器当前正在使用的动态内存总量.
监视IIS需要的一些计数器
Internet Information Services Global:
File Cache Hits %、File CacheFlushes、File Cache Hits
File Cache Hits %是全部缓存请求中缓存命中次数所占的比例，反映了IIS 的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而File Cache Hits是文件缓存命中的具体值，File CacheFlushes 是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较File Cache Hits 和File Cache Flushes 可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考IIS 的设置ObjectTTL 、MemCacheSize 、MaxCacheFileSize）
Web Service:
Bytes Total/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
Connection Refused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
Not Found Errors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）
-
WEB性能测试研究
2008-08-12 11:41:04
一、引言随着网络技术的迅速发展，尤其是WEB及其应用程序的普及，各类基于WEB的应用程序以其方便、快速，易操作等特点不断成为软件开发的重点。与此同时，随着需求量与应用领域的不断扩大，对WEB应用软件的正确性、有效性和对WEB服务器等方面都提出了越来越高的性能要求，对WEB应用程序进行有效的系统的测试也逐渐成为人们研究的重要课题。
目前可以见到各种WEB服务器平台，然而根据Mereury的研究报告，98%的WEB服务器都没能达到人们所期望的性能，平均只能发挥人们所期望性能的1/6左右。WEB性能测试能够确定影响WEB服务器性能的关键因素，从而可以有针对性地进行分析和改进，避免WEB服务器研究和优化过程中的盲目行为；同时，它也是选取不同的WEB服务器的重要参考。
随着WEB应用程序使用越来越广泛，针对其性能测试的要求也越来越多，然而由于WEB程序综合了大量的新技术，诸如HTML、JAVA、Javascrīpt、VBscrīpt等，同时它还依赖很多其它的因素，比如Link、Database、Network等，使得WEB应用程序测试变得非常复杂。例如：WEB压力测试是评价一个WEB应用程序的主要手段，它的测试就是一个代表性的方面。
WEB应用程序的测试有别于传统软件的测试，它有其自身的特点。下面我们进行比较深入的讨论。
二、WEB测试技术
（一）WEB应用程序体系结构
WEB应用程序采用B/S结构，它是伴随着Internet技术的不断进步，由C/S结构改进和发展起来的新型体系结构。在这种结构下，用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑则在服务器端实现，形成所谓3tier结构。B/S结构利用不断成熟和普及的浏览器技术实现原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。这种结构更成为当今应用软件开发的首选体系结构，目前最流行的mi?鄄crosoft.net也是在这样一种背景下被提出来的架构。
传统的软件一般采用C／S结构，此结构把数据库内容放在远程的服务器上，而在客户机上安装相应软件。C／S软件一般采用两层结构，C／S结构在技术上很成熟，它的主要特点是交互性强、具有安全的存取模式、网络通信量低、响应速度快、利于处理大量数据。但是该结构的程序是针对性开发，变更不够灵活，维护和管理的难度较大。
（二）WEB测试的内容与目的
在很多时候我们都把测试的目的定位为寻找软件的BUG，而且是尽可能的找出BUG来，而测试人员所做的事情就是找软件的毛病，只要找出毛病就可以了，这样很容易带了一系列的问题。比如测试人员给某网站做测试，并递交了一份简单的测试报告：“当100用户共同按某提交按钮时，发生大量的提交失败”。对于测试人员来说，他已经完成了他自己的任务，找出了BUG，但是，这样的测试报告对于开发人员和项目管理者却毫无用处。报告中并未提及造成提交失败的原因，是硬件资源不足、网络问题、支撑软件参数设置错误还是应用开发问题等等。
测试的目的是证伪，但不能片面的理解为简单的找不BUG就可以了。软件测试应该经历以下四个步骤：
1．测试人员描述发现的问题（找到bug）；
2．测试人员详细阐明是在何种情况下测试发现的问题，包括测试的环境、输入的数据、发现问题的类型、问题的严重程度等情况；
3．测试人员协同开发人员一起去分析BUG的原因，找出软件的缺陷所在；
4．测试人员根据解决的情况进行分类汇总，以便日后进行软件设计的时候提供参考，避免以后出现类似软件缺陷。
（三）制定WEB测试计划
当我们明确了测试的目的之后，真正开始针对一个WEB应用程序进行测试的时候，我们需要制定一套详细的测试计划，这样才能顺利的完成所有的测试内容，计划的内容归纳为以下几步：
1．首先对被测的WEB应用程序进行需求分析，即对你所做的测试做一个简要的介绍，包括描述测试的目标和范围，所测试的目标要实现一个什么样的功能，总结基本文档，主要活动。
2．写出测试策略和方法，这里包括测试开始的条件，测试的类型，测试开始的标准以及所测试的功能，测试通过或失败的标准，结束测试的条件，测试过程中遇到什么样的情况终止和怎么处理后恢复等。
3．确定测试环境的要求（包括软件和硬件方面），选择合适的测试工具。
4．主要针对你测试的行为，描述你测试的细节，包括测试用例列表，进度表，错误等级分析，对测试计划的总结，和在测试过程会出现的风险分析等。
（四）测试的类型
WEB测试的类型包括内容测试、界面测试、功能测试、性能测试、兼容性测试、安全性测试等情况。内容测试、界面测试和兼容性测试都比较简单，在此不再细谈。
WEB的功能测试与传统的软件测试区别不大，主要是在连接测试方面有点区别，数据的传递方面会稍微复杂点。由于WEB软件都是采用B/S结构，客户端所需的服务都是由服务器提供的，所以主要是测试服务器上软件运行的性能。WEB应用程序的测试包括客户端连接服务器速度方面的测试和压力测试这两方面，性能测试的步骤：
第一，分析产品结构，明确性能测试的需求，包括并发、极限、配置和指标等方面的性能要求，必要时基于LOAD测试的相同测略需同时考虑稳定性测试的需求。
第一，分析应用场景和用户数据，细分用户行为和相关的数据流，确定测试点或测试接口，列示系统接口的可能瓶颈，一般是先主干接口再支线接口，并完成初步的测试用例设计。
第三，依据性能测试需求和确定的测试点进行测试组网设计，并明确不同组网方案的重要程度或优先级作为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。
第四，完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。
第五，确定采用的测试工具。
第六，进行初验测试，以主干接口的可用性为主，根据测试结果分析性能瓶颈，通过迭代保证基本的指标等测试的环境。
第七，迭代进行全面的性能测试，完成计划中的性能测试用例的执行。
第八，完成性能测试评估报告。
