性能调优step by step

(一) --方案和原则

一.方案演化

历经一周多的性能测试和性能调优工作接近尾声了，这里总结下一周多的进展和调优情况。首先声明一点，我没有性能调优方面的经验，很多方法都是请教了大牛和网上查找得到的答案，感觉自己进步了很多。

1.1封装框架

刚开始对于压力测试采用的自己先的压力测试框架，就是启N多线程。然后调用远程服务器进行压力测试，调用完成后有响应时间等统计信息（见pc2性能测试方案篇）

优点：压力测试简单，不需要写太多代码。

缺点：和客户端性能有很大关系，在不同客户端上起线程的速度肯定不一样，这样就导致了测试出来数据价值不是很大。

1.2 windows下Jmeter 进行测试

优点：统计信息全面，较为切近的模拟并发情况。

缺点：由于windows下客户端性能差别较大，启动线程并没有linux下快，会导致发送的请求数有限，tps上不去的。

1.3 linux下Jmeter 进行测试

优点：较好的模拟并发情况，并发效率较高。

缺点: 使用较为复杂，如果使用nmon更需要一定的配置基础。

二.调优原则

1. 贵在坚持，不可以一簇而就，别人的经验通常是针对特定系统，特定环境的，不可以照搬，不可以不知所以然。

2. 细节决定成败，调优的准备工作要做好，消除外部因素对测试造成的影响。

3. 可以按照先整体-后部分-再整体的思路进行测试，先整体是看看整体哪块有问题，找出比较慢的部分进行重点测试和调优，然后再整体测试保证所有应用并发是没有问题。

(二) --方法和步骤

1. webTrace跟踪数据库SQL 瓶颈：是否走到索引，是否sql执行计划最优等。

2. jProfile跟踪那块代码消耗cpu较多，（jprofile使用方法见工具篇）。

3. kill -3进行线程查看，如果有大量BLOCKED线程，则说明有问题，如果RUUNNBLE的线程很多都是在执行一样的操作那就说明这部分比较消耗资源，要做优化。

4. apache调优，对apache的各个参数进行调优，最终使apache参数对应于当前系统和当前并发量最优。所以调优的并发量参考数据要经过计算，不可以认为响应时间越快，tps越高越好。（经验告诉我们apache由于是多进程多线程的，我们采用的是apache 和jboss一直链接的情况，也不会消耗太多性能，所以还是apache好些。其在并发处理方面的能力要显著高于JBOSS）

5. jvm 调优：对于jboss配置的jvm 垃圾回收机制进行调优，让其垃圾回收更加及时高效。

6. 内存使用调优，使用jconsole 进行监控，如果内存直线上升，最终得不到稳定，则说明有可能存在内存泄露等问题。

7. linux 内核调优。这部分难度较高，一般不需要，如果以上步骤不能满足性能要求，考虑此步骤。

(三) --遇到的问题(数据库)

1. Webtrace 分析sql 性能，发现

userPermissionService.listVAccountIdsByUserIdAndProductCode

是数据库未分析数据，执行方案是基于开销的方式，导致执行计划未走到索引。后来是走的索引，但是仍然较慢。

分析：

kill -3后查看jboss 日志发现很多都在执行listVAccountIdsByUserIdAndProductCode 这个代码

由于apache 线程池都进行了调整，有足够多的等待线程，不太会导致BLOCKED，这样runnble 的较多都集中在这个代码上，就说明线程在这里比较占用时间。（用vi 不要用tail）

这个sql有问题：

select pup.vaccount_id

from pc2_user_permission pup

where pup.product_code = #productCode#

and https://www.wendangku.net/doc/e84662364.html,er_id = #userId#

and pup.acl = '1'

没有走正确的索引，目前只有product_code +user_id的索引，需要建立

product_code +user_id + acl的索引

解决方法：DBA 进行oracle 的数据分析，然后再跑，或者delete掉数据，这和应用进行delete 一样，数据库会自动进行数据分析和重建索引等。

对于走了索引仍然较慢的情况，加上含有acl的索引，这样就不用查询数据库了，速度会快比较多。

2. 测试apache 和jboss 性能对比情况时，发现和QA使用jmeter测试的结果不一致，本机测试apache 较好，QA测试jboss反而更优。

本机测试，多数情况是apache 较好，QA使用jmeter做大并发时，数据库连接数是个瓶颈，经常over-load。

解决办法：需要让DBA 再把数据最大连接数调大些，process给调成250。

3. 不断执行压力测试，表空间占满。

分析：不停的delete 和insert时会有碎片产生，这样oracle自己的回收机制来不及做，就会导致原来占一个G的数据，现在就要占5G并且会增加insert的成本，导致插入数据时非常慢。

处理方法：正常情况下是会自动回收的。只要在高并发情况下才会出现这种情况,原来表空间6G，目前增加到10G，DBA进行碎片整理。

4. DBA调整了事务管理块及insert预分配空间，调整后性能有所提高，大概提高10%左右

因为PC2中有大量的insert操作，DBA认为insert操作时，若有较多的磁盘碎片，会对insert 性能产生影响，所以为此预分配了一定空间，所有的插入操作都是往预分配空间插入，这样省去了寻址的时间。

5. 报数据库已经关闭异常，jboss log 报出

ERROR com.mchange.v2.resourcepool.BasicResourcePool :: com.mchange.v2.resourcepool.BasicResourcePool@5b553d28 -- Unexpectedly broken!!!

com.mchange.v2.resourcepool.ResourcePoolException: Unexpected Break Stack Trace!

解决方法：修改pc2-spring-common.xml 中C3P0配置，将其如下值修改

此问题较为普遍，在UDB和原来PCC都有发生，发生场景为不少连接被占用（本次是被预发环境占用）资源发生竞争时，如果设置为true,已经被占用的连接，就会直接报出异常，如果为false ，他会去尝试再获取下，短链接的情况下会很快释放的，这样就不会报出异常了。

6. 多次fetch的数据问题

webtrace是一个很不错的SQL跟踪工具

通过查看trace得到的SQL执行情况，问题一可以很容易查到原因，问题三的原因也由此可以看出来。

虽然走到索引，但fetch次数太多（ibatis是以object来传输的，查到了这么多数据，取了这么多次，肯定是耗费很大性能的）。数据存在问题。

(四) --遇到的问题(Apache)

一.两个失误

1. Timeout 20 改错改成0了，导致报500 异常

