发布新日志

  • 性能测试使用的一些计数器 (2)

    2008-12-16 14:55:10

    性能测试使用的一些计数器 2

    Memory object

    Memory object记录了当前系统中整体内存的统计信息。

    Available Mbytes Committed Bytes

    Available Mbytes记录了当前剩余的物理内存数量。Committed Bytes记录了所有进程commit的内存数量。结合两个计数器可以观察到:

    1) 两者相加可以粗略估计系统总体可用内存多少,便于估计物理配置

    2) Available Mbytes少于100MB的时候,说明系统总体内存吃紧,会影响到整个系统所有进程的性能。应该考虑增加物理内存或者监察内存泄露

    3) 通过比较Process\Private BytesVirtual Bytes,便于进一步确认是否有内存泄露,判断内存泄露是否是某一单个进程导致

    Free System Page Table EntriesPool Paged BytesPool Paged Bytes

    这三个计数器可以衡量核心态空闲内存的数量。特别是当使用/3GB开关后,核心态内存地址被压缩,容易导致核心态内存不足,继而引发一些非常奇怪的问题。可以参考前面提到的文章:

    .NET CLR Memory object

    .NET CLR Memory object记录了CLR进程中跟CLR相关的内存信息。该类别下的所有计数器都很有意思,而且意思也非常直接。建议用一个例子程序进行测试和研究。下面是两个最常用的计数器

    Bytes in all heaps

    Bytes in all heaps记录了上次GC发生时候所统计到的,进程中不能被回收的所有CLR object占用的内存空间。该计数器不是实时的,每次GC发生的时候该计数器才更新。跟同一进程的Process\Private bytes比较,可以区分出managed heapnative memory的变化情况。对于memory leak,便于区分是managed heapleak还是native memoryleak

    %Time in GC

    %Time in GC记录了GC发生的频繁程度。一般来说15%以内算比较正常。当超过20%说明GC发生过于频繁。由于GC不仅仅带来很高的CPU开销,还需要挂起目标进程的CLR线程,所以高频率GC是非常危险的。通过跟CPU利用率和其他性能指标比较,往往能够看出GC对性能的影响。高频率的GC往往因为

    1) 负载过高

    2) 不合理的架构,对内存使用效率不高

    3) 内存泄露,内存分片导致内存压力

    如果目标程序是ASP.NET,在ASP.NET开头的object中,下面这些计数器对于测量ASP.NET的性能非常有用。由于不少计数器存在于多个object类别中,下面只列出具体的计数器名字,而不去对应到具体的object:

    Application Restarts

    Application Restarts记录了ASP.NET Application Domain重启的次数。导致ASP.NET appDomain重启的原因往往是虚拟目录中被修改。比如修改了web.config文件,或者防毒程序对虚拟目录进行扫描。通过该计数器可以观察是否有异常的重启现象

    Request Execution time

    Request Execution time记录了请求的执行时间,是衡量ASP.NET性能的最直接参数。通过该计数器的平均值来衡量性能是否合乎预期值。需要注意的地方是由于Windows并非实时系统,所以不能用峰值来衡量整体性能。比如当GC发生的时候,请求执行时间肯定都要超过GC的时间。所以平均值才是有效的标准

    Request Current

    Request Current记录了当前正在处理的和等待处理的请求。最理想的情况是Request Current等于CPU的数量,这说明请求跟硬件资源能并发处理的能力恰好吻合,硬件投资正运行在最优状态。但是一般说来,当负荷比较大的时候,Request Current也随着增高。如果Request Current在一段时间内有超过10的情况,说明性能有问题。注意观察这个时候对应的CPU情况和其他的资源。如果CPU不高,很可能是程序中有blocking发生,比如等待数据库请求,导致请求无法及时完成。

    Request/second

    Request/second计数器记录了每秒钟到达ASP.NET的请求数。这是衡量ASP.NET负载的直接参数。注意观察Request/second是否超过程序的预期吞吐量。如果Request/Second有突发的波动,注意看是否有拒绝服务攻击。通过把Request/second,Request Current, Request Execution time和系统资源一起比较,往往能够看出来ASP.NET整体性能的变化和各个因素之间的影响

    Request in Application Queue

    ASP.NET没有空余的工作线程来处理新进入的请求的时候,新的请求会被放到Application Queue中。当Application Queue堆积的请求也超过设定数值的时候,ASP.NET直接返回503 Server too busy错误,同时丢弃该请求。所以正常情况下,Request in Application Queue应该总为0,否则说明已经有请求堆积,性能问题严重

  • 性能测试使用的一些计数器(1)

    2008-12-16 14:42:25

    性能测试使用的一些计数器 1

    l  Process object下的所有计数器

    l  Processor object下的所有计数器

    l  System object下的所有计数器

    l  Memory object下的所有计数器

    l  如果是.NET程序,观察 .NET 开头的object下的所有计数器

    l  如果是ASP.NET,观察 ASP.NET 开头的object下的所有计数器

    具体性能计数器分析描述

    Process object

    Process object中的计数器可以针对目标进程分析内存,CPU,线程数目和handle数目。首先要确定目标进程,然后分析目标进程的下面一些计数器:

    % Processor Time

    该计数器是该进程占用CPU资源的指标。当进程繁忙的时候,CPU平均占用率应该在80%以内。如果超过该数值,程序可以认为发生了high CPU的问题。另外一种问题是CPU波动幅度大。虽然平均占用率不高,但是上下跳动频繁。在某一个短时间段里面,会有连续高CPU的情况出现。

    Handle Count

    该计数器记录了当前进程使用的kernel object handle数量。Kernel object是重要的系统资源。当程序进入稳定运行状态的时候,Handle Count数量也应该维持在一个稳定的区间。如果发现Handle Count在整个程序周期内总体趋势是连续向上,可以考虑程序是否有Handle Leak

    ID Process

    该计数器记录了目标进程的进程ID。你可能觉得奇怪,ID有什么好观察的。进程ID是用来观察程序是否有重启发生。比如ASP.NET工作进程可能会自动回收。由于进程名都相同,只有通过进程ID来判断是否进程有重新启动现象。如果ID有变化,考虑程序是否发生崩溃或者Recycle

    Private Bytes

    该计数器记录了当前通过VirtualAlloc API CommitMemory数量。无论是直接调用API申请的内存,被Heap Manager申请的内存,或者是CLR managed heap,都算在里面。跟Handle Count一样,如果在整个程序周期内总体趋势是连续向上,说明有Memory Leak

    Virtual Bytes

    该计数器记录了当前进程申请成功的用户态总内存地址,包括DLL/EXE占用的地址和通过VirtualAlloc API ReserveMemory Space数量,所以该计数器应该总大于Private Bytes。一般来说,Virtual BytesPrivate Bytes的变化大致一致。由于内存分片的存在, Virtual BytesPrivate Byes一般保持一个相对稳定的比例关系。当Virtual BytesPrivate Bytes的比例关系大于2的时候,程序往往有比较严重的内存地址分片。

    Processor object

    Processor object记录系统中芯片的负载情况。由于普通程序并不刻意邦定到某个具体CPU上执行,所以在多CPU机器上观察Total Instance也就足够了

    % Processor Time

    该计数器跟Process下的% Processor Time的意义一样,不过这里记录的是所有进程带来的芯片,而不是针对具体某一个进程。通过把这个计数器跟Process下的同名计数器一起比较,就能看出系统的高CPU问题是否是由于单一的某个进程导致的

    System object

    System object记录系统中一个整体的统计信息。所以不区分Instance. 通过比较System object下的counter和其他counter的变化趋势,往往能看出一些线索

    Context Switch/sec

    Context Switch标示了系统中整体线程的调度,切换频率。线程切换是开销比较大的操作。频繁的线程切换导大量CPU周期被浪费。所以看到高CPU的时候,一定要跟Context Switch一起比较。如果两者有相同的变化趋势,高CPU往往是由于contention导致的,而不是死循环。

    Exception Dispatches/sec

    Exception Dispatches表示了系统中异常派发,处理的频繁程序。跟线程切换一样,异常处理也需要大量的CPU开销。分析方法跟Context Switch雷同。

    File Data Operations/sec

    File Data Operations记录了当前系统中磁盘文件读写的频繁程度。通过观察该计数器跟其他性能指标的变化趋势,通常能够判断磁盘文件操作是否是性能瓶颈。类似的计数器还有Network Interface\Bytes total/sec

     

  • Windows性能监视器的使用

    2008-12-16 14:40:43

    Windows性能监视器的使用

    Windows性能监视器

    以下用Winxp中的“Windows性能监视器”为例说明:

    打开控制面板->管理工具->性能->性能日志和警报,如下图所示:

    方法1:动态监视

    点击右键后,选择“添加计数器”如下图所示:

     

    添加计数器窗口中,选择性能对象为“Processor” 其它设置为默认设置;设置完毕,点击添加按钮,关闭窗口,即可实时监视选中的参数。

    方法2:计数器日志跟踪

    打开控制面板->管理工具->性能->性能日志和警报->计数器日志->新建日志设置

    设置新建日志名“Test_guok”;

    设置日志监视的对像和计数器,如设置性能对像“Processor”,列表选择计数器“% Processor Time

    备注:“% Processor Time 指处理器用来执行非闲置线程时间的百分比。计算方法是,测量范例间隔内非闲置线程活动的时间,用范例间隔减去该值。(每台处理器有一个闲置线程,该线程在没有其他线程可以运行时消耗周期)。这个计数器是处理器活动的主要说明器,显示在范例间隔时所观察的繁忙时间平均百分比。这个值是用 100% 减去该服务不活动的时间计算出来的。

    设置日志文件,如“日志文件类型”,选择“文本文件(逗号分隔)”;

    备注:性能日志和警报以逗号分隔或制表符分隔的格式收集数据,以便容易导入电子表格程序,为后面的数据分析做准备,所以启用此方式!

    设置计划,如时间按下面所列出

    设置成功,确认后如下图所示:

     

    数据分析

    C:/ PerfLogs目录下打开日志“Test_guok_000001.csv

    选择Excel中的“插入”->“图表”->“折线图”,如下图所示

     

  • 使用DEBUGDIAG手动抓取DUMP文件

    2008-12-16 14:35:09

    使用DebugDiag手动抓取dump文件

    l  手动抓取IIS dump文件

    l  查看dump文件的默认存储位置

    l  修改dump文件的存储位置

    l  抓取dump文件的时机

    手动抓取IIS dump文件

    1、启动DebugDiag 1.1 (x86)后点击“选择规则类型”窗口中的“取消”按钮后,点击Processes分页。

    2、右键单击w3wp进程,并选择Create Full Userdump

    等待一段时间后出现成功创建dump文件,以及dump的文件名和存储路径的对话框,点击确定即可。

    查看dump文件的默认存储位置

    1、点击DebugDiag 1.1 (x86)工具主窗口工具栏中的“文件夹”图标

           查看弹出的窗口

          

           打开其中的misc文件夹,刚才所抓取的dump文件就存放在其中。

          

    修改dump文件的存储位置

    点击DebugDiag 1.1 (x86)工具菜单栏中的“Tools->Options and Settings”设置Manual Userdump Save Folder中的路径为所要修改的路径即可。

     

    抓取dump文件的时机

    1、应用程序初始化完毕(测试执行前)需要抓取一个dump文件

    2、使用性能计数器观察测试中的内存使用情况,在IIS崩溃前(观察Prvite#time in GC的变化)抓取dump文件以便于开发分析

    3、(可选)在性能计数器中观察gen2large object heapbytes in all heaps堆的使用和释放情况,在堆的使用即将达到一个高峰值(相对值)前抓取dump,并同时抓取堆释放到一个低峰值(波谷)前抓取一个dump,方便开发对比分析。

  • 如何有效开展性能测试(2)

    2008-12-16 14:24:08

    如何有效开展性能测试(2

    3.2 配置测试环境

    配置测试环境是测试实施的一个重要环节,测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境,硬件环境指测试必需的服务器、客户端、网络连接设备,以及打印机/扫描仪等辅助硬件设备所构成的环境;软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。考虑到其它因素,如网络锁、网速、显示分辩率,数据库权限、容量等对测试结果的影响。如条件允许,我们最好能配置几组不同的测试环境。

    搭建测试环境步骤:

    1)  测试环境规划

    测试环境的规划包括硬件、软件及所有构建测试环境所需的资源的规划,可以利用Checklist或是测试环境部署矩阵的方式完成;

    测试环境部署checklist

    测试环境说明

    对测试环境的简介

    项目名称

    测试项目名称

    项目简介

    对项目的简介

    网络拓扑图

    测试环境的网络拓扑图

    硬件配置

    描述配置环境硬件配置信息

    例如:

    CPU:至强3.0

    内存:4GB

    硬盘:200G

    网卡:千兆

    软件配置

    测试环境中所使用的软件环境配置(要有详细版本)

    例如:

    操作系统:Windows Server 2003 SP2

    系统服务:AD域、消息队列、MSDTC访问

    应用平台:Microsoft .Net Framework2.0 SP1

    应用软件:MCMS 2002 SP1

    数据库:SQL Server 2005 SP1

    中间件:IIS6.0

    浏览器:IE7.0

    杀毒软件:诺顿SEP

    软件防火墙:windows防火墙

    软件要求

    描述软件环境的详细配置:

    例如:

    操作系统需要配置/3G的支持

    需要打开windows防火墙

    IIS应用连接池的详细配置

    IE需要将应用网址添加到信任站点

    网卡型号

    描述测试环境的网卡型号信息详细

    例如:

    Intel PRO/100 NIC

    Intel(R) 82567V-2 Gigabit Network Connection

    网络信息

    描述网络的具体配置项

    例如:

    域名或工作组名

    IP地址

    子网掩码

    默认网关

    DNS服务器

    测试工具

    描述环境中需要安装的测试工具

    测试工具名称

    测试工具版本

    测试工具简介

    用户权限

    描述测试环境中的用户权限

    应用软件列表

    被测试的软件及版本描述

    如:

    门户网站后台管理服务端

    静态抓取服务端

    外来数据导入应用

    应用软件要求

    描述应用软件的详细配置

    Dao.config数据库连接的配置

    Webconfig配置

    外来数据导入配置

    2)        测试环境创建

    按照checklist中的网络拓扑、硬件配置、网卡型号的要求创建测试环境的硬件和网络环境,搭建完毕后,每个设备(PC或服务器)要整理出《硬件配置表》,以便于维护

    3)        测试环境配置

    按照checklist中的软件配置、软件要求、网络信息、用户权限配置测试环境中PC和服务器的软件环境,配置完毕后,每个设备(PC或服务器)要整理出《环境配置文档》,以便于后期的环境维护。

    4)        应用程序部署

    按照checklist中的应用软件列表和应用软件要求,将应用程序部署到测试环境中,部署完毕后,每个应用程序的部署要整理出《应用软件部署文档》,以便于后期的升级维护。

    5)        测试环境的使用

    在使用过程中可能会对测试环境做一定的调整,每次调整后,都要对相应的文档《测试环境部署checklist》、《硬件配置表》、《应用软件部署文档》和《应用软件部署文档》进行修改,以保持环境和文档的一致。

    6)        测试环境回收

    项目结束后,需要对项目中使用的资源进行整理,并将不使用的资源进行释放。

    硬件资源:PC机、服务器、磁盘空间、交换机等

    网络资源:IP地址

     

    3.3 测试数据的获取和处理

    功能测试的数据获取主要有三个方式

    1)  数据:针对正常业务,异常情况,边界情况等构建测试数据,不仅仅包括最基本的基础数据,比如:用户、权限、配置、基础编码、原数据等,还包括系统的业务数据;

    2)  “导”数据:把已经在生产环境中运行的数据或老版本中的数据导出,在此基础上进行数据的整理后加工为测试数据;

    3)      “积累”数据:使用现实的业务流程将现有的非电子化业务数据手工录入系统,在验证业务的同时也完成了测试数据的积累,即边测试边积累数据。但是这种情况积累的数据往往有一定局限性,因为已经发生的业务数据基本是正确的、一致的,而且可能缺少某些特定业务的数据(不常发生的分支业务)。这样就需要根据对测试需求的分析,追加新的测试数据,以便能完整覆盖业务类型。

    性能测试使用的数据和功能测试有一定的区别,准备测试数据的侧重点不同,性能测试使用的数据不用考虑如何去校验功能。性能测试数据要注意以下几点:

    1)        测试数据的唯一问题

    性能测试往往使用自动化测试工具进行测试,会使用相同的脚步反复的运行来进行测试,所以在测试过程中一定要注意脚本中参数的重复问题,设计测试数据时要考虑并发用户数以及每个用户可能迭代的次数,避免因测试数据数量不够而使用重复数据,最终导致测试失败。

    2)        测试数据的清理问题

    性能测试往往会向系统中增加大量的数据,增加的数据量足以达到影响系统性能的程度(例如:数据库表中有100条数据和表中有100W条数据的响应时间一定是不同的),所以必须及时的对增加的测试数据进行清理,以保证测试环境的公平性,进而保证测试结果的真实性。

    3)        测试数据数量和容量(大小)问题

    性能测试往往要使用“大”数据量来进行测试,“大”数据量不仅仅指数量的多少,还要考虑到数据容量的大小。例如:发布文章的测试,不仅要满足发布文章数量的要求,还要考虑到文章内容的大小,也就是说不仅要考虑发布10W1K大小的文章的性能还要考虑发布10W10M大小的文章的性能。

    4)        测试数据随意性问题

    测试数据忌随意性,随意输入指定长度的字符串,虽然满足测试执行的要求,但是对后续工作会产生很多不良影响,例如:无法保证数据的唯一性,随意的输入数据有几率产生重复数据;收集的测试结果开发人员不易分析,性能测试中的开发人员可能需要分析内存的Dump文件,随意输入的、没有规则的字符串不利于开发人员对dump文件的分析。

    4. 如何开展性能测试

      测试前期的准备工作纷繁复杂,做好测试准备工作,已是完成了测试工作的一大半,但要产生一份具有说服力的测试报告,还应正确把握测试的强度,保持测试的一致性,提高测试的精度。

    判断软件的好坏,要看软件解决实际应用的能力,只有在一定的测试强度下,才能测试出各种软件资源的消耗率,软件运行的速度,软件的稳定性。通过对比在不同的测试强度下,不同软件每一个功能模块解决实际问题的能力和软件运行的效率,我们才可能判断出不同软件的每一个模块的强弱,甚至于整个软件的优劣。

    性能测试开始后,所有参数的输入都应遵循统一的标准,无论是哪一个环节,哪怕是一点点偏差,都应立即纠正,绝不能心存侥幸。要特别注意外部环境对测试结果的影响,如果在整个测试过程中,外部环境不一致,如网速、机器内存使用率不一样,就有可能导致测试结果与实际情况有出入。

    实例1XX项目使用终端PCA1运行Loadrunner 进行15小时(1700-第二天早800)的压力测试,第二天查看结果,发现由于PCA1的内存不足,导致Loadrunner在凌晨300 查看(668) 评论(0) 收藏 分享 管理

  • 如何有效开展性能测试(1)

    2008-12-16 13:57:05

    如何有效开展性能测试(1)

    一、            性能测试类型

    性能测试是一种广义上的说法,包括了以下各种不同的性能测试类型,每种测试类型都带着明确的测试目的。

    1.性能测试(Performance Testing

    性能测试的方法是通过模拟生产运行的业务压力量和使用场景组合,测试系统的性能是否满足生产的性能要求。即在特定的运行条件下验证系统的能力状况。

    主要强调在特定的软硬件环境、特定的测试业务场景下,获得系统的各个性能指标。

    2.负载测试(Load Testing

    在给定的测试环境下,通过在被测系统上不断增加压力,直到性能指标超过预定指标或某种资源使用已经达到饱和状态,目的是了解系统性能容量和处理能力极限。负载测试的主要用途是发现系统性能的拐点,寻找系统能够支持的最大用户、业务等处理能力的约束。

    负载测试是在固定测试环境,在其它测试角度(负载方面)不变的情况下,变化一个测试角度并持续增加压力,查看系统的性能曲线和处理极限,以及是否有性能瓶颈存在(拐点)。主要意义是从多个不同的测试角度去探测分析系统的性能变化情况,配合性能调优。测试角度可以是并发用户数、业务量、数据量等不同方面的负载。

    3.压力测试(Stress Testing

    测试系统在一定饱和状态下系统能够处理的会话能力,以及是否出现错误,一般用于稳定性测试。

    可以理解为资源的极限测试。测试关注在资源处于饱和或超负荷的情况下,系统能否正常运行,是一种在极端压力下的稳定性测试。其主要意义是通过测试、调优保证系统即使在用户的极端压力下也不会出错甚至系统崩溃。

    压力测试的目的是调查系统在其资源超负荷的情况下的表现,尤其是对系统的处理时间有什么影响。这类测试在一种需要在反常数量、频率或资源的方式下执行系统。目标是通过极限测试方法,发现系统在极限或恶劣环境中自我保护能力。主要验证系统的可靠性。

    4.配置测试(Configuration Testing

    通过对被测系统的软硬件环境的调整,了解各种不同环境对性能影响的程度,从而找到系统各项资源的最有分配原则。

    主要用于性能调优,在经过测试获得了基准测试数据后,进行环境调整(包括硬件配置、网络、操作系统、应用服务器、数据库等),再将测试结果与基准数据进行对比,判断调整是否达到最佳状态。

    5.并发测试(Concurrency Testing

    模拟并发访问,测试多用户并发访问同一个应用、模块、数据时是否产生隐藏的并发问题,如内存泄漏、线程锁、资源争用问题。

    6.可靠性测试(Reliability Testing

    通过给系统加载一定的业务压力的情况下,让应用持续运行一段时间,测试系统在这种条件下是否能够稳定运行。

    需要和压力测试区分开,两者的测试环境和测试目的不一样。压力测试强调在资源极限情况下系统是否出错,可靠性测试强调在   一定的业务压力下长时间(如24×7)运行系统,关注系统的运行情况(如资源使用率是否逐渐增加、响应时间是否越来越慢),是否有不稳定征兆。

     

    二、如何有效开展性能测试

    1.引言

      作为评价产品性能的重要手段,性能测试在软件测试工作中占的比重一直很大,要最终提供一份准确,权威的测试报告,测试人员的努力工作自然不可或缺,但更重要的是测试人员清晰的工作思路,简洁的测试流程和良好的测试方法。

    2.目前性能测试存在的问题

      总结以往进行的性能测试,虽然测试人员自始至终对测试工作都做到了认真负责,但测试报告出炉后,大家总觉得美中不足,对测试结果都心存疑虑,尤其在那些时间跨度较长、针对不同的测试对象的性能对比测试中,或多或少都存在以下几个方面的问题:

    1.        测试准备不充分,测试目标不明确,测试计划不详细;

    2.        缺乏测试以及针对测试对象的技术储备;

    3.        测试环境的稳定性及前后一致性不足;

    4.        测试数据精确性和代表性不足;

    5.        测试描述不精练;

    下面,我们就剖析以上问题的同时,探讨一下如何解决这些问题。

    3. 性能测试准备

      这是一个经常被忽略的环节,在接到测压任务后,基于种种其它因素的考虑,测试人员往往急于进度,立即投入到具体的测试工作去了,测试、记录、分析,忙的不亦乐乎,工作进行了一半才发现,或是硬件配置不符合要求,或是网络环境不理想,甚至软件版本不对,一时弄得骑虎难下,这都是没有做好测试准备惹的祸。

      那么我们应该如何做好性能测试的准备工作呢?

      做软件项目有需求调查、需要分析,我们做测试也一样。在拿到测试任务后,我们首要的任务就是分析测试任务,在开始测试前,我们至少要弄清以下几个问题:

    1.        要测试什么或测试的对象是谁?

    2.        要测试什么问题或我们想要弄清楚或是论证的是什么问题?

    3.        哪些因素会影响测试结果?

    4.        需要怎样的测试环境(软件、硬件、网络环境)?

    5.        应该怎样测试?

      只有在认真调查测试需求和仔细分析测试任务后,才有可能弄清以上一系列的问题,只有对测试任务非常清楚,测试目标极其明确的前提下,我们才可能制定出切实可行的测试计划。明确测试目标,详尽测试计划在对测试需求充分了解的基础上,制定尽可能详细的测试计划,对测试的实施是大有裨益的。

    3.1 测试技术准备

    在目前的大环境下,要求测试人员在短时间撑握所有的软、硬件知识是不太现实的,但平时测试人员应抓紧对测试工具和测试理论的研究,在测试计划中,应给研究测试对象和测试工具分配充足的学习时间,只有在充分撑握测试工具,完全了解测试对象的前提下,我们才能够实施测试。建立在错误的认识上的测试,既使你再努力,结果也是背道而驰,也很难证明问题,更不用说用这样的测试报告去说服用户。

    技术准备列表:

    1)        扎实的计算机专业基础知识;

    2)        大量的实际性能测试及优化经验;

    3)        性能测试相关工具的使用;

    4)        操作系统的原理:熟悉操作系统的体系架构、操作系统的重要基础概念,以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理,熟悉常用的性能计数器;

    5)        数据库原理:能进行一般的数据库管理操作,熟悉SQL脚本的使用,熟悉常用的数据调优工具和常用的性能计数器;

    6)        web应用服务器原理:了解一般的配置,熟悉常用的服务器性能监控方法和原理,熟悉常用的性能计数器;

    7)        计算机网络原理:至少熟悉TCP/IP协议,熟悉HTTP协议,至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的性能计数器;

    行业知识:熟悉专属行业的业务知识和用户场景,例如银行网站后台管理系统所涉及的业务知识和用户场景,证券交易系统所涉及的业务知识和用户场景;

  • SQL Sever 2005 事件跟踪器:保存死锁图形(图文)

    2008-12-16 13:02:59

    l  使用 SQL Server 2005 事件跟踪器 保存 Deadlock Graph 事件

    l  Deadlock Graph 事件以 XML 文件形式保存。

    保存 Deadlock Graph 事件

    1、在文件菜单上,单击新建跟踪, 连接到 SQL Server 实例。

    将出现跟踪属性对话框。

    注意:如果选择了建立连接后立即开始跟踪,则不会出现跟踪属性对话框,而是直接开始跟踪。若要关闭此设置,请在工具菜单上,单击选项,再清除建立连接后立即开始跟踪复选框。

    2、在跟踪属性对话框的跟踪名称框中,键入跟踪的名称。

    3、在使用模板列表中,为此跟踪选择一个跟踪模板;如果不想使用模板,请选择空白

    4、单击事件选择选项卡。

    事件数据列中,展开“Locks”事件类别,然后选中“Deadlock Graph”复选框。如果没有显示“Locks”事件类别,请选中显示所有事件以显示该类别。

    事件提取设置选项卡将添加到跟踪属性对话框中。

    注意:如果使用模板将不会出现 事件提取设置选项卡,需要取消并再次选择Deadlock Graph 事件,才会出现事件提取设置选项卡

    Deadlock Graph 事件以 XML 文件形式保存

    5、在事件提取设置选项卡上,单击分别保存死锁 XML 事件

    6、在另存为对话框中,输入要存储 Deadlock Graph 事件的文件的名称。

    7、单击单个文件中的所有死锁 XML 以将所有 Deadlock Graph 事件保存到单个 XML 文件中,或单击不同文件中的每个死锁 XML 以为每个 Deadlock Graph 事件创建新的 XML 文件。

    保存死锁文件后,您可以在 SQL Server Management Studio 中打开查看该文件

    注意:按照以上步骤配置,在测试结束后需要手动的保存Deadlock Graph 事件的跟踪记录(为灵活起见,在第3步中没有配置保存文件的选项)

数据统计

  • 访问量: 48844
  • 日志数: 19
  • 建立时间: 2008-11-13
  • 更新时间: 2008-12-16

RSS订阅

Open Toolbar