-
一些重要的性能计数器(转载)
2007-07-04 18:38:13
解决性能问题的时候，我往往会让客户添加下面一些计数器进行性能收集。
Process object下的所有计数器。
Processor object下的所有计数器
System object下的所有计数器
Memory object下的所有计数器
如果客户的程序是.NET程序，还会添加 .NET 开头的object下的所有技术其
如果客户使用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 Commit的Memory数量。无论是直接调用API申请的内存，被Heap Manager申请的内存，或者是CLR 的managed heap，都算在里面。跟Handle Count一样，如果在整个程序周期内总体趋势是连续向上，说明有Memory Leak
Virtual Bytes
该计数器记录了当前进程申请成功的用户态总内存地址，包括DLL/EXE占用的地址和通过VirtualAlloc API Reserve的Memory Space数量，所以该计数器应该总大于Private Bytes。一般来说，Virtual Bytes跟Private Bytes的变化大致一致。由于内存分片的存在， Virtual Bytes跟Private Byes一般保持一个相对稳定的比例关系。当Virtual Bytes跟Private Bytes的比例关系大于2的时候，程序往往有比较严重的内存地址分片。
Processor object
Processor object记录系统中芯片的负载情况。由于普通程序并不刻意邦定到某个具体CPU上执行，所以在多CPU机器上观察Total Instance也就足够了
% Processor Time 该计数器跟Process下的% Processor Time的意义一样，不过这里记录的是所有进程带来的芯片，而不是针对具体某一个进程。通过把这个计数器跟Process下的同名计数器一起比较，就能看出系统的高CPU问题是否是由于单一的某个进程导致的
System
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
Memory
Memory object记录了当前系统中整体内存的统计信息。
Available Mbytes
Committed Bytes
Available Mbytes记录了当前剩余的物理内存数量。Committed Bytes记录了所有进程commit的内存数量。结合两个计数器可以观察到：
1) 两者相加可以粗略估计系统总体可用内存多少，便于估计物理配置
2) 当Available Mbytes少于100MB的时候，说明系统总体内存吃紧，会影响到整个系统所有进程的性能。应该考虑增加物理内存或者监察内存泄露
3) 通过比较Process\Private Bytes跟Virtual Bytes，便于进一步确认是否有内存泄露，判断内存泄露是否是某一单个进程导致
Free System Page Table Entries，Pool Paged Bytes和Pool Paged Bytes
这三个计数器可以衡量核心态空闲内存的数量。特别是当使用/3GB开关后，核心态内存地址被压缩，容易导致核心态内存不足，继而引发一些非常妖怪的问题。可以参考以下文章：
How to use the /userva switch with the /3GB switch to tune the User-mode space to a value between 2 GB and 3 GB
http://support.microsoft.com/kb/316739/en-us
.NET CLR Memory
.NET CLR Memory object记录了CLR进程中跟CLR相关的内存信息。该类别下的所有计数器都很有意思，而且意思也非常直接。建议用一个例子程序进行测试和研究。下面是两个最常用的计数器
Bytes in all heaps
Bytes in all heaps记录了上次GC发生时候所统计到的，进程中不能被回收的所有CLR object占用的内存空间。该计数器不是实时的，每次GC发生的时候该计数器才更新。跟同一进程的Process\Private bytes比较，可以区分出managed heap和native memory的变化情况。对于memory leak，便于区分是managed heap的leak还是native memory的leak
%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，否则说明已经有请求堆积，性能问题严重
文章作者：lixiong 录入时间：
-
性能测试案例解析(四)
2007-06-18 11:50:03
4.1数据库调优策略
1．修改sql语句中影响速度的写法
2．增加或者修改索引
针对表间的连接创建索引
针对查找建立索引
使用索引时，遵守以下原则可达到更好的效果
第一：一般建立在多个字段上的一个组合索引优于针对单个字段建立的多个索引，根据值匹配条件创建的索引也需要遵循同样的原则：
第二：创建组合索引时，精确匹配的字段放在非精确匹配字段前面，取值范围大的字段放在取值范围小的字段前面，可以提高查询速度，如身份证字段应该放在性别字段前面。
第三：索引并不是越多越好，当数据库记录较多时，意味着数据库要付出的开销将会很大，从而降低数据库其他方面的性能。
3．调整相应数据库的系统参数（系统投产生的调优，通常由厂商的配合完成）
一般检查项为：复杂语句支持，大对象功能支持，并发查询性能，吞吐量，数据迁移（导出备份）。
4.2weblogic/oracle相关分析
主要监控：%processor, Avalable Mbytes(空闲内存), JVM内存，connection Delay Time（数据库连接池建立数据库连接的时间）
Oracle运行平台AIX监控（unix），cpu的使用率（cpu utilization），disk traltic(磁盘负载)，page-in,page-out rate的使用情况。
以及oracle本身相关报告：相看缓冲区调整缓存，应用程序的i/o操作。
4.3性能测试用例设计要基于用户语言
即满足用户要求又相对全面的性能测试用例，设计时要基于“用户语言”，易于用户理解的、大纲形式的测试用例，这样涉及的技术语言不多，用户很容易看懂。这样使得用户在现场测试阶段能够提出很多改进建议，并同意对用例进行调整（删减近一半的用例），可以为后期执行测试节约成本。
性能测试实施的特点之一就是不会严格按照测试用例来执行，通常是在项目中对用户进行一定的调整，然后再去执行，对于测试用例进行调整，删除、修改、增加，这是很正常的，基本成本来进行设计和执行。
共计四篇,摘自<<web性能测试实战>>
备注:只为方便自已查阅,对于文中增删不全的地方,如果感兴趣建议查看原文,同时欢迎大家交流讨论!
-
WEB性能测试分析(三)
2007-06-18 11:45:29
1．随着压力的加大，吞吐率的曲线在增加到一定的时候，出现变化缓慢，甚至平坦的状态，很有可能标明网络出现带宽瓶颈。类似地，当压力加大时，点击率/TPS曲线出现变化缓慢或平坦的趋势，很有可能服务器开始出现瓶颈。
2．吞吐率与TPS具有很强的关联性：如果随着压力的加大，吞吐率和TPS的变化呈大体一致的趋势，即一起增加，说明在测试的压力下，系统没有出现显著的性能瓶颈。
3.1性能分析的步骤
1．首先从响应时间做为分析性能的起点。查看响应时间以判断是否满足用户对性能的期望。
2．考察系统的瓶颈是在网络环节还是在服务器环节。
针对服务器分析主要涉及应用程序、web服务器、数据库服务器、操作系统等。
首先应该分析业务或者用户事务的响应时间，根据测试结果来分析哪些业务真正变慢了，然后分析web资源的处理情况，最后对页面组成元素的响应时间进行分解。
1．查看结果综述图：查看事务的平均响应时间，以及事务的通过率
2．查看事务综述图和事务平均响应时间分析图：查看事务通过和失败的数值，来判断是程序算法出现问题还是服务器存在内存泄漏现象。
3．每秒通过事务数分析图：可确定系统在任何给定时刻的实际事务负载。当发现每秒通过的事务数减少时，就需要更加深入的分析，配合服务器监控数据一起分析。
4．事务性能摘要图：重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
5．事务响应时间与负载分析图：正在运行的虚拟用户和平均事务响应时间图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展应用系统提供参考，对分析具有渐变负载的测试场景比较有用。
6．事务响应时间分布情况分布图：预先定义相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
1．点击率图：每秒点击次数，即点击率图显示在场景运行过程中虚拟用户每秒向web服务器提交的HTTP请求数，可依据点击次数来评估虚拟用户产生的负载量，还可将其与”平均事务响应时间”图进行比较，以查看点击次数对事务性能产生的影响。
系统点击率下降通常表明服务器的响应速度在变慢。
2．吞吐率图：显示场景运行过程中服务器每秒的吞吐量。度量单位是字节，表示虚拟用户在任何给定的某一秒上从服务器获得的数据量。
点击率：每秒服务器处理的HTTP申请数
吞吐率：客户端每秒从服务器获得的总数据量。
每秒HTTP响应数图还能返回其他各类状态码信息，通过分析状态码，可以判断服务器在压力下的运行情况。
常见的http状态代码：从200-505均有其含义。如202：已经接受请求，但处理尚未完成。
3．每秒连接数图：显示在运行过程中每秒新建立的TCP/IP连接数。新连接数应该是每秒点击次数的一小部分，理想情况下，很多的HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。
通过它可深入地分析网站上那些下载很慢的图像或中断的链接等有问题的元素。
页面分解总图：可显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。
1．下载时间细分：查看静态gif图片和动态的jsp代码。
2．组件细分（随时间变化）：可以选择不同的元素查看测试过程中其下载时间的变化曲线。适用于需要在客户端下载控制较多的页面，通过分析控件的响应时间，很容易就能发现哪些控件不稳定或者比较耗时。
3．下载时间细分（随时间变化）：查看jsp页面主要时间花在如receive,first buffer,connection等。
下载时间细分：宏观，整个测试过程页面元素响应时间的统计分析结果
下载时间细分（随时间变化）：微观，显示场景运行过程中每一秒内页面元素响应时间的统计结果。
4．第一次缓冲时间细分（随时间变化）：可查看页面运行时间主要花在服务器还是网络传输上。
服务器分析通常从web服务器和数据库服务器入手。
服务器分析的第一步，分析测试工具对web服务器和数据库服务器相关计数器的监控结果，然后确定在压力下是web服务较慢还是数据处理较慢。
Web服务较慢：查看web服务器的各种参数配置，如最大连接数、最大内存等是否设置的合理。查看内存、CPU、硬盘
数据处理较慢：一般是数据库配置发生问题，或是硬件资源配置太低。如oracle,要查看内存配置、运行模式等信息。
-
性能测试实施与管理(二)
2007-06-18 11:41:23
测试计划：主要包含测试范围、测试环境、测试方案简介、风险分析等，测试计划要进行评审后方可生效。
测试报告：主要包含测试过程记录、测试分析结果、系统调整建议等。
测试经验总结：不断总结工作经验是建立学习型团队的基础，实践－总结－再实践
2.1人员之间的配合关系
客户代表：可了解一些项目的背景知识，例如客户在软件性能方面的需求，是否关注性能测试等，这些都是制定性能测试策略的依据。
需求分析员：确定哪些业务是核心业务，为后面编写核心业务模块相关的测试用例打下良好的基础，并且他们对用户群体构成以及系统的扩展目标较清楚，这些都是设计性能测试的数据来源。
架构师：了解系统的结构，使设计出的性能测试用例在“恰当”的地方施压。
2.2性能测试的范围确定
对测试项或测试需求进行打分，根据综合评分确定性能测试工作包含的测试内容，评分要素主要包含客户关注度、性能风险、测试的成本等，性能风险主要指如果不进行该项性能测试需求，投产系统可能潜在的风险。
客户关注程度或者性能风险较高的均应划分到测试范围内。
编号
测试需求
性能风险
(10分)
用户关注度(10分)
成本投入
(10分)
总分
1
系统运转一年的数据量测试
7
10
6
23
2
……
……
2.3目标系统的业务分析
确定系统的核心模块：业务比较复杂或用户使用较频繁
确定模块件的耦合关系：清晰了解核心模块间数据传输方式，通过确定模块间如何接口，可以真实地模拟多用户并发时的情况，尤其可以确定用户并发时一些算法是否正确。
分析系统压力点：多是用户使用较频繁或数据流量较大的地方。
2.4用户及场景分析
一，基于用户实际使用情况的场景测试，二，为了特殊测试目的(扩展性、稳定性)而设计的场景测试。
确定系统有多少类典型的用户，每类用户的大概数量以及在不同时间段各类用户大概按照何种比例来使用系统。较常见的用户场景有如下三种：
一天内不同时间段的使用场景
系统运行不同时期的场景
不同业务模式下的用户场景
2.5整体规划
性能测试规划的重点是时间、质量、成本等项目管理要素。
Loadrunner:是一种预测系统行为和性能的负载测试工具,目前很多公司执行性能测试的首选工具.
Rational performance: rational 系列产品之一,功能非常强大,和loadrunner竞争比较激烈.
QALoad:compu ware 公司的产品
Webload:专门用于web性能测试的工具
WAS:全称是Microsoft Web Application Stress Tool,微软提供的免费性能测试工具
Apache JMeter :开源的性能测试工具
openSTA:开源的性能测试工具
测试结果数据是分析系统瓶颈的主要依据,大量的测试结果文件要进行规范管理,统一文件的命名规范.例如:
执行性能测试尽量不要破坏用户环境,而且要预先制定相应的备份/恢复策略,以便系统发生意外时可以恢复到测试前的状态.
性能测试很有可能产生大量的垃圾数据,消除垃圾数据是测试结事后首当其冲的工作
测试时还要监控测试机的使用情况,除非保证场景消耗的资源不会超出测试机的负载能力,否则就应该认真监控测试机,因为一旦测试机发生瓶颈,所有测试结果均无实际意义.
主要关注性能测试规划与设计、测试用例设计、测试工具与技术、性能分析等方面。
性能测试用例的设计分析：可用性、执行效果、执行时间、还应该分析用例的设计方法、设计思路等。
对于瓶颈：应用系统、数据库、web服务器等有时会因配置参数不正确导致系统性能不高，可积累解决这方面问题的经验，以便于以后快速解决问题。
-
web性能测试基础(一)
2007-06-18 11:31:07
1.1基本概念
并发用户：用户并发一般发生在使用比较频繁的模块中，而且遇到异常通常都是程序的问题。
用户并发数量：在线用户数量是计算并发用户数量的主要依据之一。=使用系统的用户数量*(5%~20%)
并发主要针对WEB服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。
吞吐量：一次性能测试过程中网络上传输的数据量的总和。
吞吐率:吞吐量/传输时间，单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。吞吐率用“请求数/秒”或者“页面数/秒”来衡量。
点击率：每秒钟用户向web服务器提交的HTTP请求数。点击率越大，对服务器的压力也越大。重要的是分析点击时产生的影响。
点击不是指鼠标的一次“单击”操作，因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求。
1.2WEB性能测试种类
压力测试：确定一个系统的瓶颈或者不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。
负载测试：在被测系统上不断增加压力 ，直到性能指标达到极限，响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供依据。
大数据量测试：针对某些系统存储、传输、统计查询等业务进行大数据量的测试。
配置测试：通过测试找到系统各资源的最优分配原则。
可靠性测试：可以施加cpu资源保持70%-90%使用率的压力，连续对系统加压运行8小时，然后根据结果分析系统是否稳定。即加载一定压力的情况下，使系统运行一段时间。
并发测试：多以发现一些算法设计上的问题。
性能测试以用户并发测试为主的测试。
性能测试主要是为了发现软件问题和硬件瓶颈。
对于性能方面给系统留有30%左右的扩展空间即可。
1.3Web全面性能测试模型
主要指需求分析和设计阶段提出的一些性能指标。
针对每个指标都要编写一个或者多个测试用例来验证系统是否达到要求。
预期指标的性能测试用例通常以单用户为主，如果涉及并发用户内容，则归并到并发用户测试用例中进行设计。
选择具有代表性、关键的业务来设计用例，并且用户的设计应该面向“模块”
用户并发性能测试分为：独立核心模块并发性能测试，组合模块并发性能测试
独立核心模块并发：完全一样功能的并发测试；完全一样操作的并发测试；相同/不同的子功能并发。
针对独立核心模块用户并发性能的测试用例设计，可发现一些核心算法或者功能方面的问题，如一些多线程、同步并发算法在单用户模式下测试是很难发现问题的，通过模拟多用户的并发操作，更容易验证其是否正确和稳定。
核心模块测试一般属于基本的性能测试，它较多地关注模拟的“功能”，一般不会对服务器进行测试。
组合模块并发：具有耦合关系的核心模块进行组合并发测试；彼此独立的、内部具有耦合关系的核心模块组的并发测试；基于用户场景的并发测试。
组合模块测试一般发现接口方面的功能问题，并尽早发现综合性能问题。
在实际中，各种类型的用户都会对应一组模块，相当于不同的业务组在并发访问系统，要充分考虑实际场景，如话费管理系统中的每月10日左右的收费高峰等场景。
在编写组合模块用户并发性能测试用例时，不但要考虑用户使用场景，还要注意并发点的运用，并发点是指一定数量的用户开始执行同一功能或者操作的时间点，一组测试场景通常包含多个并发点，从而实现了核心模块同一功能或者操作的真正并发。
独立业务实际是指一些核心业务模块对应的业务。这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。主要测试这类模块和性能相关的一些算法、还要测试这类模块对并发用户的响应情况。
用户并发测试是核心业务模块的重点测试内容。
是最接近用户实际使用情况的测试，也是性能测试的核心内容。
组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。
用户并发测试是组合业务性能测试的核心内容。“组合”并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来进行匹配。
为准确展未带宽、延迟、负载和端口的变化是如何影响用户的响应时间的。主要是测试应用系统的用户数目与网络带宽的关系。
调整性能最好的办法就是软硬相结合。
主要是针对对数据库有特殊要求的系统进行的测试，主要分为三种：
1．实时大数据量：模拟用户工作时的实时大数据量，主要目的是测试用户较多或者某些业务产生较大数据量时，系统能否稳定地运行。
2．极限状态下的测试：主要是测试系统使用一段时间即系统累积一定量的数据时，能否正常地运行业务
3．前面两种的结合：测试系统已经累积较大数据量时，一些实时产生较大数据量的模块能否稳定地工作。
大数据量测试用例的设计:1,历史数据引起的大数据量测试和2运行时大数据量测试
首先确定系统数据的最长迁移周期和选择一些前面的核心模块或者组合模块的并发用户测试用例作为其主要内容即可.
性能测试的主要目的是在软件功能良好的前提下，发现系统瓶颈并解决，而软件和服务器是产生瓶颈的两大来源，因此在进行用户并发性能测试，疲劳强度与大数据量性能测试时，完成对服务器性能的监控，并对服务器性能进行评估。
服务器性能测试用例设计就是确定要采集的性能计数器，并将其与前面的测试关联起来。
可以满足预期性能指标测试用例要求的，就没有必要设计更多的内容，因为用例越多，执行的成本也越高。
一定要服从整体性能测试策略，千万不能仅从技术角度来考虑设计“全面”的测试用例，“全面”应该以是否满足自己的测试要求作为标准。
适当裁剪原则
只有根据实际项目的特点制定合理的性能测试策略、编写适当的性能测试用例，并在测试实施中灵活地变通才可以做好性能测试工作。
-
性能瓶颈与数据库调优
2007-05-27 23:06:55
所有的应用程序都存在一定程序的性能瓶颈，为了提高应用程序的性能，就要尽可能的减少程序的瓶颈，以下是程序中常见的性能瓶颈。
瓶颈 程序中的操作 文件的读写和网络的操作 程序等待读写数据到网络或硬盘 CPU 等待CPU空闲 内存 程序不停的分配，释放和扫描内存 异常 程序不断的处理异常消息 同步 程序等待共享资源被释放 数据库 程序等待从数据库中返回结果 具体的数据库测试主要从查询、更新、插入等方面测试，而对具体的数据库进行调优，主要从以下几个方面进行：
1．Rowre-sequencing以减少磁盘i/o
2.oracle sql调整。
3．调整oracle排序。
4．调整oracle的竞争：表和索引的参数设置对于update和insert的性能有很大的影响。
标题搜索
我的存档
数据统计
- 访问量: 19457
- 日志数: 34
- 图片数: 8
- 书签数: 11
- 建立时间: 2007-04-24
- 更新时间: 2010-11-09