解决办法：这样客户端链接一直不超时，很快就会占满所有的资源。其它连接就连接不上。这个超时时间是必须有的

2. 配置的应该是AJP1.3的协议，原来配置项有些配置到8080端口了配置的是http1.1协议。对应于AJP的8009参数没有配置上。导致不能满足高并发的要求.

二.其他调优点

3. tps 上不去

分析：

（1）测试代码问题,把newSampleTest（）放在了setUp里面，统计结果不准，导致TPS一直比较异常，要么是用户数整除的，要么是直线上升的。

（2）TPS开始会比较高，但随时间大幅下降，响应时间也是越来越长,并通过监控显示, 大量线程bolck在取用户产品权限这里QA的测试脚本中存在一个问题：往数据库插入的数据，每次请求都是同一个userid,只会循环改变vaccountid，这样导致按userid取列表的SQL性能每次请求一次比一次差。

（3）接口测试时都是短连接，不需要长链接。

httpd.conf KeepAlive 为Off

JkWorkerProperty worker.localnode.connection_pool_timeout=0 为链接池的等待时间，让其不超时，因为我们采用的是一个apache 对应一个jboss 一直保持通讯就可以了，JBOSS 同步修改。

结果：比原来理想，tps 有提高。

4. 502 异常频繁出现

4.1 解决办法：将原来的mod-jk localnode方式修改为loadbalancer，使用apache 缓冲池，并设置了apache 线程池大小为500。

4.2 又爆出502、503 异常：Apache configured -- resuming normal operations

将socket超时时间增加些，让请求的线程等待时间加长一点。不至于很快拒绝掉，导致503异常。

JkWorkerProperty worker.localnode.socket_timeout=20 增加

JkWorkerProperty worker.localnode.connection_pool_minsize=25 （增加，原来注释掉了）

4.3 502 Response has been sent to the client (yet)

解决方法：线程池被被占用，先修改log看下，再有问题修改下mod-jk soket超时时间。调的长一点。

5. 将maxProcess 和maxThread 同时出现，以哪个为基准，cpu与性能有什么关系

分析：maxProcessor 和maxThread 同时出现时，maxProcess 优先级较高。maxProcess 表示最大并发数，maxThread 是jboss 启动的最大线程数。

这里最大链接数调整为3200 ，这个已经足够满足需求了，用于保证jboss 的稳定性，算法就是每个cpu 可以撑住200个线程，16core*200/core = 3200 ，生产环境为8core cpu需要调整下。

apache 起了10 个进程StartServers = 10 这里有两个相关参数要调整

MinSpareThreads（http_conf）*10 = MinSpareThreads (server.xml) ？

JkWorkerProperty worker.localnode.connection_pool_size=320 *10 (启动了10个进程)= maxClient

ServerLimit 100

ThreadLimit 400（大于ThreadsPerChild 320）

StartServers 10

MaxClients 3200

MinSpareThreads 100

MaxSpareThreads 320(小于MaxClients/10)

ThreadperChild 320

6. 报异常Socket read failed

[org.apache.catalina.core.StandardWrapperValve] ERROR org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/pc2].[remoting] :: Servlet.service() for servlet remoting threw exception

java.io.IOException: Socket read failed

at org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:1014)

at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:1089)

解决方法：对比和UDB配置区别server.xml

maxThreads="3200" [color=red]minSpareThreads="100"（1000修改为100没有与httpd中相应值10：1 这个说法）[/color] backlog="256"

7. 宕机，apache error_log报child process 14629 still did not exit, sending a SIGTERM 错误

解决办法：apache 子进程无法正常终止，资源耗尽就宕机了，apache的日志文件太大导致的，将apache 日志删除。

8. 3200多个close_wait 状态，apache 很慢。最终跑完时有1800多个close_wait，gcUtil 观察回收情况，发现回收不正常YGC非常慢，不是每次更新一行都有增加回收次数

解决方法：由于测试环境是16core的cpu ，这样我们的最大连接数可以按照16*200= 3200 调，从结果来看，1800个最终的close_wait/UDB 在同样配置下是900左右的cose_wait挂起状态，也说明我们16核接收了更多请求，但是apache 配置确没有接受这么多，导致线程阻塞。调整为3200个最大并发数。

调整后wait 的线程保持200 个左右回收正常了。刚才的回收不正常是由于线程挂起导致

的。

(五) --遇到的问题(内存)

1. free 查看内存，使用超过16G（累积出来的）。而生产环境只有一驱四25G内存，有内存溢出危险。

解决方法：修改jboss 启动脚本虚拟机配置，修改回收机制，改为CMS回收。

Xml代码

JAVA_OPTS="-server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX

:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods"

2. 内存使用始终很大，在2G多，tps 也上不去。ps –aux 没有发现apache日志占用内存。

解决方法：apache access log 是apache的访问日志，每次访问都会记录，占用了46M，删除后内存占用降低了很多从2G多降低到300M，最终在httpd.conf中去掉access_log配置

#DeflateFilterNote ratio

#LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate

#CustomLog /home/admin/pc2/logs/deflate_log deflate

#LogFormat "%h %l %u %t \"%m /%{HOST}i%U%q %H\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %T" combined

#LogFormat "%h %l %u %t \"%r\" %>s %b" common

#LogFormat "%{Referer}i -> %U" referer

#LogFormat "%{User-agent}i" agent

#CustomLog /home/admin/pc2/logs/access_log combined

(六) --遇到的问题(环境准备)

1. SA默认装了jboss4.

2.3GA+jdk1.6会出现ajp connector的线程挂起在CLOSE_WAIT状态上。属于jboss的一个bug,具体见：https://https://www.wendangku.net/doc/e84662364.html,/jira/browse/JBPAPP-2100

解决方法：Jboss 4.2.3的bug 后来统一调整为 4.0.5 版本。

可选通过修改Linux内核参数：

net.ipv4.tcp_keepalive_time=30

net.ipv4.tcp_keepalive_probes=2

net.ipv4.tcp_keepalive_intvl=2

增大tcp协议请求的等待时间，尝试消除CLOSE_WAIT状态的线程。一定数量的close_wait 状态（即线程挂起）多时则需要处理。

2. open files 确保足够大，否则并发大的情况可能jmeter-server会出现too many open files

解决方法：ulimit –a 查看系统参数

配置为

open files (-n) 10240

3. Jprofile 比较影响性能，做长时间大压力测试时去掉。

4. 发送消息给计费，连不通，导致异常，pc2_log 变的很大303 M，内存飙升，old区有大量对象待回收。

