性能测试工程师心得（精选12篇）
性能测试工程师心得 篇1
高级性能测试工程师培训心得
--税务事业部 魏琳
从中国的软件现状来看，各式各样的软件层出不穷，但是好的却并不多，能够走向国际的更是少之又少。中国的软件要想与国际接轨，就必须要完善自己的软件产业，使软件产业走向正规化、国际化，从而更加完善自己的软件产品，这就使软件测试工程师的人员缺口很大。很多人认为软件测试无非就是找错误，挑程序员的毛病，仅此而已，其实不然，测试并不只是单纯的挑刺，更多的意义是在辅助程序员，让程序员的程序更加完美，让公司的产品能够更稳固的占据市场，尤其是现在这个软件行业竞争异常激烈的时代，只有公司的产品站住了脚，公司才会有更多的效益产生，只有公司有了效益，员工才会领到更多的工资，这样公司才能长久的生存下去，而帮助产品能够更坚牢的站住市场的，就是软件测试人员。
这次有幸参加公司组织的为期五天的高级性能测试工程师的培训，虽然课程紧密，内容繁多，但是我却乐在其中，受益匪浅。借此机会与大家分享一下我这几天以来的学习心得：
首先，知识日新月异，不学则惘。在当今这个信息高速传递的社会，不难感受到知识爆炸的巨大威力，特别对于我们IT行业，更加深刻体会到什么叫做“日新月异”，更加深刻认识到，先进的知识与技术是一个企业立于不败之地关键因素。但是对于已经步入社会的我们，已经远离校园的我们，现在的学习缺乏系统性，往往不能自觉主动地抽出时间，静下心来学习，常常是需要什么，急用什么，才想起来学什么，遇到问题才翻理论、寻政策，临时抱佛脚，学习缺乏“挤”劲和“钻”劲，浅尝辄止，通过这次培训，使我在老师那里学到了当今最流行的测试技术以及测试管理，当然这只是其次，最重要的是在同行中营造了浓厚的学习氛围，大家互相取长补短，分享工作中遇到的各种问题，与老师讨论如何提升自己的价值。知识就是力量，知识就是本钱，我们应该以这次培训为契机认真学，努力学。
其次，责任重于泰山，无为则殆。做而不学等于蛮干，学而不做等于白学。我们学习的根本目的就是要用所学的知识来指导我们做事。通过这次学习，我更清楚地感到自己肩上责任的重大，无论我们从事哪种行业，无论我们身兼何职，责任心、使命感和进取心是我们一辈子不能舍弃的东西。通过这次学习，使我感觉到学习的重要性和紧迫性，我们学习的自觉性、主动性、积极性得到了激发，把所学的知识应用到自己的岗位当中，提升自己的价值，当我们付出艰苦劳动得到的产品传递的客户那里，获得的是一份肯定，一份赞赏时，我们才可以如释重负，我们的努力才没有白费。
最后，学以致用，做好本职工作。通过五天的学习，使我的理论水平、知识素养都有了很大的提高，但归根到底还是要把工作做好。NO excuse！不为失败找借口，要为成功找方法。我们在工作中要完成一项工作，往往会碰到这样那样的问题和困难，如何正确的对待这些问题和困难?没有任何借口，只有千方百计地寻找解决问题、克服困难的办法。
北京学习虽然短暂，但是我们从中获得的东西却是受益终生的！
性能测试工程师心得 篇2
1 测试系统环境的配置
1.1 原型系统基本原理
集中式NAT-PT簇负载均衡系统解决方案中,核心节点是DNS-ALG[3]和n个NAT-PT,其中DNS-ALG与n个NAT-PT是通过高速的内网相连的,并且,他们之间要传送数据和命令。在实现各个节点之间通信时采用图1的结构,给每台机器装配对应的软件系统。
1.2 硬件整体构架搭建
根据图1负载调度通信系统结构,搭建的实验测试环境如图2所示(最基本的环境配置)。其中机器的配置如下:IPv6主机与IPv6 DNS服务器采用Linux9.0作为操作系统,在实验调试时将IPv4协议栈关闭,加载IPv6协议栈,使其成为纯IPv6机器。IPv4主机与IPv4 DNS服务器采用Linux9.0作为操作系统,在实验调试时将IPv6协议栈关闭,加载IPv4协议栈,使其成为纯IPv4机器。NAT-PT和DNS-ALG采用Linux9.0作为操作系统,全部安装三网卡,网卡1与IPv4侧网络相连、网卡2与IPv4侧网络相连、网卡3将DNS-ALG和NAT-PT组成高速内网。NAT-PT和DNS-ALG都同时加载IPv6协议栈、IPv4协议栈。
1.3 软件环境配置
1.3.1 DNS-ALG与NAT-PT的软件环境配置
1.3.1. 1 DNS-ALG与NAT-PT的Linux内核模块的编译
NAT-PT和DNS-ALG工作于双协议栈,需要对它们的Linux内核进行编译,具体编译过程如下:
1)首先以root身份登陆,进入源码所在目录,利用命令:cd/usr/src/Linux2.4.20;
2)清除操作系统中一些可能过期的中间代码,运行make clean;
3)配置支持IPv6协议栈内核选项:运行make xconfig(或make menuconfig、make config),将下面支持IPv6、IPtables和IP6tables的选项选上,其他内核选项可根据系统的具体情况作出符合系统的选择。
4)运行make dep,make clean;make bzImage。如果没有错误,则编译成了支持IPv6协议、IPtables、和IP6tables的内核;
5)将该内核拷贝到Linux的启动目录下,利用命令:cp arch/i386/boot/bzImage/boot/vmlinuz-IPv6;
6)编辑etc/grub.conf或etc/lilo.conf,使支持IPv6协议栈的新内核成为boot的选择。
7)最后,重启系统:reboot。重启系统之后,在登陆之前会发现有支持IPv6的内核信息出现,表明该主机是纯IPv6主机,同时有支持Netfilter配置的IPtables、IP6tables信息出现。
1.3.1. 2 DNS-ALG与NAT-PT翻译网关其它必要的配置
1)支持IPv6路由的配置
(1)配置/etc/sysconfig/network文件以支持IPv6路由,文件如下:
(2)系统有三块网卡,假设选定eth1为Pv6通信网卡,配置/etc/sysconfig/network-cripts目录下的ifcfg-eth1文件,该文件应该配置以下条目:
2)支持IPv4路由的配置
1.3.1. 3 应用软件的安装
1)建立/usr/src/natpt目录;
#mkdir/usr/src/natpt
2)将所有源文件拷贝到/usr/src/natpt目录;
3)在NAT-PT中有IPv4地址池,要给地址池分配IPv4地址。在应用过程中要配置IPv4_Addresses.list文件,配置如下:
4)配置nat-pt_global.h文件
5)编译应用软件并生成可执行文件;
运行:make。当修改了相关的配置文件,该应用软件需要再次编译,在再次编译时要求先运行make clean清除原有的可执行文件,再运行make生成可执行文件。
6)运行应用软件
1.3.2 路由配置
整个试验系统的地址分配情况如图3所示,NAT-PT在处理转换跨域连接时用到的IPv4、IPv6地址。另外,DNS-ALG与NAT-PT用于交换负载信息的内网地址没有在图3中体现出来,对于内网地址可以任意设定,只要求它们工作在同一个网段。
1.3.3 DNS的配置
1.3.3. 1 v4网络中DNS的配置
1)named文件的部分关键配置
2)seu.edu.cn文件的部分关键配置
1.3.3. 2 v6网络中DNS的配置
1)named文件的部分关键配置
2)sub.seu.edu.cn文件的部分关键配置
3)sub.rev文件的部分关键配置
2 NAT-PT簇负载均衡系统的测试
对于任何一个应用系统来说首先要求能正常工作,因此在本文的试验测试中首先对DNS-ALG的功能和NAT-PT的功能进行了测试。
2.1 Ethereal网络协议分析器分析IPv4、IPv6数据包测试系统功能
在DNS-ALG主机、NAT-PT主机安装了Ethereal网络协议分析器,Ethereal是一个为Unix和Window操作系统而设计的免费的网络协议分析器。它允许用户查看从活动网络或从磁盘上捕捉的文件,可以浏览被捕捉的数据,查看每一数据包的摘要或详细信息。
IPv4主机访问IPv6侧Web服务器时,用Ethereal网络协议分析器在NAT-PT主机上捕获了相应的数据包,同时,也可在IPv6主机访问IPv4侧Web服务器时,用Ethereal网络协议分析器在NAT-PT主机上捕获了相应数据包。图4所示为IPv4主机访问IPv6侧Web服务器时在NAT-PT主机上用Ethereal捕获的数据包。图中源地址(Source)192.168.1.10为IPv4侧发出访问的主机地址,目的地址(Destination)192.168.3.1为IPv6侧Web服务器的绑定地址。通过分析其中的命令判断DNS-ALG与NAT-PT功能。
2.2 系统性能测试
NAT-PT簇负载均衡的性能测试是分析算法的优越性,测试该算法在选择NAT-PT作为跨域节点时能否根据NAT-PT的负载性能动态地选择合适的NAT-PT。若用单一NAT-PT只需关闭其中NAT-PT服务器,使之只有一条NAT-PT服务器工作,并运行单一NAT-PT程序即可。采用动态负载均衡算法时,只需打开所有服务器,并按上述步骤分别安装对应不同算法程序即可进行各中算法比较,从而分析系统性能。
3 结束语
集中式NAT-PT负载均衡系统实现IPv4/IPv6互访的一个关键技术。文章对集中式NAT-PT负载均衡系统实践平台硬件环境搭建;整个系统的软件配置给出出来关键点配置说明;性能测试方面介绍了测试方法,在具体性能测试过程中应合理选择测试参数。
摘要：集中式NAT-PT负载均衡系统是提高IPv4/IPv6互访通信质量的一个关键技术。如何搭建一个与工程实践平台性能相当的测试平台,成为了集中式NAT-PT簇均衡系统工程应用研究的一个难点。文章对集中式NAT-PT负载均衡系统实验平台硬件环境搭建、软件配置与性能测试等方面进行深入的研究。
关键词：负载平衡,环境配置,平台
参考文献
[1]Tsirtsis GNetwork Address Translation-Protocol Translation(NAT-PT)[S].RFC27662000.
[2]傅强,郑纬民.一种使用于机群系统的任务动态调度方法[J].软件学报,1999(10):19-22.
性能测试报告 篇3
服务器软件：nginx/1.02.12
端口：80
一共测试了两次：
并发级别：10
完成请求：1000
完成时间：67.009 seconds
吞吐率：14.92/s 每秒相应14.92个请求
用户平均请求等待时间：670.088 毫秒
服务器平均请求等待时间 67.009 毫秒
每个请求处理时间的分布情况，50%的处理时间在552ms内，66%的处理时间在594ms内。Percentage of the requests served within a certain time(ms)
50%552
66%594
75%647
80%692
90%877
95%1018
98%3503
99%3596
100%3930
并发级别：100
完成请求：10000
完成时间：711.398 seconds
吞吐率：14.06/s 每秒相应14.92个请求
用户平均请求等待时间：7113.977 毫秒
服务器平均请求等待时间 71.140 毫秒
每个请求处理时间的分布情况，50%的处理时间在6011ms内，66%的处理时间在6454ms内。
Percentage of the requests served within a certain time(ms)
50%6011
66%6454
75%7220
80%7566
90%9422
95%12017
98%20382
99%28455
实验性能测试工具3 篇4
2.2. 使用
在unix系统中，可以直接运行可执行程序来启动netserver，也可以让inetd或xinetd来自动启动netserver。当netserver在server端启动后，就可在client端运行netperf来测试网络的性能。netperf通过命令行参数来控制测试的类型和具体的测试选项，根据作用范围的不同，netperf的命令行参数可以分为两大类：全局命令行参数、测试相关的局部参数，两者之间使用--分隔。
netperf语法格式为:
Netperf [global options] C-[test-specific options]
[global options] 可选参数，其中可选的参数有如下几个：
[test-specific options] 可选参数，其中可选的参数有如下几个： 远程主机： NPtcp [options]
本地主机： NPtcp -h remote_host [options]
2.3. 应用实例第一文库网
2.3.1. 批量(bulk)网络流量的性能
批量数据传输典型的例子有ftp和其它类似的网络应用(即一次传输整个文件)。根据使用传输协议的不同，批量数据传输又分为TCP批量传输和UDP批量传输。
1. TCP_STREAM
Netperf缺省情况下进行TCP批量传输，即-t TCP_STREAM。测试过程中，netperf向netserver发送批量的TCP数据分组，以确定数据传输过程中的吞吐量：
从netperf的结果输出中，我们可以知道以下的一些信息：
1) 远端系统(即server)使用大小为87380字节的socket接收缓冲
2) 本地系统(即client)使用大小为16384字节的socket发送缓冲
3) 向远端系统发送的测试分组大小为16384字节
4) 测试经历的时间为60秒
5) 吞吐量的测试结果为88Mbits/秒
在缺省情况下，netperf向发送的测试分组大小设置为本地系统所使用的socket发送缓冲大小。TCP_STREAM方式下与测试相关的局部参数如下所示：
通过修改以上的参数，并观察结果的变化，我们可以确定是什么因素影响了连接的吞吐量。例如，如果怀疑路由器由于缺乏足够的缓冲区空间，使得转发大的分组时存在问题，就可以增加测试分组(-m)的大小，以观察吞吐量的变化：
在这里，测试分组的大小减少到2048字节，而吞吐量却没有很大的变化(与前面例子中测试分组大小为16K字节相比)。相反，如果吞吐量有了较大的提升，则说明在网络中间的路由器确实存在缓冲区的问题。
2. UDP_STREAM
UDP_STREAM用来测试进行UDP批量传输时的网络性能。需要特别注意的是，此时测试分组的大小不得大于socket的.发送与接收缓冲大小，否则netperf会报出错提示：
为了避免这样的情况，可以通过命令行参数限定测试分组的大小，或者增加socket的发送/接收缓冲大小。UDP_STREAM方式使用与TCP_STREAM方式相同的局部命令行参数，因此，这里可以使用-m来修改测试中使用分组的大小：
UDP_STREAM方式的结果中有两行测试数据，第一行显示的是本地系统的发送统计，这里的吞吐量表示netperf向本地socket发送分组的能力。但是，我们知道，UDP是不可靠的传输协议，发送出去的分组数量不一定等于接收到的分组数量。
第二行显示的就是远端系统接收的情况，由于client与server直接连接在一起，而且网络中没有其它的流量，所以本地系统发送过去的分组几乎都被远端系统正确的接收了，远端系统的吞吐量也几乎等于本地系统的发送吞吐量。但是，在实际环境中，一般远端系统的socket缓冲大小不同于本地系统的socket缓冲区大小，而且由于UDP协议的不可靠性，远端系统的接收吞吐量要远远小于发送出去的吞吐量。
2.3.2. 请求/应答(request/response)网络流量的性能
另一类常见的网络流量类型是应用在client/server结构中的request/response模式。在每次交易(transaction)中，client向server发出小的查询分组，server接收到请求，经处理后返回大的结果数据。如下图所示：
Netperf输出的结果也是由两行组成。第一行显示本地系统的情况，第二行显示的是远端系统的信息。平均的交易率(transaction rate)为9502.73次/秒。注意到这里每次交易中的request和response分组的大小都为1个字节，不具有很大的实际意义。用户可以通过测试相关的参数来改变request和response分组的大小，TCP_RR方式下的参数如下表所示：
通过使用-r参数，我们可以进行更有实际意义的测试：
从结果中可以看出，由于request/reponse分组的大小增加了，导致了交易率明显的下降。注：相对于实际的系统，这里交易率的计算没有充分考虑到交易过程中的应用程序处理时延，因此结果往往会高于实际情况。
2. TCP_CRR
与TCP_RR不同，TCP_CRR为每次交易建立一个新的TCP
连接。最典型的应用就是HTTP，每次HTTP交易是在一条单独的TCP连接中进行的。因此，由于需要不停地建立新的TCP连接，并且在交易结束后拆除TCP连接，交易率一定会受到很大的影响。
即使是使用一个字节的request/response分组，
交易率也明显的降低了，只有2662.20次/秒。TCP_CRR使用与TCP_RR相同的局部参数。
3. UDP_RR
UDP_RR方式使用UDP分组进行request/response的交易过程。由于没有TCP连接所带来的负担，所以我们推测交易率一定会有相应的提升。
结果证实了我们的推测，交易率为10141.16次/秒，高过TCP_RR的数值。不过，如果出现了相反的结果，即交易率反而降低了，也不需要担心，因为这说明了在网络中，路由器或其它的网络设备对UDP采用了与TCP不同的缓冲区空间和处理技术。
3. 参考资料
www.netperf.org/netperf
性能测试工程师心得 篇5
发布时间: 2012-3-09 13:52 作者: xiaowan 来源: TaoBao QA Team 字体: 小 中 大 |上一篇下一篇 |打印 |我要投稿 |推荐标签：性能测试软件测试
Android手机客户端的性能测试开展近3个月了，期间包括性能监测工具的开发周期和工具的投入使用和优化；客户端性能测试从这里起步，从这里开始。
一般情况，对于新生的产品，都会用定势的思维考虑：优先功能测试，之后才会是安全、性能等方面。android客户端从诞生到现在，在测试上走的也是这样的路线。随着客户端功能越来越完善、越来越繁大，用户群越来越多，性能、响应、稳定等被正式提上议程，重点考虑关注。
为什么我们要从以上几个点来考虑客户端性能呢？ 针对上面的几个点我们是如何开展监控测试的？如何来评估一个客户端的性能好不好，是否给予通过？下面就我自己看法跟大家详细交流。
有数据统计：有很大一部分人群喜欢睡觉前、公交车、厕所、或者会议中开小差中使用手机；在看下移动互联网的发展趋势【下图摘自某次互联网统计报告】：
在上图为各大运营商所占移动市场份额的变化情况：整体上移动用户数仍绝对领先，但其市场份额也明显的下降趋势，百度推断导致此变化的原因是基础网络的性能已经开始影响移动互联网应用的使用，即网络到底好不好，速度到底快不快，已经开始在影响应用市场份额了。同样，对用户而言：特定网络下客户端流畅不流畅、响应快不快决定着用户对客户端的使用时长和粘度；此外，用户在考虑速度的同时，还会考虑跟自身利益相关的—-金额&网络流量的消耗。
一个成熟的场景包括：人、时间、地点、行为。换言之：什么特征的人在什么情况下会使用比较容易比较经常使用客户端，他们又经常使用客户端的哪些面呢？
在客户端性能监测前，我们需要采集真实场景中的性能数据：2G的网络下的时间指标、访问量较多页面的流量消耗情况、整个客户端的稳定情况。
（1）稳定性测试：【不同网络、不同软硬件系统下】
客户端可稳定运行的时间、以及长时间操作后的流量消耗和内存消耗；
（2）性能测试指标：【不同网络下】
界面流畅性、界面切换时间、占用的内存数、服务器返回数据消耗流量大小及数据的返回时间；
对以上的点，有几种方法可以采用来监测。现在我们使用的是自己开发的客户端性能工具。其中：流量统计使用TrafficStats.getUidRxBytes()来获取下行流量值；响应时间通过判断activity的状态和日志中记录的时间戳来获取响应时间段； 内存通过解析dumpsys命令返回内容，截取我们需要的值进行分析；电量统计android系统提供查看。除了自己研发的小工具之外，外界也提供很多工具，都可以帮助我们完成相关的性能监测。
竹炭纤维性能研究与测试 篇6
1 竹炭纤维的开发[1]
竹炭在纺织中的应用途径基本上有3种∶
其一, 在纺丝过程中将超细甚至是纳米竹炭粉末加入到纺丝流体中制成竹炭纤维。一般选用粘胶基材, 因为纤维素的透气性比合成纤维树脂切片的要高很多, 适合开发新一代保健性功能纤维。
其二, 在涤纶、丙纶、腈纶、粘胶纤维等表面涂上超细竹炭添加剂。这是超细纳米技术和纺织工程相结合的产品, 是将天然植物添加剂移植到化纤中的一个新亮点。
其三, 将竹炭粉末分散到水溶性、热塑性树脂中, 将组合后的树脂涂抹在梭织物、针织物等基布之上。对于涂布量需求较少的被覆膜, 可采用点状被覆。反之, 宜采用全面被覆方式。
在此重点介绍由第1种途径开发的竹炭改性涤纶纤维。即指将竹炭超微颗粒与聚酯通过共混纺丝而制成的竹炭涤纶纤维, 并对这种具有多微孔结构及超强吸附、抗静电、抗菌、防霉、发射负离子等特殊功能的涤纶纤维[2]进行测试。
2 性能测试[3,4]
对竹炭改性涤纶纤维性能的研究是为其产品开发服务的, 本试验选用与其可纺性, 服用性能等有关的指标进行测试研究, 并且与纯涤纶纤维进行性能指标的对比, 见表1。
注:A, B为竹炭改性涤纶纤维, C为纯涤纶纤维
2.1 纤维回潮率的测试
试验仪器:Y802A型八吊篮烘箱:
试验结果与分析:竹炭涤纶纤维与纯涤纶纤维的回潮性能比较见表2。
从竹炭改性涤纶纤维和涤纶纤维的回潮率测试中可以看出, 前者由于竹炭颗粒的存在, 较好地改善了纤维的回潮率, 且随着竹炭在纤维中含量的增加, 纤维的回潮率也随着增加。这是由于竹炭改性涤纶纤维的竹炭颗粒有吸附的功能, 因此使得竹炭改性涤纶纤维比一般的涤纶纤维吸湿性能更好, 用其制作的服装穿着舒适, 适合于制作夏季及贴身穿着的服装、运动服装等, 具有良好的服用性能。
2.2 纤维比电阻性的测试
试验仪器:YG321型纤维比电阻仪;
试验结果:竹炭涤纶纤维与纯涤纶纤维的比电阻性能比较见表3。
由上表可以看出, 竹炭改性涤纶纤维的表面质量比电阻明显低于普通纯涤纶纤维, 这意味着竹炭改性涤纶纤维具有良好的抗静电能力。这是由于竹炭改性涤纶纤维具有良好的吸湿性的原故, 使得其抗静电性能好。用其制作的服装穿着时比较舒服, 不会因静电而有吸附在身上的贴身感, 不易粘着灰尘。这也表明它具有良好的服用性能。
2.3 摩擦性能的测试
试验仪器:Y151型纤维摩擦系数测定仪;
试验结果与分析:竹炭涤纶纤维与纯涤纶纤维的摩擦性能比较见表4。
从上表的测试结果可以看出, 竹炭改性涤纶纤维的摩擦系数较小, 纤维比较光滑, 纤维的动、静态摩擦系数相差不大。涤纶纤维采用熔体纺丝, 截面呈圆形, 表面很平整, 使纤维相对滑动时接触面积不大, 摩擦系数高。竹炭改性涤纶纤维是将高温炭化技术烧制的竹炭, 利用纳米技术微粉化, 再通过熔融纺丝程序把竹炭次纳米级微粉均匀地融入化学纤维中, 这使得其表面具有一定的粗糙, 表面积相对有所增大, 从而其摩擦系数得以减小。
由实验得出的数据可以看出, 橡胶辊的动、静摩擦系数, 竹炭纤维与涤纶纤维相比都有减小, 是因为含竹炭量的多少对纤维摩擦性能的影响不是很显著。
2.4 纤维强力的测试
试验仪器:YG004E型电子单纤维强力仪;
试验结果与分析:竹炭涤纶纤维与纯涤沦纤维的耐酸碱性能比较见表5。
注:A1, B1, 为竹炭涤纶改性纤维是A, B在18%的HCl溶液中浸泡2h, 温度30℃。A2, B2, 为竹炭涤纶改性纤维是A, B在0.5%的Na OH溶液中浸泡2h, 温度30℃。
3 结语
由实验数据可得:竹炭改性涤纶纤维经浓度为18%的HCl处理后与未处理前相比, 其强力、强度、伸长率都没有太大变化, 而经浓度为0.5%的Na OH处理后, 其拉伸强度、强力有所明显的减小。由此, 可得酸对竹炭改性纤维的力学性能没有大的影响, 强碱对其强度有很大的损害。这说明在织物的后面加工过程中, 应注意不能用强碱性的物质对其加工。竹炭纤维所具有的耐酸不耐碱性, 决定了其纱线和织物也具有这种性能, 这让我们注意织物的印染后整理中采用适当的处理工艺。
参考文献
[1]李旭明.竹炭纤维的开发与应用[J].针织工业2007, (10) :21-22.
[2]林力.台湾大力开发竹炭纤维[N].中国绿色时报, 2005-9-29 (07) .
[3]姚穆, 周锦芳.纺织材料学[M].北京∶中国纺织出版社, 1988.
性能测试工程师心得 篇7
主要从以下几部分来说明，关于内存和内存泄露、溢出的概念，区分内存泄露和内存溢出;内存的区域划分，了解GC回收机制;重点关注如何去监控和发现内存问题;此外分析出问题还要如何解决内存问题。
下面就开始本篇的内容：
第一部分 概念
众所周知，java中的内存java虚拟机自己去管理的，他不想C++需要自己去释放。笼统地去 讲，java的内存分配分为两个部分，一个是数据堆，一个是栈。程序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系。但 是如果程序员声明了static的变量，就直接在栈中运行的，进程销毁了，不一定会销毁static变量。
另外为了保证java内存不会溢出，java中有垃圾回收机制。System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。
而其中，内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出。
内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问，该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越 多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。
第二部分 原理
JAVA垃圾回收及对内存区划分
在Java虚拟机规范中，提及了如下几种类型的内存空间：
◇ 栈内存(Stack)：每个线程私有的。
◇ 堆内存(Heap)：所有线程公用的。
◇ 方法区(Method Area)：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。
◇ 原生方法栈(Native Method Stack)：主要用于JNI中的原生代码，平时很少涉及。
而Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，“垃圾回收”也是主要是和堆内存(Heap)有关。
垃圾回收的概念就是JAVA虚拟机(JVM)回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”，而没有 被应用或者取不到引用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于 应用运行当中，自动回收。
JVM的垃圾回收器采用的是一种分代(generational)回收策略，用较高的频率对年轻的对象(young generation)进行扫描和回收，这种叫做minor collection，而对老对象(old generation)的检查回收频率要低很多，称为major collection。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观察和回收。
(Sun JVM 1.3 有两种最基本的内存收集方式：一种称为copying或scavenge，将所有仍然生存的对象搬到另外一块内存后，整块内存就可回收。这种方法有效率，但需要有一定的空闲内存，拷贝也有开销。这种方法用于minor collection。另外一种称为mark-compact，将活着的对象标记出来，然后搬迁到一起连成大块的内存，其他内存就可以回收了。这种方法不 需要占用额外的空间，但速度相对慢一些。这种方法用于major collection.)
一些对象被创建出来只是拥有短暂的生命周期，比如 iterators 和本地变量。
另外一些对象被创建是拥有很长的生命周期，比如 高持久化对象等。
垃圾回收器的分代策略是把内存区划分为几个代，然后为每个代分配一到多个内存区块。当其中一个代用完了分配给他的内存后，JVM会在分配的内存 区内执行一个局部的GC(也可以叫minor collection)操作，为了回收处于“dead”状态的对象所占用的内存。局部GC通常要不Full GC要快很多。
JVM定义了两个代，年轻代(yong generation)(有时称为“nursery”托儿所)和老年代(old generation)。年轻代包括 “Eden space(伊甸园)”和两个“survivor spaces”。虚拟内存初始化的时候会把所有对象都分配到 Eden space，并且大部分对象也会在该区域被释放。当进行 minor GC的时候，VM会把剩下的没有释放的对象从Eden space移动到其中一个survivor spaces当中。此外，VM也会把那些长期存活在survivor spaces 里的对象移动到 老生代的“tenured” space中。当 tenured generation 被填满后，就会产生Full GC，Full GC会相对比较慢因为回收的内容包括了所有的 live状态的对象。pemanet generation这个代包括了所有java虚拟机自身使用的相对比较稳定的数据对象，比如类和对象方法等。
关于代的划分，可以从下图中获得一个概况：
如果垃圾回收器影响了系统的性能，或者成为系统的瓶颈，你可以通过自定义各个代的大小来优化它的性能。使用JConsole，可以方便的查看到当前应用所配置的垃圾回收器的各个参数。想要获得更详细的参数，可以参考以下调优介绍：
Tuning Garbage collection with the 5.0 HotSpot VM
http://java.sun.com/docs/hotspot/gc/index.html
最后，总结一下各区内存：
Eden Space(heap)： 内存最初从这个线程池分配给大部分对象。
Survivor Space(heap)：用于保存在eden space内存池中经过垃圾回收后没有被回收的对象。
Tenured Generation(heap)：用于保持已经在 survivor space内存池中存在了一段时间的对象。
Permanent Generation(non-heap): 保存虚拟机自己的静态(refective)数据，例如类(class)和方法(method)对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的，Code Cache(non-heap):HotSpot Java虚拟机包括一个用于编译和保存本地代码(native code)的内存，叫做“代码缓存区”(code cache)
第三部分 监控(工具发现问题)
谈到内存监控工具，JConsole是必须要介绍的，它是一个用JAVA写的GUI程序，用来监控 VM，并可监控远程的VM，易用且功能强大。具体可监控JAVA内存、JAVA CPU使用率、线程执行情况、加载类概况等，Jconsole需要在JVM参数中配置端口才能使用。
由于是GUI程序，界面可视化，这里就不做详细介绍，具体帮助支持文档请参阅性能测试JConsole使用方法总结：
http://
http://Java.sun.com/javase/6/docs/technotes/tools/share/jconsole.html
在实际测试某一个项目时，内存出现泄露现象。起初在性能测试的1个小时中，并不明显，而在稳定性测试的时候才发现，应用的HSF调用在经过几个 小时运行后，就出现性能明显下降的情况。在服务日志中报大量HSF超时，但所调用系统没有任何超时日志，并且压力应用的load都很低。经过查看日志后，认为应用可能存在内存泄漏。通过jconsole 以及 jmap 工具进行分析发现，确实存在内存泄漏问题，其中PS Old Gen最终达到占用 100%的占用。如图所示：
从上图可以看到，虽然每次Full GC，JVM内存会有部分回收，但回收并不彻底，不可回收的内存对象会越来越多，这样便会出现以上的一个趋势。在Full GC无法回收的对象越来越多时，最终已使用内存达到系统分配的内存最大值，系统最后无内存可分配，最终down机。
第四部分 分析
经过开发和架构师对应用的分析，查看此时内存队列，看哪个对象占用数据最多，再利用jmap命令，对线程数据分析，如下所示：
num #instances #bytes class name
1: 9248056 665860032 com.taobao.matrix.mc.domain.**
2: 9248031 295936992 com.taobao.matrix.**
3: 9248068 147969088 java.util.**
4: 1542111 37010664 java.util.Date
前三个instances不断增加，指代的是同一个代码逻辑，异步分发的问题，堵塞消息，回收多次都无法回收成功。导致内存溢出。
此外，对应用的性能单独做了压测，他的性能只能支撑到一半左右，故发送消息的TPS，应用肯定无法处理过来，导致消息堆积，而JAVA垃圾回收期认为这些都是有用的对象，导致内存堆积，直至系统崩溃。
调优方法
由于具体调优方法涉及到应用的配置信息，故在此暂不列出，可以参考性能测试小组发布的《性能测试调优宝典》
第四部分 总结
内存溢出主要是由于代码编写时对某些方法、类应用不合理，或者没有预估到临时对象会占用很大内存量，或者把过多的数据放入JVM缓存，或者性能 压力大导致消息堆积而占用内存，以至于在性能测试时，生成庞大数量的临时对象，GC时没有做出有效回收甚至根本就不能回收，造成内存空间不足，内存溢出。
性能测试工程师心得 篇8
燃煤电厂综合升级改造机组性能测试管理细则
为规范燃煤电厂开展综合升级改造的机组性能测试和效果审核管理工作，制定本细则。
一、确定机组测试机构。国家能源局、财政部按照机组测试机构回避该公司系统和所在省（区、市）的原则，从机组测试机构名单中委托有关机构对燃煤电厂综合升级改造项目进行性能测试。中央财政按照相关规定支付性能测试费用。
二、制定改前测试方案。省级能源主管部门负责本地区机组性能测试的全过程协调服务，组织省级电网公司、项目单位和测试机构等制定机组改造前性能测试方案，明确测试方法、测点、条件、时限和相关责任，并报送国家能源局电力司（方案扫描版发指定邮箱）。
三、开展改前现场测试。按照测试方案，项目单位应落实测试条件；电网调度机构做好机组性能测试配合工作，妥善安排电力系统运行；测试机构在省级电网公司、项目单位配合下，独立、公正开展改造前现场测试工作。
四、编制改前测试报告。测试完成后，测试机构应按照《燃煤电厂综合升级改造实施前机组性能测试报告（提纲）》要求，编制测试报告，在5个工作日内报送国家能源局电力司、财政部经建司，抄送省级能源主管部门、财政部门和项目单位（报告扫描版发指定邮箱）。项目单位确认相关单位收到测试报告后，5个工作日内未接到抽查通知的，即可实施停机改造。
五、制定改后测试方案。机组改造完成后，省级能源主管部门组织省级电网公司、项目单位和测试机构等制定机组改造后性能测试方案，并报送国家能源局电力司（方案扫描版发指定邮箱）。除供热项目外，改造后性能测试应在改造后2个月内完成。
六、开展改后现场测试。按照测试方案，项目单位应落实测试条件，使其与改造前测试基本一致；电网调度机构做好测试配合工作，妥善安排电力系统运行；测试机构原则上应安排改造前试验人员、使用相同仪器和设备，在省级电网公司、项目单位配合下，独立、公正开展改造后现场测试工作。
七、编制改后测试报告。测试完成后，测试机构应按照《燃煤电厂综合升级改造实施后机组性能测试暨实施效果报告（提纲）》要求，编制测试报告，比对改造前、后的测试结果，进行能量平衡和能效校核，对机组改造后的能效、实际年节能量等做出结论，并在5个工作日内将测试报告报送国家能源局电力司、财政部经建司，抄送省级能源主管部门、财政部门和项目单位（报告扫描版发指定邮箱）。
八、供热项目测试报告。纯凝机组改供热和热电机组扩大供热能力的改造项目，项目单位应做好关停替代分散小锅炉的调查、记录。供热满一年（工业负荷）或一个采暖季（居民采暖负荷）后，通知测试机构校核供热量。测试机构应在补充完成供热量校核后，5个工作日内提交机组改造后性能测试报告。
九、加强监督检查。测试机构、项目单位应按档案管理相关规定，留存机组性能测试、校核、改造实施的详细资料以备检查。国家能源局将视情况委托有关机构抽查审核项目改前、改后测试报告，必要时复测机组能效。
任何单位和个人不得妨碍测试机构独立、公正开展工作。对弄虚作假、骗取政策支持的项目单位，一经查实，将收回奖励资金，取消奖励规模，并建议有关部门依法追究相关人员的责任。
冷却塔喷嘴性能测试 篇9
常用喷嘴的主要特性主要包括泄流能力、喷溅范围、喷溅的均匀性、液滴大小、冲击力、材料等。冷却塔喷头设计、选型比较关注的是泄流能力、喷溅范围、喷溅均匀性, 可以用图3试验装置进行测量。喷溅装置安装在试验水池内, 由水泵经供水管供水, 水池底面方格布置, 水池深精度±1毫米, 试验水池内安装一水平器, 保证水池水位稳定。进水压力、进水流量, 喷头到水池顶面高度H都可以调整。
1泄流能力即泄流量
指单个喷嘴单位时间内所排泄的水量, 用公式表示为
式中Q—泄流量, m3/s;
μ—流量系数;
A—管嘴出口处过流面积, m2;
H—作用在管嘴出口断面的水头, m;
g—重力加速度, m/s2;
2喷嘴的喷溅范围
用相机拍下喷头喷射的正投影, 然后在照片上确定喷淋水直线部分, 在直线部分测量其角度, 通过调整喷嘴高度和压力测出不同喷淋半径和流量。根据实验测得Q、H、和喷洒半径α可以做出相应的曲线, 如根据表1一组实验数据绘出了图4 H-α曲线, 为冷却塔布水设计提供参考依据。测量的数据越多, 计算的μ值、绘制的性能曲线也就越准确。
3 喷溅的均匀性
喷溅的均匀性是指在喷溅范围内各点的淋水密度是否均匀, 喷嘴安装在水池底面, 调整不同的喷嘴高度h, 测量该高程上的淋水密度, 看喷嘴的淋水是否均匀。因为喷嘴的淋水是轴对称的, 所以测量一个半径上的值就可以了。测量方法是用一个长方形的接水槽, 分割成若干小格 (每格如10cm×10cm) , 放在要测的高程上, 计量接水时间, 测出每格的水量, 并算出该高程上径向每格的淋水密度, 淋水均匀性程度用溅水均匀性分布系数来表示, 溅水均匀分布系数表达式如下:
式中:ao—溅水均匀分布系数;
N—小方格总数。
用式4-1计算器均方差ao, 用以判断其均匀性, 对于单个喷嘴, ao越小说明其均匀性好, 但是在冷却塔中是多喷头共同运行交叉喷淋的, 交叉后的喷淋均匀性随喷嘴的布置方式, 间距, 压头变化, 所以淋水的均匀性不能用一个喷头来衡量, 而应测量其组合下的淋水分布。
4 结论
喷嘴的评价标准为 : 一定压力下的流量、喷洒面积、喷洒角度, 喷洒的均匀性, 相同压力下喷洒流量越大、喷洒越均匀、角度越大性能就越好;另外冷却水量在一定范围内变化时, 喷洒无明显恶化, 不易堵塞, 污物容易清理, 易更换和维修也非常重要, 当然所有优良因素均有的喷嘴比较难找, 这就需要根据具体要求有所取舍, 选择符合设计需求的喷嘴。
参考文献
[1]赵振国.冷却塔[M].中国水利水电出版社.
[2]侯红立, 王银华等.冷却塔淋水填料性能试验台的研制[M].工业用水与废水, 2010.
[3]薛新宇, 柳平增等.喷头综合性能测试实验台的研制及应用[M].2006中国农机化.
性能测试工程师心得 篇10
上表中显示，MariaDB 5.5 不管是在吞吐量还是响应时间方面都是优于 MySQL 的。
但是，为什么 MariaDB 在 Windows 下的只读测试由于 MySQL 5.5 呢?二者基于同一个代码，表现应该也相同啊。这个问题的答案并不是 MariaDB 做了什么优化，也无关 XtraDB 和 InnoDB 的优劣。答案是 MariaDB threadpool. 这个线程池在 Windows平台是默认启用的。
可是，为什么使用线程池就可以有如此好的性能呢?答案是 MariaDB 承担了通过调整线程池的大小并回调到对应的 Windows 本身的线程池，这在操作系统这一级别上相当于黑盒排序，因此能获取良好的性能。关键在于 Windows 内置的线程池，受益于 IOCP(I/O Completion Port，I/O完成端口)是性能最好的一种I/O模型。这是 Windows 专有的特性，运行在其上的服务器应该使用这种技术。要让这项技术运行良好的招数是：
不要让同一时间在同一个 CPU 上运行太多的线程，这样可减少上下文切换，这是提高吞吐量的最重要的因素
在完成的 LIFO 顺序中激活线程等待，热门的线程保持热门，可降低缓存失效
顺序处理 IO 完成，这是响应时间表现良好的因素
最后便是降低热锁的争用
由此，线程池是只读性能表现佳的主要因素，
下一个有趣的问题是在写操作上 MariaDB 表现是否一致。因此我们使用写模式来运行 sysbench 工具，也就是update_non_index(每个查询对一个非索引的整数字段进行加值处理)。为了最大化写的吞吐量，我们设置了参数innodb_flush_log_at_trx_commit值为 0，每次日志的写入是每秒一次，而不是每次事务提交一次。
性能测试工程师心得 篇11
会议纪要
2012-7-31、厂家普遍采用保护小CT用于合并单元，未考虑暂态特性，也未考虑录波、PMU
等特殊用途。目前需要所有厂家考虑传统保护CT移至过程层，所将面临的问题，并一一列出。调研相关的专用小CT产品和技术。
2、目前市场存在符合各类需求的小CT，满足暂态或者变送的需求，但可靠性等需
要验证。如果合并单元能够真实反映一次电网原始波形，则保护装臵的算法需要加以处理，因为目前多数厂家的数字化保护是基于合并单元的保护小CT特性的。
3、合并单元作为公共的采集单元，应真实的传变电网一次侧模拟量特性。
4、GPS失步再同步的过程中，应保证采样值点对点输出接口报文的发送间隔。
5、静电放电试验按照运行配臵，可不带PPS输出进行。
6、测量电流相位误差在高低温环境下应满足10分，保护电流相位误差满足60分的要求。
7、测试结果的总结中，可将问题按影响重要性等级分类，以反映装臵的水平。
8、需补充测试内容：
a)按照点对点额定延时方式，重新测试所有端口的相位误差；
b)验证合并单元所有端口的相位误差的一致性；
c)ICD文件与实际输出数据集的一致性；
d)测试MU负载（输入阻抗），交流阻抗；
e)交流叠加直流的电源干扰试验。
9、分析研究内容
a)分析合并单元时间精度和相位误差的关联关系；
b)验证合并单元精确度的稳定性（均方根），比较暂态波形的复合误差和最大
瞬时误差；
c)暂态标准参考GB/T16847标准，进行评价。5P的CT指标参考GB/T20840.8； d)提出应用技术原则，指导工程应用。
10、下一步工作
a)补充MU技术规范、测试规范
b)MU现场试验规范
11、进一步研究内容
a)调研国内外就地电磁兼容试验研究现状，研究、设计电磁干扰（开关刀闸操
作）测试方案
b)现场MU接地方案研究
c)MU与其他设备的普适性研究
12、时间节点安排
a)7月10日完成补充试验
b)7月中旬集中总结
c)7月下旬总结会议
d)8月MU相关规范
e)三周后给厂家试验研究报告，随后三周内厂家反馈整改方案
数据库性能测试的研究 篇12
如今,各种数据库系统处理的数据量越来越大,处理数据时遇到的问题也是方方面面的,因此,数据库的性能已经成为不同系统之间的主要差异因素。随着软件和网络应用的迅速发展,数据库发挥的作用越来越重要。其糟糕的性能在很大的程度上制约着数据库处理并发事务的能力,同时还影响着数据库的一致性。数据库的功能完善程度和性能稳定性直接影响着软件的执行效率。所以,数据库性能测试已经成为数据库领域的一个热门话题。
2 数据库性能测试
2.1“性能测试”概念
“性能测试”主要指首先全面系统地了解掌握系统运行过程中会遇到的各种正常或者异常负载的条件,然后自己编写代码模拟这些条件,测试所设计的数据库系统在面临各种条件时的运行情况并加以记载、分析和总结。
2.2“性能测试”目的
数据库性能测试的目的是测试该系统是否可以满足不同用户提出的各种要求,在测试中发现本系统运行的性能瓶颈,最终达到优化数据库系统的目的。评价数据库的性能时,选用真实的、具有代表性的、工作中实际使用的项目。面临新的程序或者要扩展新的功能时,设计者能够使用负载测试来判断系统是否可以处理用户期望的负载,从而了解该数据库系统将来的性能。
性能测试的目的有以下几个:
1)优化系统:反复对数据库系统进行性能测试,根据测试结果不断地对系统进行调整,以达到优化系统性能的目的。
2)找出设计中的缺点:测试过程中,发现由于数据库中的某个设计使得受控的负载增加到当前状态下的一个临界点,就可以想办法来改变这个设计,突破这个临界点,达到修复系统瓶颈的目的。
3)对数据库系统整体评估:可以根据性能测试的结果来评估数据库系统各方面的性能,使设计与实际应用挂钩,这对设计者修改系统设计有很大帮助。
4)验证系统的可靠性和稳定性:通过在一定的负载下运行一定时间的数据库系统,可以很好地评估系统是否可靠和稳定。
2.3“性能测试”指标
资源利用率:指对不同系统资源的使用程度,是我们测试和分析瓶颈的主要对象。
吞吐量:一次数据库性能测试中,网络上传输的总的数据量就叫“吞吐量”。我们用单位时间内传输的数据量来衡量网络的性能。
并发:指许多的用户同时做同样的一个操作。通过并发操作,我们可以看到系统是否稳定,并发现系统设计中的问题。
请求响应时间:是指从客户端发出一个请求,到接收到服务器端返回的结果之间的时间
3 数据库性能基准测试
“性能基准测试”是指根据性能基准设计检测程序,搭建检测环境,进行性能测试,并把检测结果与相同检测程序在相同系统或另外系统上的运行结果相比较的整个过程。在数据库性能评估方面,目前存在着两个标准的基准程序系列:TPC和SPEC。其中,最具权威性也是应用最广泛的是TPC系列基准。
3.1 基准测试标准TPC
国际上TPC组织提出的数据库性能测试标准和规范,是最为大家所熟悉的数据库测试规范。TPC是事务处理委员会(Transaction Processing Council)的缩写,它的职责是制定商务应用基准程序的价格度量和标准规范,并依据这些基准测试项目发布客观性能数据。
现在流行的由TPC发布的基准程序有四种:
TPC-C:联机事务处理的基准测试。
TPC-H:针对数据仓库或决策支持系统的基准测试。
TPC-R:商业报告以及决策支持的基准测试。
TPC-W:基于事务处理的互联网电子商务的基准测试。
在TPC发布的所有基准测试当中,数据库性能测试主要涉及TPC-C基准测试。
3.2 TPC-C基准测试
TPC-C是专门针对联机交易处理系统(OLTP系统)的,它还适用于与数据库相关的整个服务器系统(包括硬件平台、操作系统和数据库系统)性能的测试,对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。一般情况下我们也把这类系统称为业务处理系统。
TPC-C模拟了一个复杂的环境,大量的终端操作者可以在同一个数据库上频繁得执行各种事务。它建立了一个“销售-订购系统”的事务处理模型,其中包括:生成订单、分发订单、记录付款、订单查询、仓储查询。这个环境以新增订单事务为核心活动,其它事务包括在一个仓库范围内区域中进行的支付操作、订单状态查询、发货、库存水平查询。TPC-C的内容并不仅限于某个特定的商业运行环境,而是体现了任何一个可以管理,销售,分配产品及服务的通用的商业环境。国际事务处理委员会认为这种“销售-订购系统”代表了商务数据库处理的典型事务,用它来测量联机交易处理系统(OLTP)数据库性能具有普适性。
4 数据库性能测试工具构架的设计
该文提出了对数据库性能测试工具构架的设计,主要内容如下:
4.1 设计要求
可扩展:减少设计中的多余的代码和设计人员的重复劳动。
可控:由调度程序来控制构架的运作。
互通:在虚拟程序相互之间,在虚拟程序和调度之间必须可以互相协调完成对系统性能的测试。
可分布:如果一台计算机不能够产生足够多的数据库负载,需要把很多的虚拟程序分布在许多不同的计算机上,通过这种方式来取得足够多的数据库负载。
效率高:虚拟用户程序之间应该要有很高的执行命令效率和通信效率。如果某个虚拟程序在基准测试中所占用的时间太多,会使测试产生重大的误差。
4.2 性能测试工具构架设计
该文中的这个数据库性能测试工具主要由三部分组成:测试数据发生模块、需求分析模块和测试控制模块。
1)测试数据发生模块:根据实际用户的需要设计一个模拟的环境,它可以随机得产生一些测试数据,也可以产生一些伪数据。在设计该模块时,需要考虑的元素有:表的连接、记录的长度和数据、索引和键、数值的分布、数据的相关性、数据库的大小等。
2)需求分析模块:它主要是对用户的业务需求进行分析,从而产生测试事务模型。在设计该模块时,需要考虑的元素有:事务的输入、事务的关联、事务的输出、处理事务的复杂程度、输出的结果数据量的情况等。
3)测试控制模块:该模块是框架中十分重要的部分。在设计该模块时,需要考虑的元素有:用户将达到的数量、测试需要的周期、处理事务时的优先级、工作分布的频率等。
4.3 性能测试流程
性能测试一般分为以下几个步骤:
1)数据模型定制:保证测试模型与基准测试的一致性;
2)事务负载定制:在被测系统中部署一系列的SQL语句,准备在压力测试中使用;
3)组件部署及参数配置:这个环节中,可以在测试系统中配置测试时间、数据库连接字符串等参数,调整缓存等内容,根据性能测试的目的、环境来布置各个组件,最后协调得来完成性能测试;
4)加载初始的数据:为了能够模拟工作中真实的环境,系统在进行压力测试前要载入初始的数据,这个过程是非常消耗时间的;
5)压力测试:这个环节中,调用事务负载,实时监控、记录、评估返回的结束和消耗的时间;
6)结果收集和分析:在压力测试结束之后要对得到的数据进行分析,对照预期结果,判断整个测试是否满足预期的结果。如果和预期不同,可能会重新执行以上几个步骤;
7)完成一份性能测试报告:在完整地完成一次性能测试之后,必须生成一份性能测试报告,报告中应该包括数据库系统实现过程中的情况和测试的结果。
5 总结
较大规模的数据库系统能够稳定、准确、快速的运行,具有决定意义的便是其数据库系统性能状况。保证数据库的良好性能对于核心数据库来说非常关键。数据库性能测试是数据库领域的一个重要内容。
参考文献
[1]胡杰.数据库应用系统的性能分析与优化方法研究[D].南京:河海大学,2002.
[2]朱敏,解群.性能测试工具的研究与设计[J].计算机工程,2005(15).
[3]Christian Antognini.Oracle性能诊断艺术[M].北京:人民邮电出版社,2009.
[4]朱正华.DM3的TPC-C性能测试研究[D].武汉:华中科技大学,2002.
[5]盖国强.Oracle DBA入门、进阶与诊断案例[M].北京:人民邮电出版社,2006.
[6]沈佩娟,汤荷美.数据库管理及应用开发[M].北京:清华大学出版社,1995.