VSTF-Performance Testing

VSTF-Performance

http://msdn.microsoft.com/en-us/library/ms182561(v=VS.90).aspx

Set up Performance Environment via VSTF Wizard:

1. Create a Project and Add load test

 

2. 设置Scenario的名字和thinking time

 

3.设置用户的load的方式，普通load和递增load两种

 

4.  设置Test Mix，主要是request的分配问题，一般默认第一种

 

5．在第4步，选择第一种Test Mix Model后，选择每个API分配的负载，也就request的比重，一般来说一些查询API分配比重多一些。

 

6. 设置网络连接方式，一般LAN是主要的，如果是手机产品或者无线网络产品，估计要分配蓝呀，3G等等

 

7． Counters，对不同的机器设置不同的counter。（根据test plan设置）例如Application这个counter下包含CUP，Memory的性能情况

 

8

设置系统load的时间。根据Test plan设置不同时间，1h，10h或者10ds等等。

Sampling rete设置的是数据采样的间隔。这个主要取决于整个test duration time. 如果是24小时，那我们可以设置1分钟一采样 ，如果2小时，估计就要5秒钟了。Sampling rate的时间越短，最后得到的测试数据就会越大。

Save log on test failure一般设置成true，因为我们需要对错误数据进行分析。

Validation Level分为高中低，越高要求测试结果要越 接近期待结果，否则给与failure的report。

 

Load下面有三个节点

·        Scenario

 设置测试场景:  建立自动化测试用例，设定用户数量，load matrix的方式和比例

·        Counter Set

设置监控实体，（产生的测试报告就是关于这些counter的）

Controller Computer: 控制agent，并且自己可以作为agent，分发任务给agent

Agent Computer: 接受controller的指令，提交request （可以是一个虚拟机或者实体机器，模拟客户端, 下载安装一个VSTF agent插件，这个agent就可以和Controller通讯了。在一个性能测试的环境中，可以有多个agent，以此模拟分布式的网络环境。 Controller和Agent也是性能测试里面的比较通用概念.）

一般情况下，默认的counter有：

 

但是基于IIS Server + DB架构的WCF项目，通常我们会加上ADO.NET, 这个名字是根据需要自己命名的

 

 

IIS server 和DB server将会监视不同的counter。

 

 

其中T3CISFSQA1SPS2 是 IIS server.(Counter set： ADO.NET / APPLICATON/ .NET APPLICATOIN/ IIS);

 T3CISFSQA1DX1是odyssey DB server，TK3PQOESGCDB01是GC server。(Counter set： SQL)

 

Running setting

 

这部分主要设置性能测试持续时间，采样时间间隔。用户数量则在Scenario中设置。

可以设置不同的Running setting. 例如持续1小时的性能测试，持续1天的性能测试，持续一周的性能测试等等。当然要根据不同的时间长度，设置不同的采样时间间隔Sampling rate；

Test iteration’s description:  Type the number of tests to run during this load test(after the completion of the warm-up period.)

还有一种情况，你想在不同环境下进行性能测试，所有的场景和监视实体是一样的，你只需要添加新的要监视的机器就可以了。

 

可以选择其中一个，然后右键Set Active

以上就是一个完整的性能测试的构架。

如果你觉的上面的构架不满足你的实际测试需求，你建立新的load test，设置不同的用户数量。

例如odyssey项目就根据20,40,60,100个用户分别建立的不同的性能测试框架，每个性能测试可以自己不同的构架参数。

Performance Counter （性能计数器） 在性能测试中的应用

Performance Counter （性能计数器） 在性能测试中的应用.

VS2010的性能测试的框架实际也是调用的这个系统内核工具，去记录采集性能测试结果。

在性能测试中很重要的一部分就是监控测试执行过程中服务器的性能参数，大型商业的测试工具比如IBM RPT，HP Load Runner已经提供了完善的功能可以直接从服务器上记录保存数据，但是如果使用一些开源软件来进行测试的话就需要用其他办法来记录数据了

在Windows中微软提供了一个小工具Performance Counter（性能计数器），可以用它来进行监控和记录数据。

1.       启动Performance Counter，打开 Control  Panel ->  Administrative Tools-> Performance

（也可以从command中直接打开该工具.  Type command: Perfmon, 对于不同的操作系统，打开的界面或许略有不同。对于win7，输入上述命令后，Performance Monitor程序即被打开。）

2.        这个时候就能看到Performance Counter的主界面，并且默认选中的是 System Monitor,这样只是显示数据并不会记录下来。

 

3.       在左边的树状菜单中选择 Performance Logs and Alerts -> Counter Logs

