目录
JDK优化 (2)
如何修改默认Java调用的JVM.dll版本? (2)
测试实例 (3)
选择合适的JDK版本 (3)
垃圾收集Java堆的优化 (4)
Tomcat性能监控与优化 (5)
监控 (5)
Tomcat监控页面 (5)
JMX (5)
内存使用调整（Out of Memery问题） (9)
连接线程数调整（cannot connect to server问题） (9)
connectionTimeout (11)
是否是整个连接处理的时间？ (11)
用telnet收工测试 (12)
直接写Socket做测试 (12)
acceptCount – 最大排队数 (13)
Tomcat Native library (15)
Connector (17)
oracle性能监控、诊断分析与调优 (20)
监控方法 (20)
方法1：在LR的Controller中配置监视Oracle (20)
方法2：使用SiteScope (25)
方法3：使用Oracle企业管理器查看数据库性能 (26)
方法4：使用Spotlight (27)
计数器 (27)
sorts(disk)(V$SYSSTAT) (27)
sort(memory)(V$SYSSTAT) (28)
db block gets (V$SYSSTAT) (29)
parse count (hard)(V$SYSSTAT) (31)
CPU used by this session(V$SYSSTAT) (35)
跟踪诊断和优化SQL语句 (36)
Oracle索引问题诊断与优化 (41)
p6spy监控和跟踪SQL语句 (43)
JSP、Servlet性能优化 (44)
Servlet常见性能问题分析与优化 (45)
Servlet中利用init()方法进行高速缓存 (45)
Servlet压缩输出 (47)
JSP常见性能问题分析与优化 (49)
选择正确的页面包含机制 (49)
屏蔽Page Session (49)
正确地确定javabean的生命周期 (51)
控制Session的时间 (52)
Java代码性能监控与性能问题定位 (53)
内存泄漏检测 (53)
JVM内存泄漏分析 (61)
认识JVM (61)
JVM启动参数介绍 (63)
JVM性能瓶颈 (64)
JVM内存泄漏实例一 - PermGen溢出 (64)
JVM内存泄漏实例二 - Heap溢出 (65)
JVM内存泄漏实例三 - 垃圾回收时promotion failed (65)
实例-JProfile跟踪内存泄漏 (67)
log4j性能诊断与优化 (75)
代码效率性能测试与优化 (79)
线程死锁 (79)
线程竞争 (81)
算法效率 (82)
JDK优化
Jvm动态库有client和server两个版本，分别针对桌面应用和服务器应用做了相应的优化，client版本加载速度较快，server版本加载速度较慢但运行起来较快。
%JA V A_HOME%/jre/bin/client/jvm.dll
%JA V A_HOME%/jre/bin/server/jvm.dll
可以看到这两个jvm.dll的大小不同。
如何修改默认Java调用的JVM.dll版本?
在命令行 java -version 可以看到jvm配置的是哪个版本。
更改默认java.exe调用的jvm.dll,这个由jvm.cfg决定。编辑%JA V A_HOME%jre/lib/i386/jvm.cfg
里面第一行写的是 -client 默认就是client版本，把第二行的-server KNOWN 放到第一行，如下面所示：
-server KNOWN
-client KNOWN
-hotspot ALIASED_TO -client
-classic WARN
-native ERROR
-green ERROR
测试实例
测试环境：
Tomcat5.5.28
jdk1.6.0_13
测试应用程序：
jpetstore5
测试目的：
对比jdk中采用client和server版本的jvm的性能区别
测试场景：
访问主页面
登录
查看宠物
添加宠物到购物车
结账
退出
100个并发用户运行1分钟左右
测试结果：
Client版本的JVM比Server版本的在大部分事务的平均响应时间上反而略为快点。
在《J2EE性能测试》这本书中也得到类似的结果：
JDK 1.3 HotSpot Server 2267ms
JDK 1.3 HotSpot Client 926ms
JDK 1.3 Classic 537ms
JDK 1.22 186ms
138ms
1.3
IBM
JRockit 3.1 137ms
选择合适的JDK版本
不同版本的JDK，甚至不同厂家的JDK可能都存在着很大的差异，对于性能优化的程度不同。一般来说，尽可能选择最新发布的稳定的JDK版本。最新的稳定的JDK版本相对以前的JDK版本都会做一些bug的修改和性能的优化工作。
可以选择自己的需要选择不同的操作系统和对应的JDK的版本（只要是符合Sun发布的Java规范的），但推荐使用Sun公司发布的JDK。确保所使用的版本是最新的，因为Sun
公司和其它一些公司一直在为提高性能而对java虚拟机做一些升级改进。一些报告显示JDK1.4在性能上比JDK1.3提高了将近10%到20%。
垃圾收集Java堆的优化
垃圾收集就是自动释放不再被程序所使用的对象的过程。当一个对象不再被程序所引用时，它所引用的堆空间可以被回收，以便被后续的新对象所使用。垃圾收集器必须能够断定哪些对象是不再被引用的，并且能够把它们所占据的堆空间释放出来。如果对象不再被使用，但还有被程序所引用，这时是不能被垃圾收集器所回收的，此时就是所谓的“内存泄漏”。监控应用程序是否发生了内存泄漏，有一个非常优秀的监控工具推荐给大家——Quest公司的JProbe工具，使用它来观察程序运行期的内存变化，并可产生内存快照，从而分析并定位内存泄漏的确切位置，可以精确定位到源码内。这个工具的使用我在后续的章节中还会做具体介绍。
Java堆是指在程序运行时分配给对象生存的空间。通过-mx/-Xmx和-ms/-Xms来设置起始堆的大小和最大堆的大小。根据自己JDK的版本和厂家决定使用-mx和-ms或-Xmx和-Xms。Java堆大小决定了垃圾回收的频度和速度，Java堆越大，垃圾回收的频度越低，速度越慢。同理，Java堆越小，垃圾回收的频度越高，速度越快。要想设置比较理想的参数，还是需要了解一些基础知识的。 Java堆的最大值不能太大，这样会造成系统内存被频繁的交换和分页。所以最大内存必须低于物理内存减去其他应用程序和进程需要的内存。而且堆设置的太大，造成垃圾回收的时间过长，这样将得不偿失，极大的影响程序的性能。以下是一些经常使用的参数设置：
1) 设置-Xms等于-XmX的值；
2) 估计内存中存活对象所占的空间的大小，设置-Xms等于此值，-Xmx四倍于此值；
3) 设置-Xms等于-Xmx的1/2大小；
4) 设置-Xms介于-Xmx的1/10到1/4之间；
5) 使用默认的设置。
需要根据自己的运行程序的具体使用场景，来确定最适合自己的参数设置。除了-Xms 和-Xmx两个最重要的参数外，还有很多可能会用到的参数，这些参数通常强烈的依赖于垃圾收集的算法，所以可能因为JDK的版本和厂家而有所不同。但这些参数一般在Web开发中用的比较少，就不做详细介绍了。在实际的应用中注意设置-Xms和-Xmx使其尽可能的优化应用程序就行了。对于性能要求很高的程序，就需要自己再多研究研究Java虚拟机和垃圾收集算法的机制了。可以看看曹晓钢翻译的《深入Java虚拟机》一书。
Tomcat性能监控与优化
监控
D:\PrefTest\案例\Tomcat调优\Tomcat性能监控.pdf
Tomcat监控页面
JMX
JMX(Java Management Extensions)是一个为应用程序植入管理功能的框架。JMX是一套标准的代理和服务，实际上，用户可以在任何Java应用程序中使用这些代理和服务实现管理。可以利用JDK的JConsole来访问Tomcat JMX接口实施监控，具体步骤如下：
首先，打开tomcat5的bin目录中的catalina.bat文件，在头部注释部分的后面加上：
set JAVA_OPTS=%JAVA_OPTS% ‐Dcom.sun.management.jmxremote.port=8999 ‐Dcom.sun.management.jmxremote.authenticate=false
‐Dcom.sun.management.jmxremote.ssl=false
如果已经配置好，则可使用JConsole打开监控平台查看Tomcat性能。
Linux下配置catalina.sh的例子：
JAVA_OPTS='-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8999
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=192.168.0.106'
由于JMX提供的接口是任何Java程序都可以调用访问的，因此我们可以编写JAVA程序来收集Tomcat性能数据，具体代码如下所示：
import https://www.doczj.com/doc/855278129.html,ng.management.MemoryUsage;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Formatter;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import javax.management.MBeanAttributeInfo;
import javax.management.MBeanInfo;
import javax.management.MBeanServerConnection;
import javax.management.ObjectInstance;
import javax.management.ObjectName;
import https://www.doczj.com/doc/855278129.html,positeDataSupport;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
public class MonitorTomcat {
/**
* @param args
*/
public static void main(String[] args) {
try {
String jmxURL = "service:jmx:rmi:///jndi/rmi://192.168.0.106:8999/jmxrmi";//tomcat jmx url
JMXServiceURL serviceURL = new JMXServiceURL(jmxURL);
Map map = new HashMap();
String[] credentials = new String[] { "monitorRole" , "QED" };
credentials);
map.put("jmx.remote.credentials",
JMXConnector connector = JMXConnectorFactory.connect(serviceURL, map);
MBeanServerConnection mbsc = connector.getMBeanServerConnection();
ObjectName threadObjName = new ObjectName("Catalina:type=ThreadPool,name=http-8080");
mbsc.getMBeanInfo(threadObjName);
=
MBeanInfo
mbInfo
String attrName = "currentThreadCount"; //tomcat的线程数对应的属性值
MBeanAttributeInfo[] mbAttributes = mbInfo.getAttributes();
attrName));
System.out.println("currentThreadCount:"+mbsc.getAttribute(threadObjName,
//heap
for(int j=0;j System.out.println("###########"+mbsc.getDomains()[j]); } Set MBeanset = mbsc.queryMBeans(null, null); System.out.println("MBeanset.size() : " + MBeanset.size()); MBeansetIterator = MBeanset.iterator(); Iterator while (MBeansetIterator.hasNext()) { ObjectInstance objectInstance = (ObjectInstance)MBeansetIterator.next(); ObjectName objectName = objectInstance.getObjectName(); String canonicalName = objectName.getCanonicalName(); System.out.println("canonicalName : " + canonicalName); (canonicalName.equals("Catalina:host=localhost,type=Cluster")) { if cluster MBeans of details Get // Details:"); System.out.println("Cluster MBeans System.out.println("========================================="); //getMBeansDetails(canonicalName); objectName.getCanonicalKeyPropertyListString(); = canonicalKeyPropList String } } //‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ system ‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ObjectName runtimeObjName = new ObjectName("https://www.doczj.com/doc/855278129.html,ng:type=Runtime"); System.out.println("厂商:"+ (String)mbsc.getAttribute(runtimeObjName, "VmVendor")); System.out.println("程序:"+ (String)mbsc.getAttribute(runtimeObjName, "VmName")); System.out.println("版本:"+ (String)mbsc.getAttribute(runtimeObjName, "VmVersion")); Date starttime=new Date((Long)mbsc.getAttribute(runtimeObjName, "StartTime")); SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); System.out.println("启动时间:"+df.format(starttime)); Long timespan=(Long)mbsc.getAttribute(runtimeObjName, "Uptime"); System.out.println("连续工作时间:"+MonitorTomcat.formatTimeSpan(timespan)); //-------------------------JVM--------------------------------- //堆使用率 ObjectName heapObjName = new ObjectName("https://www.doczj.com/doc/855278129.html,ng:type=Memory"); MemoryUsage heapMemoryUsage = MemoryUsage.from((CompositeDataSupport)mbsc.getAttribute(heapObjName, "HeapMemoryUsage")); long maxMemory = heapMemoryUsage.getMax(); //堆最大 long commitMemory = heapMemoryUsage.getCommitted(); //堆当前分配 long usedMemory = heapMemoryUsage.getUsed(); // 堆使用率 System.out.println("heap:"+(double)usedMemory*100/commitMemory+"%"); MemoryUsage nonheapMemoryUsage = MemoryUsage.from((CompositeDataSupport)mbsc.getAttribute(heapObjName, "NonHeapMemoryUsage")); long noncommitMemory = nonheapMemoryUsage.getCommitted(); long nonusedMemory = heapMemoryUsage.getUsed(); System.out.println("nonheap:"+(double)nonusedMemory*100/noncommitMemory+"%"); ObjectName permObjName = new ObjectName("https://www.doczj.com/doc/855278129.html,ng:type=MemoryPool,name=Perm Gen"); MemoryUsage permGenUsage = MemoryUsage.from((CompositeDataSupport)mbsc.getAttribute(permObjName, "Usage")); long committed = permGenUsage.getCommitted();//持久堆大小 long used = heapMemoryUsage.getUsed();// gen:"+(double)used*100/committed+"%");//持久堆使用率 System.out.println("perm //‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Session ‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐ ObjectName managerObjName = new ObjectName("Catalina:type=Manager,*"); Set for (ObjectName obj:s){ System.out.println("应用名:"+obj.getKeyProperty("path")); ObjectName(obj.getCanonicalName()); objname=new ObjectName System.out.println("最大会话数:"+ mbsc.getAttribute( objname, "maxActiveSessions")); System.out.println("会话数:"+ mbsc.getAttribute( objname, "activeSessions")); System.out.println("活动会话数:"+ mbsc.getAttribute( objname, "sessionCounter")); } //‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Thread Pool ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐ ObjectName threadpoolObjName = new ObjectName("Catalina:type=ThreadPool,*"); Set for (ObjectName obj:s2){ System.out.println("端口名:"+obj.getKeyProperty("name")); ObjectName(obj.getCanonicalName()); objname=new ObjectName System.out.println("最大线程数:"+ mbsc.getAttribute( objname, "maxThreads")); System.out.println("当前线程数:"+ mbsc.getAttribute( objname, "currentThreadCount")); System.out.println("繁忙线程数:"+ mbsc.getAttribute( objname, "currentThreadsBusy")); } } catch (Exception e) { e.printStackTrace(); } } public static String formatTimeSpan(long span){ long minseconds = span % 1000; span = span /1000; long seconds = span % 60; span = span / 60; long mins = span % 60; span = span / 60; long hours = span % 24; span = span / 24; long days = span; return (new Formatter()).format("%1$d天 %2$02d:%3$02d:%4$02d.%5$03d", days,hours,mins,seconds,minseconds).toString(); } } 内存使用调整（Out of Memery问题） Tomcat 默认可以使用的内存为 128MB ，在较大型的应用项目中，这点内存是不够的，需要调大。 Windows 下，在文件 {tomcat_home}/bin/catalina.bat ， Unix 下，在文件{tomcat_home}/bin/catalina.sh 的前面，增加如下设置： JA V A_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】 ' 需要把这个两个参数值调大。例如： rem ----- Execute The Requested Command --------------------------------------- set JA V A_OPTS='-Xms256m -Xmx512m' 表示初始化内存为 256MB ，可以使用的最大内存为 512MB 可用JDK附带的Jconsole查看tomcat的内存使用情况。 连接线程数调整（cannot connect to server问题） 优化tomcat配置：maxThreads="500" minSpareThreads="400" maxSpareThreads="450"。 maxThreads This is the maximum number of threads allowed. This defines the upper bound to the concurrency, as Tomcat will not create any more threads than this. If there are more than maxThreads requests, they will be queued until the number of threads decreases. Increasing maxThreads increases the capability of Tomcat to handle more connections concurrently. However,threads use up system resources. Thus, setting a very high value might degrade performance, and could even cause Tomcat to crash. It is better to deny some incoming connections, rather that affect the ones that are being currently serviced. maxSpareThreads This is the maximum number of idle threads allowed. Any excess idle threads are shut down by Tomcat. Setting this to a large value is not good for performance; the default (50) usually works for most Web sites with an average load. The value of maxSpareThreads should be greater than minSpareThreads, but less than maxThreads. minSpareThreads This is the minimum number of idle threads allowed. On Tomcat startup, this is also the number of threads created when the Connector is initialized.If the number of idle threads falls below minSpareThreads, Tomcat creates new threads. Setting this to a large value is not good for performance, as each thread uses up resources. The default (4) usually works for most Web sites with an average load. Typically, sites with “bursty” traffic would need higher values for Tomcat6使用默认的配置，在进行压力测试时，老是报错，用Jmeter模拟40个用户并发时，正常，当超过60个时，居然全部报错，打开server.xml可以看到如下配置： connectionTimeout="20000" redirectPort="8443" /> Tomcat的官方网站的解释如下， maxThread如果没有set，默认值为200. The maximum number of request processing threads to be created by this Connector , which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool. 这个就产生问题了，打开Tomcat的源码发现默认值是40，而不是200，所以压力测试时遇到同类的问题，大家一定要注意，添加以下配置： connectionTimeout="20000" redirectPort="8443" maxThreads="150"/> Tomcat7实验： 一、测试JSP页面： http://192.168.1.101:8080/examples/jsp/jsp2/el/basic-arithmetic.jsp 1、默认配置（maxThreads=200） VU：50 RT：0.072 2、maxThreads=10 VU：50 RT：0.072 3、maxThreads=5 VU：50 RT：0.081 4、maxThreads=1 VU：50 RT：10.423 二、测试JPetStore主页面： http://192.168.1.101:8080/jpetstore/shop/index.shtml 1、maxThreads=5 VU：50 RT：0.355 VU：50 RT：0.369 3、maxThreads=3 VU：50 RT：0.559 4、默认配置（maxThreads=200） VU：50 RT：0.390 5、maxThreads=3 VU：50（Rendezvous） RT：2.609 6、maxThreads=50 VU：50（Rendezvous） RT：0.597 connectionTimeout 单位是毫秒，Connector从接受连接到提交URI的等待的时间。 https://www.doczj.com/doc/855278129.html,/tomcat-5.5-doc/config/http.html The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. The default value is 60000 (i.e. 60 seconds). 现象：线上系统中tomcat的连接超时（connectionTimeout）设置成60ms，造成第三方访问公司的服务，总是502异常（502 Bad Gateway）。 这个设置在$tomcat/conf/server.xml中： maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="2000" disableUploadTimeout="true" />是否是整个连接处理的时间？ 写了一个servlet，doGet先sleep一段时间，再写一个输出，直接用浏览器访问。 经过测试，发现和这个时间无关。 用telnet收工测试 直接用telnet连上tomcat，如果什么都不输入，socket很快回断开，输入完整GET。。。，能够获得输出。如果不保持输入，则连接很快会断开。如果一直不停输入，连接继续保持。 $ telnet localhost 8080 GET /index.jsp HTTP/1.1 Accept-Language: zh-cn Connection: Keep-Alive Host: 192.168.0.53 Content-Length: 36 直接写Socket做测试 还是2s超时，睡一秒能够正确获得输出，睡2秒，输出为空。 以下是Groovy代码 content ='''GET /index.jsp HTTP/1.1 Accept-Language: zh-cn Connection: Keep-Alive Host: 192.168.0.53 Content-Length: 36 ''' def sleepTime=1000 Socket socket = new Socket('localhost',8080) println 'is keep alive? ' + socket.getKeepAlive() println 'sleep ' + sleepTime + ' ms.' Thread.sleep(sleepTime) println 'is closed? ' + socket.isClosed() println 'sleep ' + sleepTime + ' ms.' //Thread.sleep(sleepTime) println 'write socket begin======' writeStream(content, socket.getOutputStream()) println 'read socket begin======' println readStream(socket.getInputStream())[0..300] void writeStream(content, stream) { OutputStream buf = new BufferedOutputStream(stream); OutputStreamWriter out = new OutputStreamWriter(buf, "UTF-8"); out.write(content) out.flush(); print content //out.close(); } String readStream(stream){ String sResult='' byte[] buffer = new byte[1024]; int readCount = stream.read(buffer); while (readCount != -1) { sResult += new String(buffer, 0, readCount, "utf-8"); readCount = stream.read(buffer); } stream.close() return sResult } acceptCount – 最大排队数 The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100. 配置例子如下： connectionTimeout="20000" redirectPort="8443" maxThreads="800" acceptCount="1000"/> maxThreads：tomcat起动的最大线程数，即同时处理的任务个数，默认值为200 acceptCount：当tomcat起动的线程数达到最大时，接受排队的请求个数，默认值为100 这两个值如何起作用，请看下面三种情况 情况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。 情况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。 情况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请 求个数也达到了acceptCount，此时tomcat会直接拒绝此次请求，返回connection refused maxThreads如何配置 一般的服务器操作都包括量方面：1计算（主要消耗cpu），2等待（io、数据库等） 第一种极端情况，如果我们的操作是纯粹的计算，那么系统响应时间的主要限制就是cpu 的运算能力，此时maxThreads应该尽量设的小，降低同一时间内争抢cpu的线程个数，可以提高计算效率，提高系统的整体处理能力。 第二种极端情况，如果我们的操作纯粹是IO或者数据库，那么响应时间的主要限制就变为等待外部资源，此时maxThreads应该尽量设的大，这样才能提高同时处理请求的个数，从而提高系统整体的处理能力。此情况下因为tomcat同时处理的请求量会比较大，所以需要关注一下tomcat的虚拟机内存设置和linux的open file限制。 现实应用中，我们的操作都会包含以上两种类型（计算、等待），所以maxThreads的配置并没有一个最优值，一定要根据具体情况来配置。 最好的做法是：在不断测试的基础上，不断调整、优化，才能得到最合理的配置。acceptCount的配置，我一般是设置的跟maxThreads一样大，这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。 如果设的较小，可以保证接受的请求较快相应，但是超出的请求可能就直接被拒绝 如果设的较大，可能就会出现大量的请求超时的情况，因为我们系统的处理能力是一定的。 *web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。 CentOS 修改Socke最大连接数 查看 ulimit -a 中的open files CentOS默认是1024 修改 vi /etc/security/limits.conf 追加 * soft nofile 32768 * hard nofile 32768 保存，重启系统，就生效了。 说明： * 对所有用户有效 soft 可以超过的配置数 hard 最大不能超过的配置数 nofile 对描述符的配置 试验: 修改/etc/security/limits.conf： * soft nofile 200 * hard nofile 200 200个VU并发（设置集合点），出现连接失败的错误： Action.c(6): Error -27796: Failed to connect to server "192.168.1.101:8080": [10060] Connection timed out 在Controller的Connection和Connection per Second图中看到连接数偏少（相比起默认设置的1024）: 1、200 TR:19.664 Connections:177.376 Connections per Second-New Connection：28.082 Connections per Second-Connection Shutdown：28.082 2、1024（默认设置） TR:2.712 Connections:315.136 Connections per Second-New Connection：114.000 Connections per Second-Connection Shutdown：114.000 Tomcat Native library 如果不下载Tomcat Native library，则启动Tomcat时会提示： 2011-7-3 23:59:16 org.apache.catalina.core.AprLifecycleListener init 信息: The APR based Apache Tomcat Native library which allows optimal performanc e in production environments was not found on the java.library.path: E:\Program Files\Java\jdk1.6.0_13\bin;.;E:\WINDOWS\Sun\Java\bin;E:\WINDOWS\system32;... Linux下可用如下命令查看到上述提示： head logs/catalina.out 所谓的Apache Tomcat Native library其实叫APR，全称为：Apache Portable Runtime and Tomcat。可以通过下面地址访问：https://www.doczj.com/doc/855278129.html,/tomcat-5.5-doc/apr.html Tomcat can use the Apache Portable Runtime to provide superior scalability, performance, and better integration with native server technologies. The Apache Portable Runtime is a highly portable library that is at the heart of Apache HTTP Server 2.x. APR has many uses, including access to advanced IO functionality (such as sendfile, epoll and OpenSSL), OS level functionality (random number generation, system status, etc), and native process handling (shared memory, NT pipes and Unix sockets). These features allows making Tomcat a general purpose webserver, will enable much better integration with other native web technologies, and overall make Java much more viable as a full fledged webserver platform rather than simply a backend focused technology. Apache Tomcat Native library是Apache 为了提升 Tomcat 的性能搞的一套本地化 Socket, Thread, IO 组件也就是说它有高级 IO 功能, 操作系统级别的功能调用, 以及本地进程处理等等, 这些都能使 Tomcat 更像一个 Web Server(像Apache那样), 而不是只能用来解释JSP, 也就是说提升单独的 Tomcat 作为服务器的吞吐性能. Windows下安装APR： 用于Windows的APR是一个名称为：tcnative-1.dll 的文件。下载匹配版本的tcnative-1.dll：https://www.doczj.com/doc/855278129.html,/dist/tomcat/tomcat-connectors/native/1.1.20/binaries/win32/ 放到<$JA V A_HOME>/bin目录下 启动Tomcat可看到： Loaded APR based Apache Tomcat Native library 1.1.20 Linux下安装APR： 1．安装 APR https://www.doczj.com/doc/855278129.html,下载apr-1.2.12.tar.gz tar –xvf apr-1.2.12.tar.gz cd apr-1.2.12 ./configure --prefix=/tomcat/apr make make install 2．安装APR-UTIL https://www.doczj.com/doc/855278129.html,下载apr-util-1.2.12.tar.gz tar –xvf apr-util-1.2.12.tar.gz cd apr-util-1.2.12 ./configure --prefix=/tomcat/apr --with-apr=/tomcat/apr make make install 3．安装tomcat native library cd /usr/local/tomcat/bin tar zxvf tomcat-native.tar.gz cd tomcat-native-1.1.10-src/jni/native ./configure --prefix=/tomcat/apr -- with-apr=/tomcat/apr –with-java-home=/usr/jdk make make install 4．编辑tomcat/bin/catalina.sh 将JA V A_OPTS="$CATALINA_OPTS -Djava.library.path= tomcat/apr/lib" 加在# ----- Execute The Requested Command -----------------------------------------前面 5、添加环境变量 # vi /etc/profile 添加：export LD_LIBRARY_PATH=/usr/local/apr/lib 6. 重启tomcat查看结果 # vim /usr/local/tomcat/logs/catalina.out 信息: Loaded Apache Tomcat Native library 1.1.10. 2008-7-8 10:20:27 org.apache.catalina.core.AprLifecycleListener init 信息: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 2008-7-8 10:20:27 org.apache.coyote.http11.Http11AprProtocol init Connector Tomcat从5.5版本开始，支持以下四种Connector的配置分别为： 1） protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443"/> 2） connectionTimeout="20000" redirectPort="8443"/> 3） port="8081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> 4） port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443" /> 我们姑且把上面四种Connector按照顺序命名为NIO, HTTP, POOL, NIOP 为了不让其他因素影响测试结果，我们只对一个很简单的jsp页面进行测试，这个页面仅仅是输出一个Hello World。假设地址是 http://tomcat1/test.jsp 我们依次对四种Connector进行测试，测试的客户端在另外一台机器上用ab命令来完成，测试命令为：ab -c 900 -n 2000 http://tomcat1/test.jsp，最终的测试结果如下表所示(单位:平均每秒处理的请求数)： NIO HTTP POOL NIOP 281 65 208 365 666 66 110 398 692 65 66 263 256 63 94 459 440 67 145 363 由这五组数据不难看出，HTTP的性能是很稳定，但是也是最差的，而这种方式就是Tomcat 的默认配置。NIO方式波动很大，但没有低于280 的，NIOP是在NIO的基础上加入线程池，可能是程序处理更复杂了，因此性能不见得比NIO强；而POOL方式则波动很大，测试期间和HTTP方式一样，不时有停滞。 由于linux的内核默认限制了最大打开文件数目是1024，因此此次并发数控制在900。 ------------------------------------------------------------- Tomcat 6.X实现了JCP的Servlet 2.5和JSP2.1的规范，并且包括其它很多有用的功能，使它成为开发和部署web应用和web服务的坚实平台。 NIO （No-blocking I/O）从JDK 1.4起，NIO API作为一个基于缓冲区，并能提供非阻塞I/O 操作的API被引入。 作为开源web服务器的java实现，tomcat几乎就是web开发者开发、测试的首选，有很多其他商业服务器的开发者也会优先选择tomcat作为开发时候使用，而在部署的时候，把应用发布在商业服务器上。也有许多商业应用部署在tomcat上，tomcat承载着其核心的应用。但是很多开发者很迷惑，为什么在自己的应用里使用tomcat作为平台的时候，而并发用户超过一定数量，服务器就变的非常繁忙，而且很快就出现了connection refuse的错误。但是很多商业应用部署在tomcat上运行却安然无恙。 其中有个很大的原因就是，配置良好的tomcat都会使用APR(Apache Portable Runtime),APR 是Apache HTTP Server2.x的核心，它是高度可移植的本地库，它使用高性能的UXIN I/O操 作，低性能的java io操作，但是APR对很多Java开发者而言可能稍稍有点难度，在很多OS平台上，你可能需要重新编译APR。但是从Tomcat6.0以后, Java开发者很容易就可以是用NIO的技术来提升tomcat的并发处理能力。 但是为什么NIO可以提升tomcat的并发处理能力呢，我们先来看一下java 传统io与 java NIO的差别。 Java 传统的IO操作都是阻塞式的(blocking I/O), 如果有socket的编程基础，你会接触过堵塞socket和非堵塞socket，堵塞socket就是在accept、read、write等IO操作的的时候，如果没有可用符合条件的资源，不马上返回，一直等待直到有资源为止。而非堵塞socket则是在执行select的时候，当没有资源的时候堵塞，当有符合资源的时候，返回一个信号，然后程序就可以执行accept、read、write等操作，一般来说，如果使用堵塞socket，通常我们通常开一个线程accept socket，当读完这次socket请求的时候，开一个单独的线程处理这个socket请求；如果使用非堵塞socket，通常是只有一个线程，一开始是select状，当有信号的时候可以通过可以通过多路复用（Multiplexing)技术传递给一个指定的线程池来处理请求，然后原来的线程继续select状态。最简单的多路复用技术可以通过java管道(Pipe)来实现。换句话说，如果客户端的并发请求很大的时候，我们可以使用少于客户端并发请求的线程数来处理这些请求，而这些来不及立即处理的请求会被阻塞在java管道或者队列里面，等待线程池的处理。请求听起来很复杂，在这个架构当道的java 世界里，现在已经有很多优秀的NIO的架构方便开发者使用，比如Grizzly,Apache Mina等等，如果你对如何编写高性能的网络服务器有兴趣，你可以研读这些源代码。 简单说一下，在web服务器上阻塞IO(BIO)与NIO一个比较重要的不同是，我们使用BIO 的时候往往会为每一个web请求引入多线程，每个web请求一个单独的线程，所以并发量一旦上去了，线程数就上去了，CPU就忙着线程切换，所以BIO不合适高吞吐量、高可伸缩的web服务器；而NIO则是使用单线程(单个CPU)或者只使用少量的多线程(多CPU)来接受Socket，而由线程池来处理堵塞在pipe或者队列里的请求.这样的话，只要OS可以接受TCP的连接，web服务器就可以处理该请求。大大提高了web服务器的可伸缩性。 使用NIO连接器，只需要在server.xml里把 HTTP Connector做如下更改： connectionTimeout="20000" redirectPort="8443" /> 改为 connectionTimeout="20000" redirectPort="8443" /> 然后启动服务器，在启动日志中会看到org.apache.coyote.http11.Http11NioProtocol start的信息，表示NIO已经启动。 ----------------------------------------------------------------- *AJP连接器 *由于tomcat的html和图片解析功能相对其他服务器如apche等较弱，所以，一般都是集成起来使 用，只有jsp和servlet服务交由tomcat处理，而tomcat和其他服务器的集成，就是通过ajp协议来完成的。 oracle性能监控、诊断分析与调优 D:\PrefTest\Oracle调优\Oracle性能诊断与调优学习笔记.doc 监控方法 方法1：在LR的Controller中配置监视Oracle 1、在Controller所在的机器上安装Oracle客户端 2、配置好服务名，用sqlplus确认可以连接Oracle 3、在Controller中配置Oracle连接： 系统性能优化方案 (第一章) 系统在用户使用一段时间后（1年以上），均存在系统性能（操作、查询、分析）逐渐下降趋势，有些用户的系统性能下降的速度非常快。同时随着目前我们对数据库分库技术的不断探讨，在实际用户的生产环境，现有系统在性能上的不断下降已经非常严重的影响了实际的用户使用，对我公司在行业用户内也带来了不利的影响。 通过对现有系统的跟踪分析与调整，我们对现有系统的性能主要总结了以下几个瓶颈： 1、数据库连接方式问题 古典C/S连接方式对数据库连接资源的争夺对DBServer带来了极大的压力。现代B/S连接方式虽然不同程度上缓解了连接资源的压力，但是由于没有进行数据库连接池的管理，在某种程度上，随着应用服务器的不断扩大和用户数量增加，连接的数量也会不断上升而无截止。 此问题在所有系统中存在。 2、系统应用方式（架构）问题(应用程序设计的优化) 在业务系统中，随着业务流程的不断增加，业务控制不断深入，分析统计、决策支持的需求不断提高，我们现有的业务流程处理没有针对现有的应用特点进行合理的应用结构设计，例如在‘订单、提油单’、‘单据、日报、帐务的处理’关系上，单纯的数据关系已经难以承载多元的业务应用需求。 3、数据库设计问题（指定类型SQL语句的优化） 目前在系统开发过程中，数据库设计由开发人员承担，由于缺乏专业的数据库设计角色、单个功能在整个系统中的定位模糊等原因，未对系统的数据库进行整体的分析与性能设计，仅仅实现了简单的数据存储与展示，随着用户数据量的不断增加，系统性能逐渐下降。 4、数据库管理与研究问题(数据存储、物理存储和逻辑存储的优化) 随着系统的不断增大，数据库管理员（DBA）的角色未建立，整个系统的数据库开发存在非常大的随意性，而且在数据库自身技术的研究、硬件配置的研究等方面未开展，导致系统硬件、系统软件两方面在数据库管理维护、研究上无充分认可、成熟的技术支持。 5、网络通信因素的问题 随着VPN应用技术的不断推广，在远程数据库应用技术上，我们在实际设计、开发上未充分的考虑网络因素，在数据传输量上的不断加大，传统的开发技术和设计方法已经无法承载新的业务应用需求。 针对以上问题，我们进行了以下几个方面的尝试： 1、修改应用技术模式 2、建立历史数据库 3、利用数据库索引技术 4、利用数据库分区技术 通过尝试效果明显，仅供参考！ ***系统性能测试报告 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 个； Java堆是指在程序运行时分配给对象生存的空间。通过-mx/-Xmx和-ms/-Xms来设置起始堆的大小和最大堆的大小。根据自己JDK的版本和厂家决定使用-mx和-ms或-Xmx和-Xms。Java堆大小决定了垃圾回收的频度和速度，Java堆越大，垃圾回收的频度越低，速度越慢。同理，Java堆越小，垃圾回收的频度越高，速度越快。要想设置比较理想的参数，还是需要了解一些基础知识的。Java堆的最大值不能太大，这样会造成系统内存被频繁的交换和分页。所以最大内存必须低于物理内存减去其他应用程序和进程需要的内存。而且堆设置的太大，造成垃圾回收的时间过长，这样将得不偿失，极大的影响程序的性能。以下是一些经常使用的参数设置： 1) 设置-Xms等于-XmX的值； 2) 估计内存中存活对象所占的空间的大小，设置-Xms等于此值，-Xmx四倍于此值； 3) 设置-Xms等于-Xmx的1/2大小； 4) 设置-Xms介于-Xmx的1/10到1/4之间； 5) 使用默认的设置。 大家需要根据自己的运行程序的具体使用场景，来确定最适合自己的参数设置。除了-Xms和-Xmx两个最重要的参数外，还有很多可能会用到的参数，这些参数通常强烈的依赖于垃圾收集的算法，所以可能因为JDK的版本和厂家而有所不同。但这些参数一般在Web 开发中用的比较少，我就不做详细介绍了。在实际的应用中注意设置-Xms和-Xmx使其尽可能的优化应用程序就行了。对于性能要求很高的程序，就需要自己再多研究研究Java虚拟机和垃圾收集算法的机制了。可以看看曹晓钢翻译的《深入Java虚拟机》一书。 Java程序性能调优的基本知识和JDK 调优 一基本知识 1.1 性能是什么 在性能调优之前，我们首先来了解一下性能是什么？关于性能，我想每个学习过Java的人都能列 出几点，甚至可以夸夸其谈。在《Java TM Platform Performance》一书中，定义了如下五个方面来作 为评判性能的标准： 1) 运算的性能——哪一个算法的执行性能最好？ 2) 内存的分配——程序运行时需要耗费多少内存？ 随着技术的发展，智能手机硬件配置越来越高，可是它和现在的PC相比，其运算能力，续航能力，存储空间等都还是受到很大的限制，同时用户对手机的体验要求远远高于PC的桌面应用程序。以上理由，足以需要开发人员更加专心去实现和优化你的代码了。选择合适的算法和数据结构永远是开发人员最先应该考虑的事情。同时，我们应该时刻牢记，写出高效代码的两条基本的原则：（1）不要做不必要的事；（2）不要分配不必要的内存。 我从去年开始接触Android开发，以下结合自己的一点项目经验，同时参考了Google的优化文档和网上的诸多技术大牛给出的意见，整理出这份文档。 1. 内存优化 Android系统对每个软件所能使用的RAM空间进行了限制(如：Nexus o ne 对每个软件的内存限制是24M)，同时Java语言本身比较消耗内存，d alvik虚拟机也要占用一定的内存空间，所以合理使用内存，彰显出一个程序员的素质和技能。 1) 了解JIT 即时编译（Just-in-time Compilation，JIT），又称动态转译（Dynamic Translation），是一种通过在运行时将字节码翻译为机器码，从而改善字节码编译语言性能的技术。即时编译前期的两个运行时理论是字节码编译和动态编译。Android原来Dalvik虚拟机是作为一种解释器实现，新版 （Android2.2+）将换成JIT编译器实现。性能测试显示，在多项测试中新版本比旧版本提升了大约6倍。 详细请参考https://www.doczj.com/doc/855278129.html,/cool_parkour/blog/item/2802b01586e22cd8a6ef3f6b. html 2) 避免创建不必要的对象 就像世界上没有免费的午餐，世界上也没有免费的对象。虽然gc为每个线程都建立了临时对象池，可以使创建对象的代价变得小一些，但是分配内存永远都比不分配内存的代价大。如果你在用户界面循环中分配对象内存，就会引发周期性的垃圾回收，用户就会觉得界面像打嗝一样一顿一顿的。所以，除非必要，应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则： 当你从用户输入的数据中截取一段字符串时，尽量使用substring函数取得原始数据的一个子串，而不是为子串另外建立一份拷贝。这样你就有一个新的String对象，它与原始数据共享一个char数组。如果你有一个函数返回一个String对象，而你确切的知道这个字符串会被附加到一个Stri ngBuffer，那么，请改变这个函数的参数和实现方式，直接把结果附加到StringBuffer中，而不要再建立一个短命的临时对象。 一个更极端的例子是，把多维数组分成多个一维数组： int数组比Integer数组好，这也概括了一个基本事实，两个平行的int数组比(int,int)对象数组性能要好很多。同理，这试用于所有基本类型的组合。如果你想用一种容器存储(Foo,Bar)元组，尝试使用两个单独的Foo[] 在项目上线之前，都需要做，目的是看下我们的网站能抗住多少的压力，能承担多少并发，如果不做压力测试，一旦出现大访问量时，我们的网站会挂掉。 一、Webbench测试并发 Webbench是下的一个网站压力测试工具，能测试处在相同硬件上，不同服务的性能以及不同硬件上同一个服务的运行状况。webbench的标准测试可以向我们展示服务器的两项内容：每分钟相应请求数和每秒钟传输数据量。webbench最多可以模拟3万个并发连接去测试网站的负载能力。 测试的环境是 Linux Ubuntu 1、安装 1.1 安装ctags apt-get install exuberant-ctags ctags 为webbench的依赖 1.2 下载安装 官网：~cz210... root@corwien:~# wget ~cz210552/distfiles/webbench- root@corwien:~# tar zxvf webbench- root@corwien:~# cd webbench-1.5/ root@corwien:~/webbench-1.5# make root@corwien:~/webbench-1.5# make install root@corwien:~/webbench-1.5# webbench webbench [option]... URL -f|--force Don't wait for reply from . -r|--reload Send reload request - Pragma: no-cache. -t|--time 测试目的： 考虑到各地区的用户数量和单据量的增加会给服务器造成的压力不可估计，为确保TMS系统顺利在各地区推广上线，决定对TMS系统进行性能测试，重点为监控服务器在并发操作是的资源使用情况和请求响应时间。 测试内容 测试工具 主要测试工具为：LoadRunner11 辅助软件：截图工具、Word 测试结果及分析 5个用户同时生成派车单的测试结果如下： Transaction Summary（事务摘要） 从上面的结果我们可以看到该脚本运行47秒，当5个用户同时点击生成派车单时，系统的响应时间为41.45秒，因为没有设置持续运行时间，所以这里我们取的响应时间为90percent –time，且运行的事物已经全部通过 事务概论图，该图表示本次场景共5个事务（每个用户点击一次生成派车单为1个事务），且5个事务均已pass，绿色表色pass，如出现红色则表示产生error 从上图可以看到服务器的CPU平均值为14.419% ，离最大参考值90%相差甚远；且趋势基本成一直线状，表示服务器响应较为稳定，5个用户操作5个900托运单的单据对服务器并没有产生过大的压力。 “Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，这里服务器每秒响应9,771次请求；如果客户端发出的请求数量越多，与之相对的“Average Throughput (吞吐量)”也应该越大。图中可以看出，两种图形的曲线都正常并且几乎重合，说明服务器能及时的接受客户端的请求，并能够返回结果。 按照上述策略，我们得出的最终测试结果为： 生成派车单: 1个用户，300个托运单点击生成派车单，响应时间7.34秒 5个用户，900个托运单点击生成派车单，响应时间41.45秒 单据匹配： 单用户1000箱，20000个商品，上传匹配时间8秒 五个用户2500箱，40000个商品，同时上传匹配耗时2分25秒 自由派车： 单条线路917个托运单下载，响应时间1分40秒 上述结果是在公司内网，测试环境上进行的测试，可能与实际会有偏差 ArcSDE 9.1性能调优方案 编写：李国勇 日期： 2006-11-27 版本： 1.0 密级：内部公开 北京恒华伟业科技有限公司 第一章概述 影响ArcSDE运行性能的因素比较多，对其性能的优化需要根据具体情况而定。总体上说，对ArcSDE性能影响较大的因素是：服务器硬件配置、Oracle参数配置、ArcSDE 参数配置和图层管理模式。 服务器硬件配置包括：CPU主频、物理内存大小、系统总线速度、硬盘数量、磁盘寻道时间等，硬件配置参数不是本文的重点讨论内容。 Oracle参数配置包括表空间的组织和缓冲参数配置；ArcSDE参数配置包括存储参数配置和缓冲参数配置。 本调整方案主要针对输配电GIS系统，不一定适合其它行业。 本优方案所有参数基于ArcSDE 9.1、Oracle 9.2。 1.1 总论 一．性能调优的重点在Oracle，而不在ArcSDE，一般情况下，调整ArcSDE各种参数对性能提升作用不大，ArcSDE使用安装时的默认参数即可； 二．小数据量（图层数据总量小于1G存储空间）下，优化SDE的存储的优化对性能的提升不大，ArcSDE的四个频繁访问的系统表没有必要分开存储； 三．小数据量（图层数据总量小于1G存储空间）下，用户数据存储于SDE用户下对性能的影响也不大，但是出于数据库管理的考虑，建议尽可能将这两类数据分开 存储； 四．对于输配电GIS系统，数据库db_block_size设置为8KB完全满足使用要求，没有必要调整到16KB； 五．如果图层中单个图形元素覆盖范围差异不大，没有必要建立多级Grid Index，而且一般情况下默认Grid Index设置即可满足多数情况下的性能需求； 六．如果注册了版本，建议定期对数据库进行Compress和Analyse，同时要确保undo 表空间有足够可用空间（如1G）； 七．定期对磁盘做碎片整理，以提升磁盘I/0性能。 1.2 参考文献 1．ArcSDE 9.1 Configuration and Tuning Guide for Oracle? -- ESRI 2005； 2．Managing ArcSDE 9.1 Application Servers -- ESRI 2005； 3．Cost Control: Inside the Oracle Optimizer -- Oracle Donald K. Burleson。 https://www.doczj.com/doc/855278129.html,/oramag/webcolumns/2003/techarticles/burleson_cbo_pt1.html X项目AB系统性能测试报告 项目编号：XXXXXX-ACP101项目名称：X项目 编写：XXX编写日期： 审核：XX审核日期： 批准：批准日期： 1.前言 1.1.测试目标 本次性能测试的目的：通过测试获取与主机、后台流程平台交互过程中终端服务器处理性能及资源消耗情况。评估目前处理性能是否满足业务需求。 2.测试方法 压力测试采用自动化测试来实现，使用业界主流的压力测试工具LoadRunner8.1及其方法论完成对被测系统进行测试和结果分析。 压力测试工具LoadRunner通过使用虚拟用户模拟真实用户的操作，发起交易，完成对被测系统的加压，监控并记录被测系统的交易响应能力，各服务器的资源使用情况，获取交易响应时间、吞吐率等各项性能指标，并根据测试结果分析系统的性能瓶颈，评估系统的整体性能。 压力测试的测试方法主要包括：在被测系统中录制压力测试中使用的交易脚本，形成可以多次重复并发运行的测试脚本，由LoadRunner的控制台调度这些脚本，并发地执行交易，从而模拟真实生产系统的压力，形成对被测系统的加压，并监控和记录被测系统在这样的压力状况下表现出来的各项特征，例如：交易响应时间变化趋势、吞吐率变化趋势和系统资源（CPU）利用率的变化趋势等，获取被测系统在大压力情况下的各项性能指标。 2.1.测试准备 （1）开发测试交易，交易首先进行圈存，然后发任务给流程平台 （2）使用grinder交易执行过程作为测试交易的脚本 （3）使用下列测试数据（帐号）进行维护。测试时随机获取不同行所的账号进行测试。 压力测试账号 （4）准备一台台式机作为调试测试脚本、发起测试的客户端。配置：CPU intel core 2duo cpu(2.93GHz);2GB Memory;os windows xp sp3.IP为10.2.45.92（5）安装被测试交易到被测试的ABS终端服务器上。 2.2.被测试系统的系统配置 系统名称Ip地址os CPU Memory (GB) Network(M)应用程序参数 ABS10.2.39.13AIX5.3 64bit POWER5 2.3*2 41000Java:1.4.2(64 bit)SR9 mem:ms256; mx1536 Log:error Gateway10.2.39.14AIX5.3 64bit POWER5 2.3*2 41000Java:1.4.2(64 bit)SR9 mem:ms256; mx1280 Log:error 2.3.资源监控 本次压力测试监控的资源是操作系统AIX资源。 利用NMON软件对服务器系统的CPU%进行监控、并把这些数据作为为测试结果的一部分进行收集，便于进行事后分析。 Java虚拟机性能参数调优指导书 (仅供内部使用） 目录 1概述 (5) 2JAVA虚拟机运行机制概览 (5) 2.1运行时分析 (5) 2.2垃圾收集和线程同步 (7) 3JAVA虚拟机参数分类说明 (8) 3.1Java虚拟机标准参数 (8) 3.2Java虚拟机扩展参数 (10) 4JAVA应用性能测试调优经验总结 (13) 4.1GC调优参数的使用 (13) 4.2JIT调优参数的使用 (14) 4.3Java线程调优参数的使用 (14) 5结束语 (15) 6参考文献 (15) 表目录 表1 JVM 标准参数集 (10) 表2 JVM 扩展参数集 (10) 表3 JVM GC/Hotspot相关参数集 (12) 表4 JVM 性能统计参数集 (13) 错误！未找到引用源。 关键词：Java、垃圾收集、虚拟机、即时编译 摘要：随着JAVA在应用系统级的项目开发中的使用越来越广泛，虚拟机、垃圾收集、热点编译、J2EE等新技术层出不穷，JAVA作为系统级开发的一个选择的优势也越来越明显，在此同时 其不能完全编译、垃圾收集等与生俱有的特征也使得JAVA备受争议的“慢”得到更多的关 注。本文通过对JAVA虚拟机的运行机理的分析，以及JAVA虚拟机参数使用说明等描述，试 图使读者能够更好的运行他的基于JAVA的应用系统，以最小的代价换取最大的收益。 缩略语清单： 缩略语英文全名中文解释 JAVA SUN公司发明的一种语言 JVM Java Virtual Machine JAVA虚拟机 GC Garbage Collection 垃圾收集 HotSpot Java虚拟机内部的一种热点编译技术 JIT Just-In-Time 即时编译技术 Linux系统性能测试与分析 1、前言 通过对系统中和性能相关的各个环节的介绍，使大家知道出现性能问题时可以从那些方面入手去查，而分析典型应用对系统资源使用的特点，让大家对应用和系统资源的依赖有了更直观的认识。大多数的硬件性能问题主要和CPU、磁盘、内存相关，还没有遇到因为开发语言的运行效率对整个应用的性能造成影响，而应用程序设计的缺陷和数据库查询的滥用反倒是最最常见的性能问题。需要注意的是，大多数情况下，虽然性能瓶颈的起因是程序性能差或者是内存不足或者是磁盘瓶颈等各种原因，但最终表现出的结果就是CPU耗尽，系统负载极高，响应迟缓，甚至暂时失去响应，因此我们观察服务器状况时，最先看的就是系统负载和CPU空闲度。当你阅读完了这遍文档以后就会有一个对系统分析的思路。 2、性能分析的目的 2.1找出系统性能瓶颈 1.硬件瓶颈 2.软件瓶颈 2.2提供性能优化方案 1.升级硬件 2.改进系统结构 达到合理的硬件和软件配置，使系统资源使用达到平衡。但遗憾的是解决一个性能瓶颈，往往又会出现另外的瓶颈或者其他问题，所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。系统运行良好的时候恰恰也是各项资源达到了一个平衡体，任何一项资源的过渡使用都会造成平衡体系破坏，从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待 CPU资源，系统响应变慢，等待会造成进程数增加，进程增加又会造成内存使用增加，内存耗尽又会造成虚拟内存使用，使用虚拟内存又会造成磁盘IO增加和CPU开销增加（用于进程切换、缺页处理的CPU开销） 3、性能相关的各个环节 3.1 硬件资源 3.1.1、CPU ⒈ 是否使用SMP。 ⒉ 单颗CPU的性能对依赖CPU的某些应用的影响很严重，比如数据库的查询处理。 3.1.2、内存 测试用例实例 （含：功能测试用例、性能测试用例、兼容性测试用例） 目录 一、功能测试用例................................................................................. - 2 - 二、性能测试......................................................................................... - 9 - 2.1预期性能测试用例.................................................................... - 9 - 2.2 用户并发测试用例................................................................. - 10 - 2.3 大数据量测试用例................................................................. - 10 - 2.4 疲劳强度测试用例................................................................. - 11 - 2.5 负载测试测试用例................................................................. - 11 - 三、兼容性测试................................................................................... - 11 - 用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注：本文档由测试组提交，审核由测试组负责人签字，由项目负责人批准。 历史版本： 版本/状态作者参与者起止日期备注 V1.1 文档级别：X级模板编号：TNET-QR-RD004 模板版本：V1.0 XXXX公司 系统名称V1.0 测试报告（功能+性能） 版本记录 状态：C-创建文档，A-增加内容，M-修改内容，D-删除内容 目录 引言 (4) 1.1编制目的 (4) 1.2词汇表 (4) 1.3背景 (4) 2 测试管理 (4) 2.1测试范围与主要内容 (4) 2.2测试方法 (4) 2.3测试环境与测试辅助工具 (5) 2.4测试准则 (5) 2.5测试接受准则 (5) 2.6 BUG的定义标准 (5) 2.7人员与任务表 (6) 2.8缺陷管理与改错计划 (7) 3 测试概要 (7) 3.1测试执行 (7) 3.2测试用例 (8) 3.2.1 功能性 (8) 3.2.2 易用性 (8) 4 测试结果 (8) 4.1B UG量表格统计 (8) 4.2柱形图统计 (9) 4.3B UG趋势图 (9) 4.4B UG引入阶段 (10) 4.5B UG状态分布 (10) 5 测试结论 (11) 5.1功能性 (11) 5.2易用性 (11) 5.3兼容性 (11) 6 附录. 本计划审批意见 (11) 引言 1.1编制目的 略 1.2词汇表 1.3背景 随着互联网的发展，人们对于网络依赖，XX系统的实现提供手机端的访问，及各功能在便捷设备上的使用，提供客户更快更优质的服务。 2测试管理 2.1测试范围与主要内容 略 2.2测试方法 黑盒测试: 1.系统测试 2.兼容性测试 3.性能测试 4.压力测试 5.容错性测试 6.升级测试 7.用户体验测试 8.UI测试 9.易用性测试 10.集成测试 MySQL5.1性能优化方案 1.平台数据库 1.1.操作系统 Red Hat Enterprise Linux Server release 5.4 (Tikanga) ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped 32位Linux服务器，单独作为MySQL服务器使用。 1.2.M ySQL 系统使用的是MySQL5.1，最新的MySQL5.5较之老版本有了大幅改进。主要体现在以下几个方面： 1）默认存储引擎更改为InnoDB InnoDB作为成熟、高效的事务引擎，目前已经广泛使用，但MySQL5.1之前的版本默认引擎均为MyISAM，此次MySQL5.5终于将默认数据库存储引擎改为InnoDB，并且引进了Innodb plugin 1.0.7。此次更新对数据库的好处是显而易见的：InnoDB的数据恢复时间从过去的一个甚至几个小时，缩短到几分钟(InnoDB plugin 1.0.7，InnoDB plugin 1.1，恢复时采用红-黑树)。InnoDB Plugin 支持数据压缩存储，节约存储，提高内存命中率，并且支持adaptive flush checkpoint, 可以在某些场合避免数据库出现突发性能瓶颈。 Multi Rollback Segments：原来InnoDB只有一个Segment，同时只支持1023的并发。现已扩充到128个Segments，从而解决了高并发的限制。 2）多核性能提升 金蝶B O S性能测试分析 分享 Company Document number：WTUT-WT88Y-W8BBGB-BWYTT-19998 金蝶BOS性能测试分析流程 目录 1.1. 简介 最近通过版本的4-5月份集成测试与云平台的性能测试两个案例分析，发现性能测试只定位发现问题的工作方式不利于问题的快速处理，进而错过问题的最佳处理时机，给后续的发版带来很高的风险，4-5月份的集成测试只反馈CPU高消耗的现象与WEB的jprofile分析文档，因开发人员过忙与缺少实际环境而把问题一直耽搁着，这个问题本来在6月1号就发现了，结果到了7月5号迫不得已才组织人员协同分析定位问题，问题定位后也快速解决了问题；而云平台的性能测试我一直跟踪并协助定位性能问题，问题定位后，开发迅速修改代码，整个过程发现的几个重大性能问题都得到了快速的解决，通过对比这两个性能测试案例，得出只有快速定位问题才能高效的解决问题，只反馈问题现象，缺乏足够的依据，开发人员很难快速修复问题。 为了在BOS性能测试过程中快速定位问题以及在调优测试中快速找到性能提升点，特意整理在分析性能问题过程中涉及到的一些工具与方法，以便快速解决问题，本文将从用例分析、问题现象、问题分析、问题定位、辅助工具等方面规范性能问题的分析过程以及工作过程中的输出文档。 1.2. 参考资料 2.1. 概述 处理任何问题都有一套方法，性能测试分析过程也一样，我们平常测试发现的问题只是问题的表现，我们要透过现象逐步分析到问题的本质，透过本质我们才能快速解决问题，下面我就按经验来整理一下性能问题的分析思路与通用流程。 2.2. 分析思路 我们通过一个倒金字塔模型来整理一个分析思路，由上至下逐步聚焦问题,测试过程中首先是会发现问题，发现性能问题后，我们第一步要确认是否是测试用例设计不当而导致的，如果不是我们就要用后续提到的各种工具与方法出具问题分析结果，根据分析数据推断出可能存在的代码可疑点，然后与开发一起如果修改问题。 2.3. 步骤结果输出 2.4. 分析流程 下图整理一个在性能测试过程中发现性能问题而进行问题定位的分析流程，本流程里不涉及到硬件绝对瓶颈的问题，如磁盘空间不足，另外应用服务器跟数据库服务器的参数都按照产品配置说明进行了正确配置，本流程图只用来指导分析软件本身存在的问题。 Java程序性能优化方案 StringTokenizer比String.split()方法效率高 更优化的方式 Java代码 while(true){ String splitStr=null; int j=temp.indexOf(';'); if(j<0)break; SplitStr=tmp.substring(0,j); tmp=tmp.substring(j+1); } while(true){ String splitStr=null; int j=temp.indexOf(';'); if(j<0)break; SplitStr=tmp.substring(0,j); tmp=tmp.substring(j+1); } 比String.startsWith和endsWith性能更优的方式：Java代码 int len=orgStr.length(); if(orgStr.charAt(0)=='a' &&orgStr.charAt(1)=='b' &&orgStr.charAt(2)=='b'); if(orgStr.charAt(len-1)=='a' &&orgStr.charAt(len-2)=='b' &&orgStr.charAt(len-3)=='c'); int len=orgStr.length(); if(orgStr.charAt(0)=='a' &&orgStr.charAt(1)=='b' &&orgStr.charAt(2)=='b'); if(orgStr.charAt(len-1)=='a' &&orgStr.charAt(len-2)=='b' &&orgStr.charAt(len-3)=='c'); StringBuffer(int capacity)指定初始容量可以减少扩容的操作 1.简要场景描述： 被测项目的数据库服务采用ORACLE 10g，测试功能点选择的是一个新建录入保存业务。当并发20用户时，数据库资源占用正常，处理业务响应时间正常，当并发40用户时，数据库服务器CPU占用率突增到100％，系统几乎不响应。 2.对ORACLE 10g进行监控： 2.1首先打开监控开关: exec dbms_monitor.serv_mod_act_trace_enable (service_name=>' 性能测试报告 ―――――――――――――――――――― 宜通关研发部 云路网络科技有限公司 目录 1. 测试目的 (3) 2. 测试地点 (3) 3. 测试环境 (3) 3.1.客户端环境 (3) 3.2.测试工具 (3) 3.3. M ONKEY的特征 (3) 4. 测试过程说明 (4) 4.1.测试案例 (4) 5. 测试结果 (5) 6. 性能测试总结 (6) 1.测试目的 本报告是针对在Android客户端的稳定性，CPU使用率，UI的渲染时间以及发生的未知的错误，发现现有系统中可能存在的性能方面问题，提出可行性建议，以尽可能降低后续工作风险，为运用的稳定运行提供保证。 主要测试目标如下： 1、获得是否无响应问题，崩溃问题，内存泄露问题，异常问题（包含空指针， NullPointerException）。 2、获得APP在不同负载下的资源消耗情况，为硬件配置提供依据。 1.测试地点 公司。 2.测试环境 2.1.客户端环境 本次测试使用的设备清单如下： 设备名称设备型号操作系统网络内存CPU 测试次数魅族魅蓝3s 5.1 3G 16G 2G 100000 OPPO R7 Plus 5.0 WiFi 32G 3G 10000 2.2.测试工具 测试项目测试工具 性能测试工具monkey 2.3. Monkey的特征 1、测试的对象仅为应用程序包，有一定的局限性。 2、 Monky测试使用的事件流数据流是随机的，不能进行自定义。 3、可对Test的对象，事件数量，类型，频率等进行设置。 3.测试过程说明 3.1.测试案例 下面是一个更为典型的命令行示例，它启动指定的应用程序，并向其发送10000个伪随机事件： monkey -p com.winlu.etg --ignore-crashes -s 100 --throttle 100 -v -v -v 100000 >D:\monkeylog.txt & com.winlu.etg （包名） -ignore-crashes 忽略崩溃，继续测试，若不做此限制，monkey测试出现崩溃时会自动停止测试 --throttle延时1000=1秒 -v -v -v 100000随机点击次数 -s 100为随机数的事件序列定一个值，若出现问题下次可以重复同样的系列进行排错 >D:\monkeylog.txt把monkey日志打出到设备储存，当测试发现出现错误时，就应该重新执行测试，把日志打出观看 & 即使把数据线从电脑上拔开，monkey测试依然会在设备上进行 举例： Android SDK 连接真机设备，Window打开CMD，命令行输入：adb shell，进入shell界面后： 软件测试用例实例(非常详细)汇总 1、兼容性测试 在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。 测试 目的 配置说明操作系 统 系统 软件 外设应用软件结果 服务器Windo w2000( S) Windo wXp Windo w2000( P) Windo w2003 用例编号TestCase_LinkWorks_W orkEvaluate 项目名称LinkWorks 1.1. 1.2. 疲劳强度测试用例 强度测试也是性能测试是的一种，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。测试目的 测试说明 前提条件连续运行8小时,设置添加 10用户并发 测试需求输入/ 动作 输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时功能1 2小时 4小时 6小时 8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI （图形用户界面）与应用程序交互，对交互的输出或接受进行分析，以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate _02 项目 名称 https://www.doczj.com/doc/855278129.html, 开发人员模块 名称 WorkEvaluate 用例参考工作考核系统界面设计 ×××系统项目 性能测试报告 ―――――――――――――――――――― XXX部 XXXXXXXX XXXX有限公司 修订控制页 目录 1.测试目的 (4) 2.测试地点 (4) 3.测试环境 (4) 3.1.服务器、客户端环境 (4) 3.2.测试工具 (5) 4.测试规模及限制 (5) 5.测试过程说明 (5) 5.1.测试模型 (5) 5.2.测试案例 (6) 5.3.测试场景 (6) 6.测试结果 (7) 6.1.平均响应时间 (7) 6.2.差错率统计 (9) 6.3.主机系统资源消耗 (10) 7.性能测试总结 (10) 8.大数据量业务测试数据 (11) 8.1.测试参数 (11) 8.2.测试结果 (11) 1.测试目的 本报告是针对XXX系统的功能完整性、高可靠性的集群、系统容量等多方面而进行的。其目的主要是验证系统架构设计决策的正确性，检验架构设计是否有能力承受高并发登录系统进行交易和大数据量的批量处理业务，根据用户提出的业务需求组织利用典型业务来验证XXX系统是否能够适应，发现现有系统中可能存在的性能方面问题，提出可行性建议，以尽可能降低后续工作风险，为系统的稳定运行提供保证。 主要测试目标如下： 1、获得XXX系统的性能表现，为系统上线提供依据。 2、考查XXX系统的并发性和效率情况，为代码优化提供指导。 3、获得系统性能较优的参数配置，为XXX系统调优提供依据。 4、获得XXX系统在不同负载下的主机资源消耗情况，为硬件配置提供依据。 2.测试地点 ××。 3.测试环境 3.1.服务器、客户端环境 本次测试的服务器环境为XXX系统的生产主机，客户环境为1台P4 1.6G 的便携式笔记本。 本次测试使用的设备清单如下： 服务器性能优化 1、Apache+tomcat集群方式 服务器基本设置：1个apache集成二个tomcat。 安装apache http server省略，访问地址为http://127.0.0.1:8081 安装tomcat，解压apache-tomcat-6.0.20.zip，测试时我是把两个tomcat分开放在不同的虚拟机，其中一个是和apache同一台虚拟机。 两个tomcat分别命名为worker2和worker3 先说tomcat.worker2的配置： server.xml 第一步：配置http监听端口，这里端口设为8079,该步骤非必要，只要不冲突就行了。 系统性能优化方案
性能测试分析报告案例
java性能调优的基本知识
安卓性能优化方案
性能测试实战经典案例分享：一个你不知道的压力测试工具
性能测试报告范例
SDE性能调优方案
性能测试报告范例 - X项目AB系统性能测试报告
JAVA虚拟机性能参数调优指导书
22提供性能优化方案---Google-Code
软件测试 测试用例实例(含：功能测试用例、性能测试用例、兼容性测试用例)
测试报告范例
MySQL5.1性能优化方案
金蝶BOS性能测试分析分享
Java程序性能优化方案
性能测试案例分析
Android性能测试报告
软件测试用例实例(非常详细)汇总
性能测试报告模板
服务器性能调优
相关主题
文本预览