解决方法：看下出异常的时间，4：30 左右开始飙升，出错时间吻合，就说明是出错导致的，还有一个影响因素就是00的task 每两分钟取10000条进行处理,处理时肯定会导致大量并发等待，占用大量内存，一时回收不掉。

将任务时间调短一点

将数据中错误数据清除（待处理）

(七) --遇到的问题(方法策略和代码问题)

1. QA 测试时，第一次去链接时间较长

处理方法:应该去除第一次链接的时间，第一次链接的时间包含了DNS解析等等，比较消耗时间，这个和访问web页面一样的道理。才能模拟正常的使用情况。

2. 测试错误率要求在0.01%-0.05%，目前太高。

处理方法：测试程序覆盖了原有的result是false 还是true 的方法。导致有些成功的也返回false。

3. jprofile 跟踪到代码有cpu-views 刷新缓存消耗较大。Kill -3 发现大量线程都在执行这个

（1）中有对对象的序列化，比较慢

List listCorpInfo = new ArrayList();

for (String vaccountId : vaccountList) {

CorpInfo corpInfo = corpInfoCacheService.getCorpInfoByVaccountId(vaccountId);

if (corpInfo != null) {

listCorpInfo.add(corpInfo);

}

}

解决方法：刷新的是公司列表数据，由于corpinfo不是java 内建对象，采用java自有的序列化机制，效率不高，修改代码改变缓存实现策略（刷新缓存返回时不返回公司列表，返回null，不用序列化公司实体了）

(八) --工具和方法

一.linux 自带命令查看性能等。

(1)top -1 查看cpu 使用情况，占到162%

(2)free 查看内存，使用超过16G（累积出来的）

(3)ps cx | grep java

kill -3 pid 强制显示该java 进程的线程信息

发现39个blocked进程

grep "BLOCKED" jboss_stdout.log -wc

TIMED_WAITING是主动的有时间的waiting，是没问题的. 很多线程并发时，RUUNBLE较多的集中在同样的线程上，就会有问题的。

(4)netstat -an| grep CLOSE_WAIT 和上面的作用一样的

netstat -an| grep WAIT

(5) 查看并行的进程

netstat -an|grep EST|wc -l

查看数据库连接数

netstat -an|grep 1521|wc -l

(6)jstat -gcutil 线程2000 监控堆栈回收情况

这个是java 自带的便捷工具-gcutil 能够看到正常的回收情况，YGC应该是每次刷新都增加的，而对应于old区的FGC会较长时间执行一次。占用率在40%-50%是正常的。

二.使用java 自带jconsole 监控内存

修改了jboss 启动脚本的run.sh 增加配置端口9999

JAVA_OPTS="$JAVA_OPTS https://www.wendangku.net/doc/e84662364.html,=$PROGNAME -Dcom.sun.management.jmxremote.port=9999

-Dcom.sun.management.jmxremote.authenticate=false -Dcom

.sun.management.jmxremote.ssl=false"

注意：如果在run.sh 增加了这段配置，不要再在jbossctl再加一次，否则会被run.sh

覆盖掉，导致你找不到原因的连接不上。

增加了jboss 启动项jbossctl 的配置增加

JAVA_OPTS="$JAVA_OPTS https://www.wendangku.net/doc/e84662364.html,.preferIPv4Stack=true"

直接运行里面执行jconsole 数据远程连接地址端口10.20.147.59:9999 就可以了

如果内存短期内是在不断的波动略有上升趋势的，长时间执行时会有周期性的FGC，内存使用会突然下降下来，所以一般运行两个小时会有2-4个锯齿形状的线条，在所有压力测试完成后要能够正常回收，回收到300-400 M 就比较正常了。

三.Jboss 自带的工具

使用jboss 自带的jmx 进行一些辅助内存回收，辅助查看是否存在内存泄露

JMX服务可以通过HTTP、RMI、SNMP等多种协议进行访问，使其适合作为一个网络管理、监控平台的技术架构。看下是否存在内存泄露别的产品线700M 我们占用2G多

http://10.20.147.59/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Aty pe%3DServer

四.查看blocked 线程

grep 'BLOCKED' jboss_stdout.log –wc 可以查看下有多少BLOCKED的线程

NEW

至今尚未启动的线程处于这种状态。

RUNNABLE

正在Java 虚拟机中执行的线程处于这种状态。

BLOCKED

受阻塞并等待某个监视器锁的线程处于这种状态。

WAITING

无限期地等待另一个线程来执行某一特定操作的线程处于这种状态。

TIMED_WAITING

等待另一个线程来执行取决于指定等待时间的操作的线程处于这种状态。TERMINATED

已退出的线程处于这种状态。

五.Jmeter

QA性能测试阶段使用了Jmeter，并部署到性能测试环境（linux）下测试

JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现

六.Jprofile的监控

JProfiler 是一个著名的用于java 系统监控分析的软件，功能很强大。

通过对CPU的监控，可以明显看出在哪些地方消耗的时间较多，性能较差,通过对VM的监控，可以观察JBOSS内存使用情况

七.webTrace 监控WebTrace 使用不具体讲拉.

数据库性能指标

数据库种类 数据库性能指标 1查询性能 多用户与查询之前的冲突 硬件 然而并不是所有的数据库性能问题都是来自数据库本身，我们日常工作中最常见的另一个情景就是数据库的硬件有若干问题，这里我们简单的介绍一下可能会出现的情况，毕竟市面上有已经有很多工具可以监测这些问题了 1、没有足够的CPU或CPU速度太慢：更多的CPU可以分担服务器的负载，从而提高性能。 2、慢的磁盘没有足够的IOPS：磁盘性能可以描述为每秒输入/输出操作（IOPS），它表示每秒磁盘的吞吐量。 3、配置不正确的磁盘：数据库需要效果明显的磁盘访问，配置不正确的磁盘会造成相当大的性能影响。 4、没有足够的内存：受限或不好的物理内存影响数据库性能，可用的内存越多，性能越好。 1NOsql 数据库优点 处理大规模数据和高并发能力 缺点 1. 复杂的数据库：NoSQL的简洁，有效，速度，然而所有这些特性都表现在数据库任务很简单的时候。当数据库变得更复杂，NoSQL开始崩溃 。同时nosql相对sql方面行业标准还不成熟，SQL有行业标准接口，而每一个nosql都是独一无二的 2. 灵活的Schema设计：在以前的数据库模型中，程序员必须考虑他们所需要的列，以照顾所有的潜在的可能性和每行中的数据项。当使用NoSQL时，各种各样的字符串都能实现，这种灵活性使得程序员能够快速地提高应用的速度。然而，当有几个小组在同一个项目上工作，或者当新的开发团队接手某个项目时，这可能是个问题。 3. NoSQL数据库相比关系型数据库通常更多的是资源密集型。它们需要更多的内存和内存分配。出于这个原因，大多数主机托管公司不提供NoSQL，你必须使用VPS或专用服务器。另一方面，随着数据库的需求增加，硬件也必须扩展 4. 监控困难：相对于已经成熟的SQL，NoSQL现在的监控可以说是比较困难的，国内也只有听云一家公司能够支持主流的Memcached, MongoDB, Redis等非关系型数据库服务