4.        在右边的窗口中就能看到一个默认的Counter，名字是System Overview.

5.       右键点击空白处，在右键菜单中选择 New Log Setting…,输入名字，建议和被监控的服务器同名，便于区分。

6.       属性对话框中选择 General 标签，点击 ‘Add Counters’,添加所需要的Counter，这里要注意，尽量不要选择 ‘Use local computer counters’ 单选项,而是选择 ‘Select Counters from computer’ 否则一旦想把现在所建的监控项目移动到其他机器上就是一个比较痛苦的事情了。

7.       在’Log Files’标签中设置记录文件的类型，建议选择’Text File (Comma delimited)’, 这样以后就可以用Excel来分析生成的数据。

8.        根据自己的需要设置’Log Files’,’Schedule’标签页中的其他内容。

9.        点击’Ok’,完成编辑。

10.   选择刚才新建的Counter，点击工具栏上的“开始”按就就可以开始记录了。

11.   可以在Counter上右键，然后选择’Save Settings as’,把Counter保存为html，这样就可以在其他导入使用。

注意事项：

1.       如果有多台服务器，最好是把所有的Counter集中一台机器上，便于统一管理。

2.       两个有用的CMD命令，可以写一个bat来统一开始停止所有的counter：

Logman Start [countername] - 启动本机上指定名字的Counter

Logman Stop [countername] -停止 本机上指定名字的Counter

入门的内容就这么多了，总的来说Performance  Counter 还是一个很不错的小工具，其他的内容可以自己摸索，很容易理解。

PS 其实不只可以用于测试，打游戏的时候也可以用来监控机器是否够用，瓶颈出在哪里。

分析性能测试结果, 找出性能瓶颈

通常性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

分析原则：

• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

• 查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

• 分段排除法 很有效

分析的信息来源

1.        根据场景运行过程中的错误提示信息

2.        根据测试结果收集到的监控指标数据

错误提示分析：

案例1

Ø  错误：

·         Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection

·         Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely

Ø  分析：

·         应用服务死（小用户时：程序上的问题。程序上处理数据库的问题）

·         应用服务没有死 （应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

·         数据库的连接 (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

案例2：

Ø  错误:

·         Page download timeout (120 seconds) has expired

Ø  分析：

可能是以下原因造成

·         应用服务参数设置太大导致服务器的瓶颈

·         页面中图片太多

·         在程序处理表的时候检查字段太大多

监控指标数据分析

1.       最大并发用户数

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

    在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2.       业务操作响应时间

·         分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

·         细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

·         如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3.       服务器资源监控指标

Ø  内存：

·         UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

·         Windows资源监控中，如果Process/Private Bytes计数器和Process/Working Set计数器的值在长时间内持续升高，同时Memory/Available bytes计数器的值持续降低，则很可能存在内存泄漏。

·         内存资源成为系统性能的瓶颈的征兆:

a.       很高的换页率(high page out rate);

b.      进程进入不活动状态;

c.       交换区所有磁盘的活动次数可高;

d.      可高的全局系统CPU利用率; 

e.      内存不够出错(out of memory errors)

Ø  处理器

·         UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 

·         合理使用的范围在60%至70%。

·         Windows资源监控中，如果System/Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

·         CPU资源成为系统性能的瓶颈的征兆: 

a.       很慢的响应时间(slow response time) 

b.      CPU空闲时间为零 (zero percent idle CPU) 

c.       过高的用户占用CPU时间(high percent user CPU) 

d.      过高的系统占用CPU时间(high percent system CPU) 

e.      长时间的有很长的运行进程队列(large run queue size sustained over time)

Ø  磁盘I/O

·         UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

·         Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

·         I/O资源成为系统性能的瓶颈的征兆 :

a.       过高的磁盘利用率(high disk utilization) 

b.      太长的磁盘等待队列(large disk queue length) 

c.       等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 

d.      太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 

e.      过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 

f.        太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4.       数据库服务器

Ø  SQL Server数据库

·         SQL Server资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。

·         如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 

·         Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

·         Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Ø  Oracle数据库：

·         如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

·         快存（共享SQL区）和数据字典快存的命中率： 

select(sum(pins-reloads))/sum(pins) from v$librarycache; 

select(sum(gets-getmisses))/sum(gets) from v$rowcache; 

自由内存： select * from v$sgastat where name=’free memory’; 

·         如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

·         缓冲区高速缓存命中率：

select name,value from v$sysstat where name in (’db block gets’,

‘consistent gets’,'physical reads’) ;

Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

Ø  如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况 ：

select name,value from v$sysstat where name = ‘redo log space requests’ ;

Ø  如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

内存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’

注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。