性能测试结果分析

性能测试结果分析 分析原则： 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点） 查找瓶颈时按以下顺序，由易到难。 服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等） 注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。 分段排除法很有效 分析的信息来源： 1）根据场景运行过程中的错误提示信息 2）根据测试结果收集到的监控指标数据 一．错误提示分析 分析实例： 1）Error:Failed to connect to server “https://www.wendangku.net/doc/e84662364.html,″: [10060] Connection Error:timed out Error: Server “https://www.wendangku.net/doc/e84662364.html,″ has shut down the connection prematurely 分析： A、应用服务死掉。 （小用户时：程序上的问题。程序上处理数据库的问题） B、应用服务没有死 （应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％ C、数据库的连接 (1、在应用服务的性能参数可能太小了；2、数据库启动的最大连接数（跟硬件的内存有关）) 2）Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成 A、应用服务参数设置太大导致服务器的瓶颈 B、页面中图片太多 C、在程序处理表的时候检查字段太大多 二．监控指标数据分析 1．最大并发用户数： 应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。 在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。 如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。 2．业务操作响应时间： 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？ 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

性能测试测试方案

性能测试详细测试方案 、八、- 前言 平台XX项目系统已经成功发布，依据项目的规划，未来势必会出现业务系统中信息大量增长的态势。 随着业务系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：每天大数据量的“冲击”，系统能稳定在什么样的性能水平，面临行业公司业务增加时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。 1第一章XXX系统性能测试概述 1.1 被测系统定义 XXX系统作为本次测试的被测系统（注：以下所有针对被测系统地描述均为针对XXX系统进行的），XXX系统是由平台开发的一款物流应用软件，后台应用了Oraclellg数据库， 该系统包括主要功能有:XXX 等。在该系统中都存在多用户操作，大数据量操作以及日报、周报、年报的统计，在本次测试中，将针对这些多用户操作，大数据量的查询、统计功能进行如预期性能、用户并发、大数据量、疲劳强度和负载等方面的性能测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统的吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。1.1.1 功能简介 主要功能上面已提到，由于本文档主要专注于性能在这里功能不再作为重点讲述。 1.1.2 性能测试指标 本次测试是针对XXX系统进行的全面性能测试，主要需要获得如下的测试指标。 1、应用系统的负载能力：即系统所能容忍的最大用户数量，也就是在正常的响应时间中，系统能够支持的最多的客户端的数量。

2、应用系统的吞吐量：即在一次事务中网络内完成的数据量的总和，吞吐量指标反映的是服务器承受的压力。事务是用户某一步或几步操作的集合。 3、应用系统的吞吐率：即应用系统在单位时间内完成的数据量，也就是在单位时间内，应用系统针对不同的负载压力，所能完成的数据量。 4、T PS每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。 5、点击率：每秒钟用户向服务器提交的HTTP青求数。 5、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端请求发起，到服务器端应答返回所需要的时间，包括网络传输时间和服务器处理时间。 6、应用系统的可靠性：即在连续工作时间状态下，系统能够正常运行的时间，即在连续工作时间段内没有出错信息。 1.2系统结构及流程 XXX系统在实际生产中的体系结构跟本次性能测试所采用的体系结构是一样的，交易流 程也完全一致的。不过，由于硬件条件的限制，本次性能测试的硬件平台跟实际生产环境略有不同。 1.2.1系统总体结构 描述本系统的总体结构，包括：硬件组织体系结构、网络组织体系结构、软件组织体系结构和功能模块的组织体系结构。 1.2.2功能模块 本次性能测试中各类操作都是由若干功能模块组成的，每个功能都根据其执行特点分成 了若干操作步骤，每个步骤就是一个功能点（即功能模块），本次性能测试主要涉及的功能 模块以及所属操作如下表

Oracle数据库性能优化

1系统问题 XX公司BI系统上线运行以来，客户反映系统目前存在着下面的几个问题，涉及到数据库和ETL. 问题一：表空间增长太快，每个月需增加3—5G空间。 问题二：ETL JOB会经常导致数据库产生表空间不足错误。 2系统优化分析 2.1分析思路 要解决表空间的问题，我们必须搞清楚下面几个问题： 思路一：真正每个月数据仓库增量是多少空间 目的：得出一个正确的月表空间增长量。 思路二：目前的数据仓库表空间是是如何分布的。 目的：找出那些对象是最占空间，分析其合理性。 2.2分析过程 要得到真实的数据分布必须对表进行分析，首先需要对数据仓库的oracle数据库进行表分析，。执行下面脚本可以对数据库进行表分析。

脚本一 analyze table SA_IMS_PRODUCT_GROUP compute statistics; analyze table SA_CONSUMP_ACT_DEL compute statistics; analyze table SA_FINANCE_ACT compute statistics; analyze table SA_CONSUMP_TGT_DEL compute statistics; analyze table SA_FACT_IS compute statistics; analyze table SA_CPA compute statistics; analyze table SA_REF_TERR_ALIGNMENT_DEL compute statistics; analyze table SA_IMS_MTHLC_BK compute statistics; analyze table SA_IMS_CHPA compute statistics; analyze table SA_FINANCE_PNL compute statistics; analyze table SA_CUST_TARG_SEG compute statistics; analyze table SA_CONSUMP_ACT compute statistics; analyze table SA_FINANCE_BS compute statistics; analyze table SA_FINANCE_BGT_QTY compute statistics; analyze table SA_CONSUMP_ACT0423 compute statistics; analyze table SA_CALLS compute statistics; analyze table SA_COMPANY_DAILY_SALES_ALL compute statistics; analyze table SA_IMS_MTHLC compute statistics; analyze table SA_IMS_MTHUS compute statistics; analyze table SA_CONSUMP_TGT compute statistics; analyze table TEST_TABLE compute statistics; analyze table SA_DOCTOR_CYCLE_EXTRACT compute statistics; analyze table SA_EXCHANGE_ACT compute statistics;

性能测试常用分析及标准

服务响应的时间标准 参考了业内比较通行的“2-5-10原则”——当然你也可以为自己的测试制定其他标准，只要得到企业内的承认就可以。所谓的“2-5-10原则”，简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。 针对基础数据库添加企业信息： 添加10家企业，9家成功，1家失败，失败详细信息 Action.c(62): Error -26612: HTTP Status-Code=500 (Internal Server Error) for "http://202.117.99.211/basedatabasesite/PSInfo/IndustryFact/PSBaseInfoAdd.aspx? PSClassCode=1&%3f" Monitor name :Windows Resources. Cannot access data for measurement Processor|% Processor Time|_Total on machine 202.117.99.211. Details: 检测出一个含有负分母值的计数器。 Hint: Check that there is such a measurement on the machine (use the Add Machine dialog box) (entry point: CNtMeasurement::GetNewData3). [MsgId: MMSG-47295] 功能名称：企业基本信息维护，添加企业基本信息 10用户模拟并发操作： 系统响应时间：最短1.078秒最长4.901秒，属于可接受范围 资源使用情况： 内存分析： 其中： Handle Count(process _total)值由71030变化为71515 差值485bytes private bytes 值由2442407936变化为2469638144差值27230208bytes 变化范围约3M committed bytes 值由2625691648 变化为2652794880 差值27103232

软件开发系统性能测试报告

订单系统二期_Order接口 性能测试报告

目录 1.术语 (3) 2.测试环境 (3) 2.1服务器&客户端环境信息 (3) 3.测试场景 (4) 4.测试目的&策略 (5) 5.结果分析 (5) 5.1基本数据统计分析&对比 (5) 5.1.1.测试场景PT1 (5) 5.1.2.测试场景PT2 (5) 5.1.3.测试场景PT3 (6) 5.2.详细数据分析 (6) 5.2.1.测试场景PT1(getOrderList Interface） (6) 5.2.2.测试场景PT2(getOrderRow Interface) (9) 5.2.3.测试场景PT3(getOrderGoodsList) (14) 6.测试结论 (17)

1.术语 2.测试环境 2.1服务器&客户端环境信息 服务端配置： 10.19.141.57 应用服务器： CPU: Intel(R) Xeon(R) CPUE5620 @ 2.40GHz 8个逻辑CPU 内存：15GB 网卡: 1000M 操作系统: CentOS release 5.8 (Final) 辅助软件: nmon 10.19.141.58 数据库服务器： CPU: Intel(R) Xeon(R) CPUE5620 @ 2.40GHz 8个逻辑CPU 内存：8GB 网卡: 1000M 操作系统: CentOS release 5.8 (Final) 辅助软件: nmon 客户端配置：（2台） CPU:4核8线程Intel(R) Xeon(R) CPU E5620 @ 2.40GHz 内存：8.00GB 网卡: 1000M 操作系统: Windows2008 浏览器/版本号: IE9.0 测试工具: LoadRunner11.0、nmon

关系型数据库性能测试参考指标 - prettyyang的个人空间 - 51testing软

关系型数据库性能测试参考指标- prettyyang的个人空间- 51Testing软... 关系型数据库性能测试参考指标----SQL Server 注：以下指标取自SQL Server自身提供的性能计数器。 指标名称 指标描述 指标范围 指标单位1．SQL Server中访问方法（Access Methods）对象包含的性能计数器全表扫描/秒 (Full Scans/sec) 指每秒全表扫描的数量。全表扫描可以是基本表扫描或全索引扫描。由于全表扫描需要耗费大量时间，因此全表扫描的

频率过高的话，会影响性能。 如果该指标的值比1或2高，应该分析设计的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 次数/秒2．SQL Server中缓冲器管理器（Buffer Manager）对象包含的性能计数器缓冲区高速缓存命中率(BufferCache Hit Ratio%） 指在缓冲区高速缓存中找到而不需要从磁盘中读取的页的 百分比。该比率是缓存命中总次数与缓存查找总次数之比。经过很长时间后，该比率的变化很小。由于从缓存中读取数据比从磁盘中读取数据的开销小得多，一般希望该比率高一些。 该指标的值最好为90%或更高。通常可以通过增加SQL Server可用的内存数量来提高该指标的值。增加内存直到这指标的值持续高于90%，表示90%以上的数据请求可以从

数据缓冲区中获得所需数据。 %读的页/秒 (Page Reads/sec) 指每秒发出的物理数据库页读取数。该指标主要考察数据库从磁盘读取数据的频率。因为物理I/O会耗费大量时间，所以应尽可能地减少物理I/O以提高性能。 该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，以降低该指标的值。 个数/秒写的页/秒 (Page Writes/sec) 指每秒执行的物理数据库写的页数。该指标主要考察数据库

MySQL数据库性能(SQL)优化方案-期末论文

高级数据库技术——期末论文 基于SQL查询的MySQL数据库性能优化研究 ：XX 学号:2014XXXXX 学院：计算机学院

摘要： 查询是数据库系统中最基本也是最常用的一种操作，是否具有较快的执行速度，已成为数据库用户和设计者极其关心的问题。在研究开源数据库管理系统MySQL 查询优化技术的基础上，主要结合传统SQL操作优化、深度分析 MySQL 源代码、现代数据库发展几方面进行诸如参数调优，MySQL关联查询，重写相关规则等容展开优化分析研究。 关键词：查询优化，查询重用，查询重写，计划优化

一、传统SQL查询优化操作 1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2.使用连接（JOIN）来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示： DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo ) 使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，

Linux 性能测试与分析报告

Linux 性能测试与分析 Linux 性能测试与分析 Revision History 1 性能测试简介 l 性能测试的过程就是找到系统瓶颈的过程。 l 性能测试(包括分析和调优)的过程就是在操作系统的各个子系统之间取得平衡的过程。l 操作系统的各个子系统包括： ?CPU

?Memory ?IO ?Network 他们之间高度依赖，互相影响。比如： 1. 频繁的磁盘读写会增加对存的使用 2. 大量的网络吞吐，一定意味着非常可观的CPU利用率 3. 可用存的减少可能增加大量的swapping，从而使系统负载上升甚至崩溃 2 应用程序类型 性能测试之前，你首先需要判断你的应用程序是属于那种类型的，这可以帮助你判断哪个子系统可能会成为瓶颈。 通常可分为如下两种： CPU bound –这类程序，cpu往往会处于很高的负载，当系统压力上升时，相对于磁盘和存，往往CPU首先到达瓶颈。Web server，mail server以及大部分服务类程序都属于这一类。 I/O bound –这类程序，往往会频繁的访问磁盘，从而发送大量的IO请求。IO类应用程序往往利用cpu发送IO请求之后，便进入sleep状态，从而造成很高的IOWAIT。数据库类程序，cache服务器往往属于这种类型。 3 CPU

3.1 性能瓶颈 3.1.1 运算性能瓶颈 作为计算机的计算单元，其运算能力方面，可能出现如下瓶颈： 1. 用户态进程CPU占用率很高 2. 系统态(核态)CPU占用率很高 测试CPU的运算性能，通常是通过计算圆周率来测试CPU的浮点运算能力和稳定性。据说Pentium CPU的一个运算bug就是通过计算圆周率来发现的。圆周率的计算方法，通常是计算小数点后104万位，通过比较运算时间来评测CPU的运算能力。 常用工具： 1. SUPER PI(π) 2. Wprime 与SuperPI不同的是，可以支持多核CPU的运算速度测试 3. FritzChess 一款国际象棋测试软件，测试每秒钟可运算的步数 突破CPU的运算瓶颈，一般只能靠花钱。比如提高时钟频率，提高L1,L2 cache容量或不断追求新一代的CPU架构： Core -> Nehalem(E55x，如r710，dsc1100) -> Westmere –> Sandy Bridge 3.1.2 调度性能瓶颈 CPU除了负责计算之外，另一个非常重要的功能就是调度。在调度方面，CPU可能会出现如下性能瓶颈： 1. Load平均值超过了系统可承受的程度 2. IOWait占比过高，导致Load上升或是引入新的磁盘瓶颈 3. Context Switch过高，导致CPU就像个搬运工一样，频繁在寄存器(CPU Register)和运行队列(run queue)之间奔波 4. 硬中断CPU占比接近于100% 5. 软中断CPU占比接近于100% 超线程 超线程芯片可以使得当前线程在访问存的间隙，处理器可以使用它的机器周期去执行另外一个线程。一个超线程的物理CPU可以被kernel看作是两个独立的CPU。 3.2 典型监控参数 图1：top

网络优化测试报告

网络优化测试报告文档编制序号：[KKIDT-LLE0828-LLETD298-POI08]

测 试 业 务 区 路测数据分析报告 （） 目录 第一章网络概况.............................................................................................................................. 网络基本情况 ............................................................................................................................... 站点分布图 ................................................................................................................................... 测试方法介绍 ............................................................................................................................... 第二章测试结果及分析.................................................................................................................. RX P OWER ..................................................................................................................................... S TRONGEST E C/I O.......................................................................................................................... A GGREGATE E C/I O ......................................................................................................................... T X P OWER....................................................................................................................................... F-FCH FER .................................................................................................................................... TX A DJ........................................................................................................................................... 第三章网络性能统计.................................................................................................................... C ALL S ETUP R ATE.......................................................................................................................... C ALL D ROP R AT E ........................................................................................................................... H ANDOFF S TATISTICS R ESULT........................................................................................................ A IR I NTERFACE S ETUP D ELAY........................................................................................................ 第四章测试结论..............................................................................................................................

《Web项目测试实战》性能测试需求分析章节样章

5.1.2性能测试需求提取 复习了一些常见的理论概念后，我们开始性能测试需求的提取。这个过程是非常重要的，往往测试失败，就是因为在这个过程中不知道如何得到确切的性能指标，而导致测试无法正常开展。性能测试需求提取一般的流程如图5- 1所示。 图5- 1性能测试需求提取流程 分析提取指标 在用户需求规格说明书中，会给出系统的功能、界面与性能的要求。规范的需求规格说明书都会给出明确的性能指标，比如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，这些指标都会以可量化的数据进行说明。如果，实际项目并没有这些正规的文档时，项目经理部署测试任务给测试组长时，一般就会说明是否要对项目的哪些业务模块进行性能测试，以及测试的要求是什么的。最麻烦的就是项目经理或者客户要求给出一个测试部门认为可以的数据，这样非常难做的。可是“甲方”往往都是提要求的，“乙方”只能“无条件”接受！ 表5- 1需求规格说明书中的性能要求 表5- 1给出的指标非常明确，在测试过程中，我们只需收集用户登录模块的响应时间、登录成功率、并发数、CPU使用率、内存使用率的数据，然后与表5- 1的指标进行比较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。 大多数是没有明确的需求，需要我们自己根据各种资料、使用各种方法去采集测试指标。以OA系统为例，假设《OA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试工程师自己分析被测系统及采集性能衡量指标。 分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终用户经常使用的业务点，那么我们的重点应该在放在该模块上。一般我们可以从下面三个方面来确定性能测试点： 第一、用户常用的功能。常用的功能一旦性能无法满足，比如登录功能，从输入用户名与密码点击登录按钮到显示成功登录信息，花了5分钟，这样的速度是 人无法忍受的。而对于用户不常用的，比如年度报表汇总功能，三个季度甚 至是一年才使用，等个10分钟也是正常的，这些是跟用户的主观感受相关 的，得根据实际情况区分。

数据库集群技术指标

1.DBTwin技术指标 A.非入侵部署 与所有的系统服务一样,DBTwin也是通过唯一的入口-一对(IP,port)来向外提供数据服务。因此,应用程序及其数据库接口不需作任何修改。支持所有的数据库接口：https://www.wendangku.net/doc/e84662364.html,、ADO、RDO、DAO、OLE DB、ODBC、DB-LIBRARY等。 B.支持数据库 Microsoft SQL Server2005/2008的标准版和企业版。 C.事务处理同步复制 通过常用的宽带网络,快速的事务处理同步复制 D.高系统可用性 自动的错误恢复，真正把意料之内和意料之外的停机时间缩至最短。网关在错误恢复期间的停止服务间隙达到小于10秒。 E.零单点错误源 从DBTwin网关这一部件开始，整个数据库系统是完全、彻底地物理冗余。 F.数据“零”丢失 DBTwin使得系统同时拥有多个实时一致的数据集，这样从理论上讲，就真正消除了数据丢失的任何可能性。数据库可靠性达到目5个9，即99.999%。 G.动态负载均衡 DBTwin对只读数据库查询操作可以进行自动的判别和动态负载均衡，这是当前唯一实现的针对数据库的动态负载均衡技术，此技术可以大大改善整个数据库系统的性能。性能提升在30%~300%之间，具体提升比例取决于应用系统及网络结构和软硬的配置。 H.可伸缩性 可伸缩的数据库性能(负载均衡+非入侵式的数据库阵列扩展)，使得数据库具有可伸缩性。需要更多的数据库性能的时候，只要增加数据库服务器就可以了。 I.容灾能力 具备即时的灾难恢复能力。 J.DBTwin自身的双机容错

DBTwin支持自身的双机主备容错切换，也可以采用第三方的HA方案解决DBTwin 自身的容错问题。 DBTwin备份(复制)软件镜像1专为数据库设计是否否 2支持数据库集群是部分支持部分支持 3支持并发数据库操作是否否 4支持动态负载均衡是部分支持部分支持 5工作方式并行串行串行 6支持多份数据集是是是 7支持多份一致数据集是否否 7单点错误源无有有 8支持业务连续性程度高低中 9数据丢失可能性零高高 10错误恢复自动化程度高低中 2.DBTwin与备份/复制软件，及数据库镜像的功能、特点比较

性能测试分析报告案例

***系统性能测试报告 V1.0 撰稿人：******* 时间：2011-01-06

目录 1.测试系统名称及测试目标参考 (3) 2.测试环境 (3) 3.场景设计 (3) 3.1测试场景 (3) 3.1测试工具 (4) 4.测试结果 (4) 4.1登录 (4) 4.2发送公文 (6) 4.3收文登记 (8)

1.测试系统名称及测试目标参考 被测系统名称：*******系统 系统响应时间判断原则（2-5-10原则）如下： 1)系统业务响应时间小于2秒，用户对系统感觉很好； 2)系统业务响应时间在2-5秒之间，用户对系统感觉一般； 3)系统业务响应时间在5-10秒之间，用户对系统勉强接受； 4)系统业务响应时间超过10秒，用户无法接受系统的响应速度。 2.测试环境 网络环境：公司内部局域网，与服务器的连接速率为100M，与客户端的连接速率为10/100M 硬件配置： 3.场景设计 3.1测试场景 间

间 间 3.1测试工具 ●测试工具：HP LoadRunner9.0 ●网络协议：HTTP/HTTPS协议 4.测试结果 4.1登录 ●运行1小时后实际登录系统用户数，用户登录后不退出，一直属于在线状态，最 终登录的用户达到9984个；

●响应时间 ●系统资源

服务器的系统资源表现良好（CPU使用率为14%，有15%的物理内存值）。磁盘等其他指标都表现正常，在现有服务器的基础上可以满足9984个在线用户。 4.2发送公文 运行时间为50分钟，100秒后300个用户全部加载成功，300个用户开始同时进行发文，50分钟后，成功发文数量如下图所示，成功发文17792个，发文失败37 个；

系统调优性能测试报告

XXXXX项目 压力测试报告 2015-10-16 XXXXXX技术有限公司文档信息

批复信息 版本记录

1简介 1.1 文档目的 本测试报告为性能对比测试报告，目的在于总结测试的工作进展情况并分析测试结果，描述本阶段测试是否达到调优预期目标，符合需要要求。 1.2 面向人员 本文档主要面向XX系统用户、测试人员、开发人员、项目管理人员和需要阅读本报告的相关领导。 1.3 参考文档 1.4 术语 1. 每秒事务数（TPS）：是指每秒钟完成的事务数，事务是事先在脚本中定义的统计单元； 2. 事务平均响应时间（ART）：响应时间一般反映了在并发情况下，客户端从提交请求到接受到应答所经历的时间； 3. 资源利用率：是指在不影响系统正常运行的情况下各服务器的CPU、内存等硬件资源的占用情况； 4. 最大并发用户数：系统所能承受的最大并发用户数；

5. 思考时间（Thinktime）：用于模拟实际用户在不同操作之间等待的时间。例如，当用户收到来自服务器的数据时，可能要等待几秒钟查看数据，然后做出响应，这种延时就称为“思考时间”。 2第一轮测试目标 根据项目情况，本次测试的目的主要是解决XX系统个人系统登录和理财交易的处理能力达到客户正常使用要求，根据测试结果评估系统性能，为生产运行提供参考。 1）分析目前系统登录与理财的处理能力； 2）提高登录和理财交易处理能力，达到客户流畅使用的目的； 3第二轮测试安排 1、对整体系统运行环境、系统自身交易功能进行全面分析。通过 压力测试手段优化系统，提高运行效率，并给出未来三到五年 资源配置计划，制定后续保障机制。 2、计划从十月十九日开始方案讨论。

(完整版)数据库性能测试报告

数据库系统性能测试报告

目录 1计划概述 (3) 2参考资料 (3) 3术语解释 (3) 4系统简介 (3) 5测试环境 (3) 6测试指标 (4) 7测试工具和测试策略 (4) 8测试数据收集 (4) 9测试结果数据以及截图 (5) 10 测试结论 (10)

1计划概述 目的：找出系统潜在的性能缺陷 目标：从安全，可靠，稳定的角度出发，找出性能缺陷，并且找出系统最佳承受并发用户数，以及并发用户数下长时间运行的负载情况，如要并发100用户，如何对系统进行调优 概述：本次测试计划主要收集分析数据库处理并发请求相关数据，做出分析和调优 测试时间：*年*月**日*点*分-*点*分 2参考资料 相关性能测试资料 3术语解释 性能测试 英文解释：Performance testing 概念解释：运行性能测试确定系统处理能力，来判断系统是否需要优化 负载测试 英文解释：Load testing 概念解释：通过系统面临多资源运行或被攻击情况下进行测试 4系统简介 数据库服务器，支持整个系统对数据的存储过程 5测试环境

器 6测试指标 测试时间：*年*月*日—*年*月*日 测试范围：数据库处理服务器或客户端请求信息(插入，查询，更新，删除)语句时，服务器各项性能指标的性能测试 Jmeter指标：（由于Apache旗下性能测试工具Jmeter收集的性能指标偏少，下面的数据选取代表性指标）1．Average/ms：服务器处理事物平均响应时间（表示客户端请求到服务器处理信息且反馈客户端的时间） 2．Throughput/s：服务器每秒处理请求数（表示服务器每秒处理客户端请求数（单位：个/秒））3．KB/s：服务器每秒接受到的数据流量（表示服务器每秒接受到客户端请求的数据量KB表示）硬件指标： 1．%Processor time ：CUP使用率（平均低于75%，低于50%更佳） 2．System：Processor Queue Length ：CUP队列中的线程数（每个处理器平均低于2） 3．Memory：Pages/sec ：内存错误页数（平均低于20，低于15更佳） 4．Physical Disk-%Disk Time：磁盘使用率（平均低于50%） 5．SQL Server：Buffer Manager-Buffer Cache Hit Ratio：（在缓冲区告诉缓存中找到而不需要从磁盘中读取的页的百分比，正常情况次比率超过90%，理想状态接近99%） 7测试工具和测试策略 ?测试工具：Apache-Jmeter2.3.2 ?测试策略：根据公司内部实际情况，以及业务分布设置数据库访问量即并发用户数 ?测试数据：因为涉及公司内部数据不便外泄，敬请见谅！ ?数据说明：选取数据均为代表性数据，包括存储过程以及查询，更新，删除，插入 8测试数据收集 收集多轮测试的结果进行对比，绘制成几何增长图形，找出压力转折点

oracle数据库性能调优

Centos6.5操作系统下，oracle数据库性能调优 1.在liunx下对数据库性能调优，首先要考虑操作系统级别的问题如：如CPU、内存、IO的瓶颈，再考虑oracle本身参数的设置。 1. 可通过top 命令判断是否为CPU瓶颈，如果oracle进程占用CPU过多，可考虑为CPU的问题。 目前我们针对的主要是内存和磁盘的问题。 2.Oracle数据库内存参数的优化 ?与oracle相关的系统内核参数 ?SGA、PGA参数设置 （1）系统内核参数 修改/etc/sysctl.conf 这个文件，加入以下的语句： kernel.shmmax = 2147483648 kernel.shmmni = 4096 kernel.shmall = 2097152 kernel.sem = 250 32000 100 128 fs.file-max = 65536 参数依次为： Kernel.shmmax:共享内存段的最大尺寸（以字节为单位）。 Kernel.shmmni：系统中共享内存段的最大数量。 Kernel.shmall：共享内存总量，以页为单位。 fs.file-max：文件句柄数，表示在Linux系统中可以打开的文件数量。 net.ipv4.ip_local_port_range：应用程序可使用的IPv4端口范围。 可通过sysctl -p 查看内核参数的值，请确认各个内核参数只有一个，避免出现一个内核参数出现好几次的情况，导致正确的参数别覆盖。

需要注意的几个问题 关于Kernel.shmmax Oracle SGA 由共享内存组成，如果错误设置SHMMAX可能会限制SGA 的大小，SHMMAX设置不足可能会导致以下问题：ORA-27123:unable to attach to shared memory segment，如果该参数设置小于Oracle SGA设置，那么SGA就会被分配多个共享内存段。这在繁忙的系统中可能成为性能负担，带来系统问题。 Oracle建议Kernel.shmmax最好大于sga，以让oracle共享内存区SGA在一个共享内存段中，从而提高性能。 Oracle 11g实现了数据库所有内存块的全自动化管理，使得动态管理SGA和PGA成为现实。 日志文件及表空间文件的大小及位置也是影响性能的一个因素，排查过程如下。 应用 iotop -ao 命令查看oracle对磁盘读写对资源的占用情况， ora_lgwr_first进行对磁盘的访问较多。 使用

网络性能测试与分析 林川 复习整理

网络性能测试与分析（林川）复习整理对一台具有三层功能的防火墙进行测试，可以参考哪些和测试相关的RFC文档 RFC3511、RFC3222、RFC2889、RFC2544 包头的最大长度为多少为什么IP 字节4060答：字节，固定部分20字节，可变部分 在数据传输层面，用以衡量路由器性能的主要技术指标有哪些 ）背（65）丢包率；（4）背对背；（）时延抖动；）延迟；1 答：（）吞吐量；（2（3）系统恢复。8）系统恢复；板能力；（7（ 什么是吞吐量简述吞吐量测试的要点 路由设备说明书和性能测试文答：吞吐量是描述路由器性能优劣的最基本参数，档中都包含该参数。是指在没有丢包的情况下，路由设备能够转发的最大速率。要规定延迟测试发包速率要小于吞吐量什么是延迟为什么RFC2544点：零丢包率。 延迟是指包的第一个比特进入路由器到最后一个比特离开路由器的时间间隔，答： 又叫时延。 丢包率测试的目的是什么简述丢包率与吞吐量之间的关系 在不同的负载和帧长度条件下的丢包率。DUT 答：丢包率测试的目的是确定 什么是背对背什么情况下需要进行背对背测试 答：背对背指的是在一段较短的时间内，以合法的最小帧间隙在传输

介质上连续发送固定长度的包而不引起丢包时的包数量，IEEE规定的以太网帧间的最小帧间隙为96比特。该指标用于测试路由器缓存能力。 大量的路由更新消息、频繁的文件传送和数据备份等操作都会导 致数据在一段时间内急剧增加，甚至达到该物理介质的理论速率。为了描述此时路由器的表现，就要进行背对背突发的测试。 吞吐量：是指在没有丢包的情况下，路由设备能够转发的最大速率。对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。 延迟：是指包的第一个比特进入路由器到最后一个比特离开路由器的时间间隔，又叫时延。 丢包率：是指路由器在稳定负载状态下，由于缺乏资源而不能被网络设备转发的包占所有应该被转发的包的百分比。丢包率的衡量单位是以字节为计数单位，计算被落下的包字节数占所有应该被转发的包字节数的百分比。背对背：是指在一段较短的时间内，以合法的最小帧间隙在传输介质上连续发送固定长度的包而不引起丢包时的包数量，IEEE规定的以太网帧间的最小帧间隙为96比特。 转发率：通过标定交换机每秒能够处理的数据量来定义交换机的处理能力。交换机产品线按转发速率来进行分类。若转发速率较低，则无法支持在其所有端口之间实，即）Mpps现全线速通信。包转发速率是指交换机每秒可以转发多少百万个数据包（． 交换机能同时转发的数据包的数量。包转发率以数据包为单位体现了交换机的交换能力。路由器的包转发率，也称端口吞吐量，是指路由器在某