BlogJava-qileilove-随笔分类-性能测试

Jenkins+Ant+Jmeter自动化性能测试平台

顺其自然EVO — Wed, 26 Nov 2014 06:22:00 GMT

　Jmeter是性能测试的工具，java编写、开源，小巧方便，可以图形界面运行也可以在命令行下运行。网上已经有人使用ant来运行，,既然可以使用ant运行，那和hudson、jenkins集成就很方便了，而且jenkins上也有相应的插件Performance Plugin,可以自动收集jmeter的测试结果，展示出来。

　　首先去下载jmeter，在2.8版本中测试通过，2.9版本测试未通过。下载ant-jmeter-1.1.1.jar放在jmeter主目录lib文件夹下。

　　下载需要的ant包，包含配置文件和一些jar包。里面的build.xml是配置文件，可以自定义。需要修改其中jmeter路径，然后直接ant运行即可。

Test Report"/>

classname="org.programmerplanet.ant.taskdefs.jmeter.JMeterTask"

classpathref="ant.jmeter.classpath" />

testplan="${jmxs.dir}/${jmx.filename}.jmx">

out="${resultBase}/temp/${results.html}/${jmx.filename}.html" classpathref="xslt.classpath"

style="${jmeter-home}/extras/jmeter-results-report_21.xsl" >

　　jmxs文件夹存放jmeter脚本，ant会顺序执行其中的脚本，执行结果会放在results文件夹中，包含统计的html文件和jmeter的请求详细jtl文件。

　　最后和jenkins集成，搭建jenkins环境，安装Performance Plugin插件，新建一个job，选择目标机器（机器上要有ant），填好svn或者cvs、定时执行、构建命令等。在Add post-build action中可以添加一个Publish Performance test result report用来收集jmeter测试结果，选择就meter，然后在Report files中填写**/*.jtl即可。

顺其自然EVO 2014-11-26 14:22 发表评论

记一次性能测试实践

顺其自然EVO — Mon, 24 Nov 2014 01:23:00 GMT

　1.测试对象

　　这次测了一些http接口和几个网页。

　　2.测试策略

　　2.1 基准测试：单个调用各接口循环100次计算平均响应时间

　　2.2 性能测试：单个接口调用以50并发用户数为单位，逐步加压直到预估的实际负载300并发用户，观察测试指标变化

　　2.3 压力测试：单个接口调用以50并发用户数为单位，逐步加压直到错误率过高或服务器资源使用率过高，观察测试指标变化

　　2.4 负载测试：预估实际负载为300并发用户数，在此基础上持续测试5分钟左右，观察测试指标是否达标

　　2.5 稳定性测试：预估实际负载为300并发用户数，在此基础上持续测试60分钟左右，观察测试指标是否达标，重点观察错误率

　　2.6 疲劳性测试：预估实际负载为300并发用户数，在此基础上持续测试240分钟左右，观察测试指标是否达标，重点观察错误率

　　2.7 组合测试：对2.2-2.5的测试采用不同接口同时调用（即系统不同模块同时测试）

　　2.8 其他：以不同ip地址加压，测试服务器负载均衡效果。

　　以上，本次只做了2.2、2.3、2.4、2.8

　　3.测试指标

　　测响应时间、错误率；同时专人监控服务器硬件资源使用状况、监控tomcat应用服务器等。

　　计算和监控吞吐量（测试工具自动计算测试执行过程中的吞吐量（每秒钟处理请求数），同时服务器监控软件业监控到了测试执行时服务器的吞吐量）

　　本次实际测试得到吞吐量距离预估有较大差距；错误率超出预期；且测试数据准备有一定问题。

　　4.测试工具

　　本次选用Jmeter，因为便宜且灵活。

　　需设置语言为英文，默认中文翻译不完整。

　　5.测试脚本编写、调试

　　5.1 提前对接口、网页进行录制。每个待测接口、网页需要加断言。断言多采用JQuery断言和Regular Expression断言

　　5.2 重点在测试数据的准备。

　　5.3 采用了本地web应用提供数据，jmeter获取这些数据，再发送给服务器的方法（这次发现这个本地应用生成的数据在较高并发时有重复，导致了不必要的错误率）

　　5.4 测试结果监听器： assertion results, summary report, aggregate report, result tree, result table

　　5.5 测试接口调用时，可用网页、数据库等其他方法确认接口调用成功。观察接口调用是否生效，是否和网页同样效果。

　　6.测试执行

　　6.1 一台电脑加压300-600并发用户。如果需要更多则需要增加电脑。

　　6.2 以不同ip地址加压，测试服务器负载均衡效果。

　　6.3 机房测试，排除internet网络延迟问题

　　6.4 数据备份和还原，排除性能测试对数据的改变

　　6.5 生产环境测试（系统未上线），排除测试环境的影响

　　7.测试报告

　　7.1 截取了jmeter监听器的结果，可以截取服务器监控的截图

　　8.调优

　　本次测试结果不理想，服务器因硬件强大，几乎无负载，但应用本身有java出错。并发现接口调用结果未正确影响网页的bug。

　　后续需要等开发修复、优化之后再次测试

顺其自然EVO 2014-11-24 09:23 发表评论

LoadRunner运行过程中的一个诡异问题

顺其自然EVO — Wed, 19 Nov 2014 01:36:00 GMT

　最近使用loadrunner压测一个项目的时候,发现TPS波动巨大、且平均值较低。使用jmeter压测则没有这个问题。经过多方排查发现一个让人极度费解的原因：

　　原脚本：

//脚本其他代码

......

web_submit_data("aaa",

"Action=http://demo.ddd.com/aaa?a=xr23498isfgljfsfd&b=adfasdfoi4308askdfjkla", //此处为密文链接

"Method=POST",

"RecContentType=text/html",

"Referer=http://demo.ddd.com/ccc?a=xr23498isfgljfsfd&b=adfasdfoi4308askdfjkla",

"Snapshot=t2.inf",

"Mode=HTTP",

ITEMDATA,

LAST);

//事务判断逻辑等代码

.....

　　TPS图如下:

　　修改后的代码:

//脚本其他代码

......

web_submit_data("aaa",

"Action=http://demo.ddd.com/aaa?a=xr23498isfgljfsfd&b=adfasdfoi4308askdfjkla", //此处为密文链接

"Method=GET",

"RecContentType=text/html",

"Referer=http://demo.ddd.com/ccc?a=xr23498isfgljfsfd&b=adfasdfoi4308askdfjkla",

"Snapshot=t2.inf",

"Mode=HTTP",

ITEMDATA,

LAST);

//事务判断逻辑等代码

.....

　　问题得以解决。后来猜测是否loadrunner对于URL中加密的参数/值对兼容性有问题？

顺其自然EVO 2014-11-19 09:36 发表评论

性能测试过程模型

顺其自然EVO — Fri, 14 Nov 2014 01:43:00 GMT

自动化测试生命周期方法，我们称之为"性能测试过程通用模型"，具体如下：

　　1.测试的前期准备阶段

　　a.系统基础功能验证，该活动主要确保当前需要进行性能测试的应用已经具备了进行测试的条件

　　b.组建测试团队

　　c.测试工具需求确认

　　2.测试工具引入阶段

　　a.选择工具

　　b.工具应用的技能培训

　　c.确定工具的应用过程

　　3.测试计划阶段

　　a.性能测试领域分析

　　b.用户活动剖析与业务建模

　　用户活动剖析与业务建模活动用来寻找用户的关键性能关注点。用户对系统性能的关注往往集中在少数几个业务活动上，在确定性能目标之前，需要先把用户的关注点找出来，从而确定最贴近用户要求的性能目标。

　　用户活动剖析的方法大体分为两种：系统日志分析和用户调查分析。系统日志分析是指通过应用系统的日志了解用户的活动，分析出用户最关注、最常用的业务功能的操作路径；用户调查分析是在不具备系统日志分析的条件(如该系统尚未交付用户运行实际的业务)时采用的一种估算方法，可以通过用户调查问卷、同类型系统对比的方法获取用户最关注、最常用的业务功能等内容。

　　c.确定性能目标

　　性能测试目标根据性能测试需求和用户活动分析结果来确定，确定性能测试目标的一般步骤是首先从需求和设计中分析出性能测试需求，结合用户活动剖析与业务建模的结果，最终确定性能测试的目标

　　d.制定测试时间计划

　　e.测试设计与开发阶段

　　1>.测试环境设计

　　对于能力验证领域的性能测试，首先明确是在特定的部署环境上进行，因此不需要特别为性能测试设计环境，只需要保证用于测试的环境与今后系统运行的环境一致即可。

　　对于规划能力领域的性能测试，测试环境不特定，但也需要设计一个基准的环境。

　　对于性能调优领域的性能测试，因为调优过程是一个反复的过程，在每个调优小阶段的末尾，都需要有性能测试来衡量调优的效果，因此必须在开始就给出一个衡量的环境标准，并在整个调优过程中保证每次测试时的环境保持不变。

　　这里所说的测试环境包括：系统的软硬件环境+数据环境设计+环境的维护

　　2>.测试场景设计

　　测试场景模拟的一般是实际业务运行的剖面

　　3>.测试用例设计

　　4.测试执行与管理

　　5.测试分析

顺其自然EVO 2014-11-14 09:43 发表评论

性能测试中如何确定并发用户数

顺其自然EVO — Mon, 10 Nov 2014 02:01:00 GMT

近日，Hitest在其技术博客上发表了一篇题为《并发用户数与TPS之间的关系》的文章，文章对TPS和并发用户数做了详细的解释，并针对性能测试中系统性能的衡量维度和测试策略给出了自己的建议。Hitest是阿里巴巴技术质量部提供的一款Web&移动应用安全测试SaaS化服务平台，旨在帮助开发者简单快捷地进行安全测试。

　　在文中，作者首先对并发用户数和TPS做了解释：

　　并发用户数：是指现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)。并发用户数和注册用户数、在线用户数的概念不同，并发用户数一定会对服务器产生压力的，而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，注册用户数一般指的是数据库中存在的用户数。

　　TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标。

　　作者认为现在很多从业人员在做性能测试时，都错误的认为系统能支撑的并发用户数越多，系统的性能就越好。要理解这个问题，首先需要了解TPS和并发用户数之间的关系：

　　TPS就是每秒事务数，但是事务是基于虚拟用户数的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。

　　也就是说，在评定服务器的性能时，应该结合TPS和并发用户数，以TPS为主，并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。

　　作者最后做了综述，他认为在性能测试时并不需要用上万的用户并发去进行测试，如果只需要保证系统处理业务时间足够快，几百个用户甚至几十个用户就可以达到目的。据他了解，很多专家做过的性能测试项目基本都没有超过5000用户并发。因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000用户并发就足够了；对于中小型系统，1000用户并发就足够了。

　　性能测试需要一套标准化流程及测试策略，在实际测试时我们还需要考虑其它方面的问题，比如如何模拟成千上万来自不同地区用户的访问场景、如何选用合适的测试软件。性能测试对一些小的团队来说并非易事，不过前段时间阿里云发布了性能测试服务PTS，PTS可以帮助开发者通过分布式并发压力测试，模拟指定区域和指定数量的用户同时访问，提前预知网站承载力。这就是云计算给我们带来的便利。

顺其自然EVO 2014-11-10 10:01 发表评论

LoadRunner 12 发布—主推云测试平台

顺其自然EVO — Mon, 03 Nov 2014 01:14:00 GMT

　Loadrunner12推出Community版本，支持50个免费用户

　　LoadRunner仿照6年前就已经出现的SOASTA、Neotys、Blazemeter等竞争对手，推出云性能测试平台，有兴趣的朋友可以看看《Thoughts about LoadRunner 12 Release》这篇文章。

　　新特性

　　1、Cloud-based load generators

　　2、Licensing - 50 vUsers free

　　3、VUGEN improvements

　　The ability to review replay statistics for tests after each run.

　　Including details on total connections, disconnections and bytes downloaded.

　　The ability to edit common file types in the editor.

　　Support for recording in the Internet Explorer 11, Chrome v30 and Firefox v23 browsers.

　　The ability to create scripts from Wireshark or Fiddler files.

　　The ability to record HTML5 or SPDY protocols.

　　4、TruClient improvements

　　TruClient script converter. This basically replays your TruClient scripts and records the HTTP/HTML traffic allowing you to create these script typers from TruClient recordings. This is similar to recording GUI scripts and then converting to other script types.

　　The addition of support for Rendezvous points, IP spoofing, VTS2 and Shunra network virtualisation in TruClient scripts.

　　5、Linux Load Generator improvements

　　Building on the increased support for Linux Load Generators in 11.5x, LDAP, DNS, FTP, IMAP, ODBC, POP3, SMTP and Windows Sockets scripts can now be replayed through UNIX load generators.

　　6、CI/CD support

　　Better integration with Jenkins etc.

　　7、Platform support

　　Support for installation on Windows Server 2012.

　　(LoadRunner 11.x and PC 11.x only supported up to W2K8 which was a barrier to enterprise adoption).

　　LoadRunner components can now run in a "non-admin" user account with UAC and DEP enabled.

顺其自然EVO 2014-11-03 09:14 发表评论

VM性能的快速测试方法

顺其自然EVO — Thu, 30 Oct 2014 02:28:00 GMT

　前段时间陆续发布了一些对公有云服务性能评测的数据。经常有同行问我怎么样去做这些性能评测。其实这些性能评测都很简单，任何一个具备Linux基础知识的工程师都可以完成。我们通常使用UnixBench来评估虚拟机CPU性能，mbw来评估内存性能，iozone来评估文件IO性能，iperf来评估网络性能，pgbench来评估数据库性能。在这里我将我自己做性能测试的过程整理一下，供各位同行参考。

　　（0）安装必要的软件

　　假定VM的操作系统是Ubuntu，可以按照如下步骤安装必要的软件：

sudo apt-get install python-software-properties

sudo add-apt-repository ppa:pitti/postgresql

sudo apt-get update

apt-get install libx11-dev libgl1-mesa-dev libxext-dev perl perl-modules make gcc nfs-common postgresql-9.1 postgresql-contrib-9.1 mbw iperf

cd ~

wget http://www.iozone.org/src/current/iozone3_414.tar

wget http://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz

tar xvf iozone3_414.tar

tar zxvf UnixBench5.1.3.tgz

cd ~/iozone3_414/src/current

make

cd ~/UnixBench

make

　　（1）CPU性能测试

　　我们使用UnixBench来进行CPU性能测试。UnixBench是一套具有悠久历史的性能测试工具，其测试结果反映的是一台主机的综合性能。从理论上来说UnixBench测试结果与被测试主机的CPU、内存、存储、操作系统都有直接的关系。但是根据我们的观察，对于现代的计算机系统来说，UnixBench测试结果受CPU 处理能力的影响更大一些。因此，在这里我们用UnixBench测试结果来代表虚拟机的vCPU 处理能力。每个UnixBench测试结果包括两个数据，一个是单线程测试结果，另一个是多线程测试结果（虚拟机上有几颗虚拟CPU，就有几个并发的测试线程）。

　　cd ~/UnixBench

　　./Run

　　下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3）。我们分别测试了宿主机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在本地磁盘上的虚拟机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在NFS上的虚拟机的CPU性能。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存，运行Ubuntu 12.04 AMD64 Server操作系统。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优。

　　从如上测试结果可以看出，在没有进行任何性能调优的情况下，在单线程CPU性能方面，宿主机 >> 本地磁盘上的虚拟机 >> NFS服务上的虚拟机；在多线程CPU性能方面，宿主机 >> 本地磁盘上的虚拟机＝ NFS服务上的虚拟机。需要注意的是，在多线程测试结果方面，宿主机所占的优势完全是由于宿主机比虚拟机多占用了两个物理线程，也就是一个物理核心。可以认为，在如上所述测试中，物理机和虚拟机的CPU性能基本上是一致的，虚拟化基本上没有导致CPU性能损失。

　　（2）文件IO性能测试

　　我们使用iozone来进行文件IO性能测试。iozone性能测试结果表示的是文件IO的吞吐量（KBps），但是通过吞吐量可以估算出IOPS。在如下命令中，我们评估的是以256K为数据块大小对文件进行写、重写、读、重读、随机读、随机写性能测试，在测试过程当中使用/io.tmp作为临时测试文件，该测试文件的大小是4 GB。需要注意的是，命令中所指定的测试文件是带路径的，因此我们可以测试同一虚拟机上不同文件系统的性能。例如我们通过NFS将某一网络共享文件系统挂载到虚拟机的/mnt目录，那么我们可以将该测试文件的路径设定为/mnt/io.tmp。

　　cd ~/iozone3_414/src/current

　　./iozone -Mcew -i0 -i1 -i2 -s4g -r256k -f /io.tmp

　　下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3）。我们分别测试了宿主机、NFS、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在本地磁盘上的虚拟机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在NFS上的虚拟机、以及从虚拟机内部挂载宿主机NFS服务（虚拟网卡启用了virtio）的磁盘IO性能。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存，运行Ubuntu 12.04 AMD64 Server操作系统。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优。

　　从如上测试结果可以看出，在如上所述特定测试场景中，在文件IO性能方面，宿主机 > NFS > 虚拟机中的NFS > 本地磁盘上的虚拟机 >NFS服务上的虚拟机。值得注意的是，即使是从虚拟机中挂载NFS服务，其文件IO性能也远远超过本地磁盘上的虚拟机。

　　［特别说明］需要注意的是，当我们说文件（或者磁盘）IO性能的时候，我们指的通常是应用程序（例如iozone）进行文件读写操作时所看到的IO性能。这个性能通常是与系统相关的，包括了多级缓存（磁盘自身的缓存机制、操作系统的缓存机制）的影响，而不仅仅是磁盘本身。利用iozone进行文件IO性能测试时，测试结果与主机的内存大小、测试数据块的大小、测试文件的大小都有很大的关系。如果要全面地描述一个特定系统（CPU、内存、硬盘）的文件IO性能，往往需要对测试数据块的大小和测试文件的大小进行调整，进行一系列类似的测试并对测试结果进行全面分析。本文所提供的仅仅是一个快速测试方法，所提供的测试参数并没有针对任何特定系统进行优化，仅仅是为了说明iozone这个工具的使用方法。如上所述之测试数据，仅仅在如上所述之测试场景下是有效的，并不足以定性地说明任何虚拟化场景下宿主机和虚拟机的文件IO性能差异。建议读者在掌握了iozone这个工具的使用方法的基础上，对被测试对象进行更加全面的测试。（感谢saphires网友的修改建议。）

　　（3）内存性能测试

　　我们使用mbw来测试虚拟机的内存性能。mbw通常用来评估用户层应用程序进行内存拷贝操作所能够达到的带宽（MBps）。

　　mbw 128

　　下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3），虚拟机运行Ubuntu 12.04 AMD64 Server操作系统。我们分别测试了宿主机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在本地磁盘上的虚拟机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在NFS上的虚拟机的内存性能。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优。

　　从如上测试结果可以看出，在没有进行任何性能调优的情况下，宿主机、本地磁盘上的虚拟机、NFS服务上的虚拟机在内存性能方面基本上是一致的，虚拟化基本上没有导致内存性能损失。

　（4）网络带宽测试

　　我们使用iperf来测试虚拟机之间的网络带宽（Mbps）。测试方法是在一台虚拟机上运行iperf服务端，另外一台虚拟机上运行iperf客户端。假设运行服务端的虚拟机的IP地址是192.168.1.1，运行客户端的虚拟机的IP地址是192.168.1.2。

　　在服务端执行如下命令：

　　iperf -s

　　在客户端执行如下命令：

　　iperf -c 192.168.1.1

　　测试完成后，在客户端会显示两台虚拟机之间的网络带宽。

　　下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3）。我们分别测试了宿主机之间、宿主机与虚拟机之间、虚拟机与虚拟机之间的内网带宽。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存，运行Ubuntu 12.04 AMD64 Server操作系统。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优，但是虚拟机的网卡启用了virtio。

　　从如上测试结果可以看出，宿主机之间的内网带宽接近内网交换机的极限。在启用了virtio的情况下，宿主机与虚拟机之间内网带宽有小幅度的性能损失，基本上不会影响数据传输能力；虚拟机与虚拟机之间的内网带宽有接近15%的损失，对数据传输能力影响也不是很大。

　　（5）数据库性能测试

　　postgresql是一个著名的开源数据库系统。在MySQL被Sun 公司收购并进一步被Oracle公司收购之后，越来越多的公司正在从MySQL迁移到postgresql。pgbench是一个针对postgresql的性能测试工具，其测试结果接近于TPC-B。pgbench的优点之一在于它能够轻易地进行多线程测试，从而充分利用多核处理器的处理能力。

　　在虚拟机上以postgres用户登录：

　　su -l postgres

　　将/usr/lib/postgresql/9.1/bin加入到路径PATH当中。

　　创建测试数据库：

　　createdb pgbench

　　初始化测试数据库：

　　pgbench -i -s 16 pgbench

　　执行单线程测试：

　　pgbench -t 2000 -c 16 -U postgres pgbench

　　执行多线程测试，在下面的命令中将N替换为虚拟机的vCPU数量：

　　pgbench -t 2000 -c 16 -j N -U postgres pgbench

　　下面是一个可供参考的测试结果。在这个测试中使用了两台物理机，每台物理机各配置一颗Intel Core i3 540 @ 3.07 GHz （双核四线程），16 GB内存（DDR3 @ 1333 MHz），一块Seagate ST2000DL003-9VT1硬盘（SATA，2TB，5900RPM），运行Ubuntu 10.04 AMD64 Server操作系统，使用的文件系统为ext4，使用的Hypervisor为KVM（qemu-kvm-0.12.3），虚拟机运行Ubuntu 12.04 AMD64 Server操作系统。我们分别测试了宿主机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在本地磁盘上的虚拟机、磁盘映像以文件格式（RAW格式，没有启用virtio）存储在NFS上的虚拟机的数据库性能。虚拟机的配置为2 颗vCPU（占用两个物理线程，也就是一个物理核心）和4 GB内存，运行Ubuntu 12.04 AMD64 Server操作系统。在这个测试中没有对操作系统、文件系统、NFS、KVM等等进行任何性能调优。

　　从如上测试结果可以看出，在没有进行任何性能调优的情况下，在数据库性能方面，宿主机 >> 本地磁盘上的虚拟机 >> NFS服务上的虚拟机。

顺其自然EVO 2014-10-30 10:28 发表评论

LoadRunner监控数据库服务器

顺其自然EVO — Tue, 14 Oct 2014 01:30:00 GMT

使用LoadRunner的数据库服务器资源监控器，可以在场景或会话步骤运行期间监控DB2、Oracle、SQL Server或Sybase数据库的资源使用率。在场景或会话步骤运行期间，使用这些监控器可以隔离数据库服务器性能瓶颈。对于每个数据库服务器，在运行场景或会话步骤之前需要配置要监控的度量。要运行DB2,Oracle和Sybase监控器，还必须在要监控的数据库服务器上安装客户端。

　　1>.SQL Server数据库服务器的监控

　　类似windows资源监控

　　2>.Oracle数据库服务器的监控

　　a.确保Oracle客户端已安装在Controller或优化控制台计算机上。

　　b.验证路径环境变量中是否包括%OracleHome%\bin.如果不包括，请将其添加到路径环境中。

　　c.在Controller或优化控制台计算机上配置tnsnames.ora文件。

　　d.向数据库管理员索要该服务器的用户名和密码，并确保Controller或优化控制台对Oracle表具有数据库管理员权限

　　e.通过在Controller或者优化控制台计算机上执行tns ping,验证与Oracle服务器的连接

　　f.要确保注册表已经依照正在使用的Oracle版本进行了更新并且具有以下注册表项 /HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE

　　g.验证要监控的Oracle服务器是否已经启动并正在运行

　　监控项包括：缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数

顺其自然EVO 2014-10-14 09:30 发表评论

Jmeter在命令行运行技巧

顺其自然EVO — Fri, 26 Sep 2014 02:11:00 GMT

　　For non-interactive testing, you may choose to run JMeter without the GUI. To do so, use the following command options

　　-n This specifies JMeter is to run in non-gui mode

　　-t [name of JMX file that contains the Test Plan].

　　-l [name of JTL file to log sample results to].

　　-r Run all remote servers specified in JMeter.properties (or remote servers specified on command line by overriding properties)

　　The script also lets you specify the optional firewall/proxy server information:

　　-H [proxy server hostname or ip address]

　　-P [proxy server port]

　　Example : JMeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000

　　-n 该参数表示Jmeter运行在非图形化模式下（即命令行模式）。

　　-t 保存有测试用例的JMX文件

　　-l 保存样本结果的JTL文件

　　-r 运行所有在JMeter.properties 中定义的远程服务（或者通过命令行覆盖配置文件中定义的远程服务）。脚本还允许您指定可选的防火墙/代理服务器信息：

　　-H 代理服务器主机名或者IP地址

　　-P 代理服务器的端口号

　　上面这段说明来自 JMeter 的官方用户手册。其中提到了使用命令行方式运行 JMeter 脚本的方法。只有几个简单的参数，很直观，用起来也很方便。好处是可以节省一些系统资源。

　　今天尝试 300 个虚拟用户连续运行 5 分钟时——使用 GUI 方式，发现开始运行后不久 UI 就失去了响应，并提示一个有关 AWT 的错误，最终只能把 Java 进程结束掉。但是使用命令行方式时却很稳定。

　　不过当在命令行方式下尝试 500 个虚拟用户连续运行 5 分钟时，JMeter 抛出了一个 Out of Memory 的异常并退出了进程。

　　Note：

　　1.执行命令前要检查当前目录是否是 %JMeter_Home%\bin 目录；

　　2.如果 JMeter 脚本不在当前目录，需要指定完整的路径；如果要把执行的结果保存在其他地方也要指定完整的路径。

顺其自然EVO 2014-09-26 10:11 发表评论

使用SoapUI测试Web Service

顺其自然EVO — Fri, 26 Sep 2014 02:11:00 GMT

　如何测试写好的Webservice？你当然可以写代码来测试，但还是太麻烦，你得花时间去学习各语言的关于Webservice调用的相关API。这里推荐一个Webservice开发的必备工具- SoapUI，无须了解底层细节，就能快速测试你的Webservice开发的是否正确。

　　SoapUI是一个开源测试工具，通过Soap/HTTP来检查、调用、实现Web Service的功能,而且还能对Webservice做性能方面的测试。

　　SoapUI下载地址：http://sourceforge.net/projects/soapui/files/

　　(SoapUI也有收费的Pro版本，对于一般的开发人员来说，如果只是调试下，开源的免费版就足够用了)

　　Demo

　　首先新建一个SoapUI Project，在Initial WSDL/WADL中输入wsdl的地址

　　Project建立好后，SoapUI会根据WSDL的格式生成左边的列表树，包括CUX_0_WS_SERVER_PRG_Binding为WSDL Binding，INVOKEFMSWS为Binding中的Operation。双击Request1就能看到Soap请求报文的内容。

　　在请求报文中填写必要的请求信息，并在左下角的Request Properies中输入用户名，密码及WSS-Pasword Type，再点击绿色的运行按钮，就能在右侧生成Soap响应报文。

　　只是对SoapUI 做了简单的介绍，主要用其来查看web service提供的接口，以及返回的结果，SoapUI的功能远不止这些，其可以对web service进行功能上和性能上的测试。

顺其自然EVO 2014-09-26 10:11 发表评论

性能测试流程剖析

顺其自然EVO — Tue, 23 Sep 2014 01:26:00 GMT

为了让学习者对性能测试的整体思路有一个认识，本篇文章将对性能测试的流程（如下图）中的各个步骤进行讲解。

　　注意：

　　1）上述性能测试流程中未包含“性能测试工具的选择”，各公司情况不同，大多数公司有固定的业务和测试工具，这样就可省去工具选择过程；若公司中有多款测试工具的话，可在使用工具实施测试前的任何阶段灵活进行选择。

　　2）在性能测试流程中会贯穿性能测试文档的编写，可编写在同一模板中，也可各阶段使用不同的模板，依据实际情况而定。

　　3）要求严格的公司，会在性能测试流程的每个阶段中设定评审，视公司及业务实际情况而定。

　　1.首先明确需求，确定性能测试目标，举例如下图。

　　2. 在需求确定的基础上进一步细化，进行业务建模，设计测试用例及场景，举例如图所示。

　　3．在上述步骤基础上，搭建性能测试环境及创建所需的测试数据，如模拟出实际系统运行中的3层体系架构环境，在数据库中创建批量的历史账户和帖子信息等。

　　4．结合上述设计，借助性能测试工具进行测试实施，同时进行资源监控及数据收集。

　　5．针对监控和收集到的大量数据、图表，进行分析。通常，这一步骤由多角色人员配合完成，如：对于数据库性能指标的分析可由DBA协助完成。

　　6．程序员及DBA等其他人员协作共同完成性能问题解决及性能调优，如：开发人员对代码逻辑中影响效率的地方进行代码调整。

　　7．回归测试，将测试结果和前阶段测试结果进行对比分析。

顺其自然EVO 2014-09-23 09:26 发表评论

性能测试URL自动转码

顺其自然EVO — Thu, 18 Sep 2014 01:23:00 GMT

English »

Options : History : Help : Feedback

最近做性能测试，写了个python程序自动将URL里面的‘%2B’，‘20%’，‘3B'等转换成正常字符，方便查看。

import os,sys;

path = sys.path[0]

os.chdir(path)

encode_list = 'encode_list.txt'

result = path + '\\results'

def get_encode():

encode_file = open(path + '\\'+ encode_list)

encode = dict()

for line in encode_file:

if line!='\n' and len(line) >1:

if line.find('read me') <0:

encode[line[1:].strip()] = line[0]

return encode

def get_files():

files = os.listdir(path)

file_list = list()

for file in files:

if file.endswith('.txt') and file!= encode_list:

file_list.append(file)

return file_list

def relace_url_encode(strPri,dicEncode):

items = dicEncode.items()

for (key,value) in items:

if strPri.find(key):

strPri = strPri.replace(key,value)

return strPri

def create_result():

if not os.path.isdir(result):

os.makedirs(result)

def write_result(filePri,strText):

fp = open(result+'\\'+filePri,'w+')

fp.write(strText)

fp.close()

create_result()

encode = get_encode()

file_list = get_files()

for ff in file_list:

try:

f = open(ff)

text = f.read()

finally:

f.close()

temp = relace_url_encode(text,encode)

temp = temp.replace('&','\n')

write_result(ff,temp)

　　下面是文件夹结构：

encode.py的代码贴在上面

　　encode_list.txt里面装的是转换对照表，其中文件名是hard code在python程序里面的，最好不要改

　　前面的是正常字符，后面的是需要转换的字符

　　需要转码的URL形如下面的形式：

selectForm=selectForm&publishId=iphone6SapptR&color=%7B%22colorDisplayText%22%3A%22Grey%22%2C%22colorId%22%3A%22Grey%22%2C%22publishId%22%3A%22iphone6SapptM%22%2C%22modelCode%22%3A%22iphone6SmodelM%22%2C%22available%22%3Atrue%7D&rom=%7B%22capacityDisplayText%22%3A%2216GB%22%2C%22capacityId%22%3A%2216GB%22%2C%22imageFileName%22%3A%22iPhoneX-gold.png%22%2C%22publishId%22%3A%22iphone6SapptM%22%2C%22modelCode%22%3A%22iphone6SmodelM%22%2C%22available%22%3Atrue%7D&locationId=%7B%22locationId%22%3A%22Marina_Bay_Sands_Exhibition_Hall_A%22%2C%22locationDisplayText%22%3A%22Marina%20Bay%20Sands%20Exhibition%20Hall%20A%22%2C%22publishId%22%3A%22iphone6SapptM%22%2C%22available%22%3Atrue%7D&dateId=&timeId=&javax.faces.ViewState=H4sIAAAAAAAAAE1QO0sDQRAeL7n4RGIEK9PZWLhgJ1hoQIOH8YGgCBa6uVuTC3e76z5ydxaBNFrYWGhhIVpY5k%2BIhZ2gpZXYW9u6F0LiBzvMst9jZjs%2FYHMpYKqBmxhp5QdoA8v6Fub28Ofzy8zJewasMowFDHtl7ComHBhVdUFknQVezFdWIcVENGJq3hxLwazLQiQ1RafYJRKtJRSHvltylc%2BoNFnTg6ySEDip%2BFLF7Y%2Fi3Su%2Bz8CQA1npn5OYp8ZRNq2xArtx7HuL2qiPKl19gGkN7VQ

bxFXL12%2BHD3k5H1iGmsosfQYtyJnO5gb9W6YlYCFVx73ZzKScUUIV2ncOfBLtMabmdgXjRKhkkyQSeigYZwGTg%2BR1qsP%2Fj1xBLsBSOV7%2FN7s8hypSI6Lw%2Ffj0275cstL97CYONDF%2B%2BQFvW4dVIi46t8Xxm6%2Br%2FiKcx3%2FTRn8XowEAAA%3D%3D&javax.faces.source=color%3A1&javax.faces.partial.event=change&javax.faces.partial.execute=color%20color%3A1&javax.faces.partial.render=productImage%20rom%20timeId%20dateId%20locationId&javax.faces.behavior.event=change&javax.faces.partial.ajax=true

　　我把转码过的结果全部放在result文件夹里面，双击运行，所有的txt文件都会被转码。并且该文件夹随便放在哪里，代码均可以执行。

　　转码过后：

selectForm=selectForm

publishId=iphone6SapptR

color={"colorDisplayText":"Grey","colorId":"Grey","publishId":"iphone6SapptM","modelCode":"iphone6SmodelM","available":true}

rom={"capacityDisplayText":"16GB","capacityId":"16GB","imageFileName":"iPhoneX-gold.png","publishId":"iphone6SapptM","modelCode":"iphone6SmodelM","available":true}

locationId={"locationId":"Marina_Bay_Sands_Exhibition_Hall_A","locationDisplayText":"Marina_Bay_Sands_Exhibition_Hall_A","publishId":"iphone6SapptM","available":true}

dateId=

timeId=

javax.faces.ViewState=H4sIAAAAAAAAAE1QO0sDQRAeL7n4RGIEK9PZWLhgJ1hoQIOH8YGgCBa6uVuTC3e76z5ydxaBNFrYWGhhIVpY5k+IhZ2gpZXYW9u6F0LiBzvMst9jZjs/YHMpYKqBmxhp5QdoA8v6Fub28Ofzy8zJewasMowFDHtl7ComHBhVdUFknQVezFdWIcVENGJq3hxLwazLQiQ1RafYJRKtJRSHvltylc+oNFnTg6ySEDip+FLF7Y/i3Su+z8CQA1npn5OYp8ZRNq2xArtx7HuL2qiPKl19gGkN7VQ

bxFXL12+HD3k5H1iGmsosfQYtyJnO5gb9W6YlYCFVx73ZzKScUUIV2ncOfBLtMabmdgXjRKhkkyQSeigYZwGTg+R1qsP/j1xBLsBSOV7/N7s8hypSI6Lw/fj0275cstL97CYONDF++QFvW4dVIi46t8Xxm6+r/iKcx3/TRn8XowEAAA==

javax.faces.source=color:1

javax.faces.partial.event=change

javax.faces.partial.execute=color_color:1

javax.faces.partial.render=productImage_rom_timeId_dateId_locationId

javax.faces.behavior.event=change

javax.faces.partial.ajax=true

　　转换后就可以更方便的查找对比，方便测试进行。

　　应该还有需要改进的地方，如果测试需要，再做改进。

顺其自然EVO 2014-09-18 09:23 发表评论

Jmeter性能测试报告解析

顺其自然EVO — Wed, 10 Sep 2014 01:20:00 GMT

　Jmeter报告解析

　　1、Aggregate Report 解析

　　Aggregate Report 是 JMeter 常用的一个 Listener，中文被翻译为“聚合报告”。今天再次有同行问到这个报告中的各项数据表示什么意思，顺便在这里公布一下，以备大家查阅。

　　如果大家都是做Web应用的性能测试，例如只有一个登录的请求，那么在Aggregate Report中，会显示一行数据，共有10个字段，含义分别如下。

　　Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值

　　#Samples：表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100

　　Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间

　　Median：中位数，也就是 50％用户的响应时间

　　90% Line：90％用户的响应时间

　　Note：关于 50％和 90％并发用户数的含义，请参考下文

　　http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html

　　Min：最小响应时间

　　Max：最大响应时间

　　Error%：本次测试中出现错误的请求的数量/请求的总数

　　Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数

　　KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

　　基本知识：

　　1、吞吐量：是指在没有帧丢失的情况下，设备能够接受的最大速率。

　　2、存储的最小单位是字节Byte，对于存储单位，有以下几个单位，GB、MB和KB，那么这三者之间的换算关系是：1GB＝1024MB，1MB＝1024KB，1KB＝1024Bytes。

　　Bit ：“位”，称为bit，也就是比特，有的时候也称为位。一个字节为8位二进制表示。

　　Byte：“字节”，一个字节就是8比特。

　　3、Mbps (million bits per second 兆位/秒) 代表每秒传输1，000，000比特。该缩写用来描述数据传输速度。例如：4Mbps=每秒钟传输4M比特。

　　数据传输速率的单位，字母b（bit）是比特和字母 B （Byte）是字节。

　　4、吞吐量与带宽的区分：吞吐量和带宽是很容易搞混的一个词，两者的单位都是Mbps.先让我们来看两者对应的英语，吞吐量:throughput ; 带宽: Max net bitrate 。当我们讨论通信链路的带宽时，一般是指链路上每秒所能传送的比特数。我们可以说以太网的带宽是10Mbps。但是，我们需要区分链路上的可用带宽（带宽）与实际链路中每秒所能传送的比特数（吞吐量）。我们倾向于用“吞吐量”一次来表示一个系统的测试性能。这样，因为实现受各种低效率因素的影响，所以由一段带宽为10Mbps的链路连接的一对节点可能只达到2Mbps的吞吐量。这样就意味着，一个主机上的应用能够以2Mbps的速度向另外的一个主机发送数据。

　　5、方差和标准差都是用来描述一组数据的波动性的（集中还是分散），标准差的平方就是方差。方差越大，数据的波动越大。

顺其自然EVO 2014-09-10 09:20 发表评论

码农的性能测试

顺其自然EVO — Fri, 22 Aug 2014 01:41:00 GMT

　1.如何理解TPS

　　性能指标的一个重要因素。TPS（Transaction Per Second，每秒事物数），单位时间内完成的事物的数量。TPS的计算一般是通过的事物除以时间。

　　TPS是跟测试脚本中事物（Transaction）相关联的。

　　在性能测试工具中，吞吐量也被称之为TPS（Transaction Per Second，每秒事物数）。吞吐量直接体现系统性能的承载能力，是指单位时间内处理的客户请求的数量。其计量单位可以根据需求不同而不同，比如请求数/秒，页面数/秒，业务数/小时（可以说下我们采集项目中吞吐量可以用解析卡数/秒）。

　　对于交互式应用，用户直接的体验就是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划；但对于非交互式应用，用“吞吐量”来描述用户对系统的性能期望可能更加合理。

　　吞吐量作为性能测试的主要关键指标。吞吐量和并发用户数之前存在着一定的联系。在没有性能瓶颈的时候，吞吐量随着虚拟用户数的增加而增加（计算公式为吞吐量 = （VU个数 * 每个VU发出请求数） / 单位时间）。如果性能遇到瓶颈，吞吐量与VU数理之间就不再符合这个关系。

　　2.如何理解线程调用

　　线程（thread）是”进程”中某个单一顺序的控制流。也被称为轻量进程。

　　线程的好处：

　　1 创建一个新线程花费的时间少。

　　2.（JAVA中线程具有新的，可运行，运行，等待/阻塞/休眠，死亡等几种状态。）在未阻塞情况下，两个线程（在同一进程中的）的切换时间少。在阻塞情况下，线程间切换将产生上下文切换。

　　3.由于同一个进程内的线程共享内存和文件，所以线程之间互相通信不必调用内核。

　　4 线程能独立执行，能充分利用和发挥处理机与外围设备并行工作的能力。

　　使用线程可以把占据长时间的程序中的任务放到后台去处理

　　ps:JAVA中可以通过jstack或者jprofiler dump出线程所执行的堆栈信息。

　　3.如何理解响应时间

　　响应时间反映完成某个业务所需要的时间。

　　在性能测试中是通过测试工具的事物函数来完成响应时间的统计。事物函数会记录开始事物和结束事物的时间差，使用Transaction Response Time这个词来说明。

　　响应时间主要包括网络时间，服务器处理时间，网络延迟

　　对于交互式应用，用户直接的体验就是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划；

　　对于交互式应用，响应时间出现拐点系统就可能出现瓶颈

　　4.如何理解性能建模（可分类回答）

　　这个不会，之前找到一个资料，分享一下吧 http://www.docin.com/p-452373613.html

　　5.如何理解响应时间，TPS曲线和用户之间的关系

　　随着用户数量的增加，在未出现瓶颈前响应时间保持稳定，TPS值和并发用户数成线性关系，出现瓶颈后响应时间变长，TPS基本保持不变或开始下降。

　　6.在LoadRunner中为何要设置思考时间和pacing?

　　1）Think time，思考时间。可以通过设置思考时间，来模拟真实用户在操作过程中的等待时间。从定义上来看，think time是在iteration内部的某个action中各个步骤的间隔时间。

　　2）Pacing，步调。可以通过设置两次迭代（iteration）之间的间隔时间，来调整各个action之间的步调（或者称之为节奏）。

　　3）pacing和think time都是可以模拟现实世界中的停顿。对于复杂场景，这个停顿要靠pacing来完成。不过，pacing怎么设置才最合适，是需要研究用户行为才能定的。

　操作系统

　　1.如何判断CPU、内存、磁盘的瓶颈？

　　CPU瓶颈：

　　1) 查看CPU利用率。建议CPU指标如下

　　a) User Time：65%～70%

　　b) System Time：30%～35%

　　c) Idle：0%～5%

　　如果us,sy高于这个指标可以判断CPU有瓶颈

　　使用top查看

　　查看运行队列

　　每个CPU都会维持一个运行队列，理想情况下，调度器会不断让队列中的进程运行。进程不是处在sleep状态就是run able状态。如果CPU过载，就会出现调度器跟不上系统的要求，导致可运行的进程会填满队列。队列愈大，程序执行时间就愈长。“load”用来表示运行队列，用top 命令我们可以看到CPU一分钟，5分钟和15分钟内的运行队列的大小。这个值越大表明系统负荷越大。超过 1.00，那么说明CPU已经超出负荷，交通严重的拥堵。

　　使用top或者uptime查看

　　查看上下文切换

　　每个CPU（或多核CPU中每个核心）在同一时间只能执行一个线程，Linux采用抢占式调度。即为每个线程分配一定的执行时间，当到达执行时间，线程中有IO阻塞或高优先级线程要执行时，Linux将切换执行的线程，在切换时要存储目前线程的执行状态，并恢复要执行的线程状态，这个过程称之为上下文切换。对于java应用，典型的是在进行文件IO操作，网络IO操作，锁等待或线程sleep时，当前线程会进入阻塞或者休眠状态，从而触发上下文切换，上下文切换过多会造成内核占用过多的CPU使用，使得应用的响应速度下降。

　　使用vmstat查看cs

　　结论：

　　检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.

　　确定CPU 利用率中user/system比例维持在70/30

　　当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级

　　当I/O 处理得到增长,CPU 范畴的应用处理将受到影响

　　ps:对于JAVA应用，CPU瓶颈可以通过jprofiler监控分析

　　内存瓶颈：

　　1.查看利用率(free)

　　used:已使用多大。

　　free:可用有多少。

　　Shared:多个进程共享的内存总额。

　　Buffers/cached:磁盘缓存的大小。

　　2.查看页交换，swap交换（po,pi,so,si），磁盘IO(vmstat)

　　si: 每秒从交换区写到内存的大小

　　so: 每秒写入交换区的内存大小

　　page in :分页(Page)从磁盘重新回到内存的过程被称作Page-In

　　page out : 分页(Page)写入磁盘的过程被称作Page-Out

　　另外在进行页交换的时候，会产生磁盘IO，还需注意bi,bo

　　Bo 磁盘块页面从内存到文件或交换设备的总额

　　Bi 磁盘块页面从文件或交换设备到内存的总额

　　3.page fault（pidstat -r，sar -B )

　　minflt/s: 每秒次缺页错误次数(minor page faults)，次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数

　　majflt/s: 每秒主缺页错误次数(major page faults)，当虚拟内存地址映射成物理内存地址时，相应的page在swap中，这样的page fault为major page fault，一般在内存使用紧张时产生

　　其中sar -B中fault/s表示每秒钟minflt，majflt的和。

　　结论：

　　监控虚拟内存性能由以下几个部分组成：

　　1.当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).

　　2.较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.

　　3.如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.

　　zee：

　　如果用做缓冲区（buff）和快速缓存（Cache）的物理内存不断地增加，而空闲的物理内存（free）不断地减少，证明系统中运行的进程正在不断地消耗物理内存。

　　已经使用的虚拟内存（swpd）不断增加，而且存在着大量的页面交换（si和so），证明物理内存已经不能满足系统需求，系统必须把物理内存的页面交换到磁盘中去。

　　由此可以得到这样的结论：该主机上的物理内存已经不能满足系统运行的需要，内存已成为该系统性能的一个瓶颈。

　　ps:对于java程序，内存瓶颈可以通过heap dump后使用mat分析

　　磁盘瓶颈：

　　iostat查看IO信息。如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。

　　另外还需要注意iowait这个值，iowait 值高就意味着磁盘缓慢或负载过大。还有不要信任svctm这个字段。

　　监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.

　　ps:磁盘瓶颈可以通过pidstat -d 定位程序

　　2.如何理解CPU、内存、磁盘的关系？

　　这些子系统之间关系是彼此联系，相互彼此依赖的

　　1.对于进程来说，数据是存放在内存中的，进程的运行需要使用CPU，进程读写数据需要跟磁盘打交道。

　　2.当内存不足时需要跟磁盘进行页(page)交换，swap交换，从而产生磁盘IO。po,so释放物理内存，pi,si增加物理内存使用。交换分页的过程需要占用cpu时间。 (内存占用过高)

　　3.当磁盘IO负载过高时，需要监控swap和系统分区，要确保virtual memory不是文件系统I/O 的瓶颈。磁盘的相当慢的，当iowait 增长,表示CPU花费大量的时间在等待磁盘IO，此时CPU Bound的应用处理将受到影响（磁盘IO过高）

　　3.如何理解paging in / paging out ?

　　在Linux内存管理中，主要是通过“调页Paging”和“交换Swapping”来完成上述的内存调度。调页算法是将内存中最近不常使用的页面换到磁盘上，把活动页面保留在内存中供进程使用。交换技术是将整个进程，而不是部分页面，全部交换到磁盘上。

　　分页(Page)写入磁盘的过程被称作Page-Out，分页(Page)从磁盘重新回到内存的过程被称作Page-In。当内核需要一个分页时，但发现此分页不在物理内存中(因为已经被Page-Out了)，此时就发生了分页错误（Page Fault）。

　　当系统内核发现可运行内存变少时，就会通过Page-Out来释放一部分物理内存。经管Page-Out不是经常发生，但是如果Page-out频繁不断的发生，直到当内核管理分页的时间超过运行程式的时间时，系统效能会急剧下降。这时的系统已经运行非常慢或进入暂停状态，这种状态亦被称作thrashing(颠簸)。

　　可以通过vmstat -s 查看 paged in/out 数量

　　4.如何监控操作系统的资源？（可用一个操作系统做例子）

　　(把简历上部分内容直接贴出来了，懒的整理了)

　　CPU监控：top(利用率)， uptime(运行队列数)， vmstat(上下文切换数)， jprofile(方法占用cpu时间百分比)

　　内存监控:top， free(利用率)， vmstat(page和swap交换)， pidstat -r和sar -B(page fault)， jmap -heap(堆dump)， mat和jprofiler(查看对象)

　　磁盘监控：iostat(%util)， top(iowait%)， pidstat -d

　　网络监控：netstat(连接数)， nethogs(流量)， wireshark和tcpdump(抓包)

　　JVM监控：jstat(gc)， jmap(堆dump)， jstack(线程dump)， jprofiler和visualvm(剖析工具)

　　nmon(长时间全局收集数据)

　　5.如何理解内存管理和线程调度？（可用一个操作系统做例子）

　　不会

　　6.如何理解上下文切换（context switch）?（可用一个操作系统做例子）

　　vmstat其中cs那一列

　　7.如何理解磁盘IO？（可用一个操作系统做例子）

　　磁盘IO速度是非常慢的，linux内核就是要尽量降低IO

　　内存不足时会进行页交换，产生磁盘IO

　　CPU Bound类型应用，当磁盘IO过多，iowait过大时会影响性能。

　操作系统

　　1.如何判断CPU、内存、磁盘的瓶颈？

　　CPU瓶颈：

　　1) 查看CPU利用率。建议CPU指标如下

　　a) User Time：65%～70%

　　b) System Time：30%～35%

　　c) Idle：0%～5%

　　如果us,sy高于这个指标可以判断CPU有瓶颈

　　使用top查看

　　查看运行队列

　　使用top或者uptime查看

　　查看上下文切换

　　使用vmstat查看cs

　　结论：

　　检查system的运行队列,以及确定不要超出每个处理器3个可运行状态线程的限制.

　　确定CPU 利用率中user/system比例维持在70/30

　　当CPU 开销更多的时间在system mode,那就说明已经超负荷并且应该尝试重新调度优先级

　　当I/O 处理得到增长,CPU 范畴的应用处理将受到影响

　　ps:对于JAVA应用，CPU瓶颈可以通过jprofiler监控分析

　　内存瓶颈：

　　1.查看利用率(free)

　　used:已使用多大。

　　free:可用有多少。

　　Shared:多个进程共享的内存总额。

　　Buffers/cached:磁盘缓存的大小。

　　2.查看页交换，swap交换（po,pi,so,si），磁盘IO(vmstat)

　　si: 每秒从交换区写到内存的大小

　　so: 每秒写入交换区的内存大小

　　page in :分页(Page)从磁盘重新回到内存的过程被称作Page-In

　　page out : 分页(Page)写入磁盘的过程被称作Page-Out

　　另外在进行页交换的时候，会产生磁盘IO，还需注意bi,bo

　　Bo 磁盘块页面从内存到文件或交换设备的总额

　　Bi 磁盘块页面从文件或交换设备到内存的总额

　　3.page fault（pidstat -r，sar -B )

　　minflt/s: 每秒次缺页错误次数(minor page faults)，次缺页错误次数意即虚拟内存地址映射成物理内存地址产生的page fault次数

　　其中sar -B中fault/s表示每秒钟minflt，majflt的和。

　　结论：

　　监控虚拟内存性能由以下几个部分组成：

　　1.当系统中出现较少的页错误,获得最好的响应时间,是因为memory caches(译注:内存高速缓存)比disk caches更快(译注:磁盘高速缓存).

　　2.较少的空闲内存,是件好事情,那意味着缓存的使用更有效率.除非在不断的写入swap device和disk.

　　3.如果系统不断报告,swap device总是繁忙中,那就意味着内存已经不足,需要升级了.

　　zee：

　　由此可以得到这样的结论：该主机上的物理内存已经不能满足系统运行的需要，内存已成为该系统性能的一个瓶颈。

　　ps:对于java程序，内存瓶颈可以通过heap dump后使用mat分析

　　磁盘瓶颈：

　　iostat查看IO信息。如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。

　　另外还需要注意iowait这个值，iowait 值高就意味着磁盘缓慢或负载过大。还有不要信任svctm这个字段。

　　监控swap 和系统分区,要确保virtual memory不是文件系统I/O 的瓶颈.

　　ps:磁盘瓶颈可以通过pidstat -d 定位程序

　　2.如何理解CPU、内存、磁盘的关系？

　　这些子系统之间关系是彼此联系，相互彼此依赖的

　　1.对于进程来说，数据是存放在内存中的，进程的运行需要使用CPU，进程读写数据需要跟磁盘打交道。

　　3.如何理解paging in / paging out ?

　　可以通过vmstat -s 查看 paged in/out 数量

　　4.如何监控操作系统的资源？（可用一个操作系统做例子）

　　(把简历上部分内容直接贴出来了，懒的整理了)

　　CPU监控：top(利用率)， uptime(运行队列数)， vmstat(上下文切换数)， jprofile(方法占用cpu时间百分比)

　　内存监控:top， free(利用率)， vmstat(page和swap交换)， pidstat -r和sar -B(page fault)， jmap -heap(堆dump)， mat和jprofiler(查看对象)

　　磁盘监控：iostat(%util)， top(iowait%)， pidstat -d

　　网络监控：netstat(连接数)， nethogs(流量)， wireshark和tcpdump(抓包)

　　JVM监控：jstat(gc)， jmap(堆dump)， jstack(线程dump)， jprofiler和visualvm(剖析工具)

　　nmon(长时间全局收集数据)

　　5.如何理解内存管理和线程调度？（可用一个操作系统做例子）

　　不会

　　6.如何理解上下文切换（context switch）?（可用一个操作系统做例子）

　　vmstat其中cs那一列

　　7.如何理解磁盘IO？（可用一个操作系统做例子）

　　磁盘IO速度是非常慢的，linux内核就是要尽量降低IO

　　内存不足时会进行页交换，产生磁盘IO

　　CPU Bound类型应用，当磁盘IO过多，iowait过大时会影响性能。

顺其自然EVO 2014-08-22 09:41 发表评论

谈谈性能测试分类

顺其自然EVO — Thu, 14 Aug 2014 01:16:00 GMT

　网上查阅了很多资料，关于性能测试的分类也众说纷芸。谈谈自己对性能测试分类的理解。

　　性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

　　验收性能测试（狭义） 　　性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。

　　特点： 1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。 2、这种方法要事先了解被测试系统经典场景，并具有确定的性能目标。 3、这种方法要求在已经确定的环境下运行。也就是说，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。

　　负载测试(Load Test)通过在被测系统上不断加压，直到性能指标达到极限（例如“响应时间”）超过预定指标或都某种资源已经达到饱和状态。

　　特点： 1、这种性能测试方法的主要目的是找到系统处理能力的极限。 2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。 3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。也就是说，这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“我的要求”或系统崩溃。

　　压力测试（强度测试）(Stress Test)压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误

　　特点： 1、这种性能测试方法的主要目的是检查系统处于压力性能下时应用的表现。 2、这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。 3、这种性能测试方法一般用于测试系统的稳定性。也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。

　　并发测试（Concurrency Testing）并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。

　　特点： 1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。 2、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。 3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。

　　配置测试（Configuration Testing）配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。

　　特点： 1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。 2、这种性能测试方法一般在对系统性能状况有初步了解后进行。 3、这种性能测试方法一般用于性能调优和规划能力。也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。

　　可靠性测试通过给系统加载一定业务压力（例如资源在70%-90%的使用率），使系统运行一段时间，以此检测系统是否稳定运行。

　　特点： 1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。 2、这种性能测试方法需要在压力下持续一段时间的运行。（2~3天） 3、测试过程中需要关注系统的运行状况。如果测试过程中发现，随着时间的推移，响应时间有明显的变化，或是系统资源使用率有明显波动，都可能是系统不稳定的征兆。也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。

　　失效恢复测试如果系统局部发生故障，用户是否能够继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。

　　特点： 1.这种性能测试方法的主要目的是验证在局部故障情况下，系统能否继续使用。 2.这种性能测试方法还需要指出，当问题发生时，“能支持多少用户访问”的结论和“采取何种应急措施”的方案。 3.一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。

　　大数据量测试针对某些系统存储、传输、统计查询等业务进行大数据量的测试。

　　疲劳强度测试主要特点是长时间对目标测试系统加压，目的是测试系统的稳定性，持续时间一般在1小时以上；感觉等同于可靠性测试。

　　注意：在做性能测试时请忘掉分类.例如，运行8个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试，等等。因此，在实施性能测试时决不能割裂它们的内部联系去进行，而应该分析它们之间的关系，以一种高效率的方式来设计性能测试。

顺其自然EVO 2014-08-14 09:16 发表评论

Lr11、QTP11破解时需要注意的问题

顺其自然EVO — Wed, 30 Jul 2014 01:54:00 GMT

　　虽然很早之前就成功装过这两个软件了。但是前阵子重装了系统再装这两个软件时却发现我又把破解的方法给忘了。后来从历史文档中搜索了好久才得到解决。想想这些还是需要总结，事情多了，难免忘记。也分享给需要的童鞋们。

　　LR11的破解方法

　　1)退出程序，把下载文件中的lm70.dll和mlr5lprg.dll覆盖掉..\HP\LoadRunner\bin下的这两个文件

　　2)注意，win7的话一定要以管理员身份运行启动程序，启动后，点击 configuration->loadrunner license，此时可能会有两个许可证信息存在，退出程序，点击deletelicense.exe文件，来删除刚才得许可证信息（即时原来没有lisense最好也运行一下）

　　3）再次打开程序， configuration->loadrunner license->new license，在弹出的输入框中输入license序列号AEABEXFR-YTIEKEKJJMFKEKEKWBRAUNQJU-KBYGB，点击确定，验证通过后，则破解成功！

　　QTP11的破解方法

　　1)安装成功后，手工创建：C:\Program Files\Common Files\Mercury Interactive下，

　　建立文件夹License Manager（这个很重要，必须要创建）

　　2)拷贝破解文件mgn-mqt82.exe至第一步创建的目录下。

　　3)运行破解文件，提示在C:\Program Files\Common Files\Mercury Interactive下创建了lservrc文件

　　4)用记事本打开lservrc，拷贝第一个#号前的一大串字符串。运行QTP，输入这串字符

　　5)安装QTP的功能测试许可服务器安装程序（打开qtp11的安装包里边的）

　　6)删掉SafeNet Sentinel目录（C:\ProgramData\SafeNet Sentinel）

　　7)运行\HP\QuickTest Professional\bin中的instdemo.exe

顺其自然EVO 2014-07-30 09:54 发表评论

性能测试个人经验小结

顺其自然EVO — Wed, 30 Jul 2014 01:38:00 GMT

　性能测试定义：

　　通过一定的工具结合相应的测试方法，对部署的系统应用进行测试，发现系统应用内部存在的代码逻辑问题及应用部署的机器硬件资源瓶颈问题及应用部署架构存在架构错误问题，如：网络端、客户端、服务端搭建的架构问题；

　　负载测试：是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过；

　　压力测试（Stress Testing）：是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试；

　　性能测试的目的：

　　性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题；

　　项目开发周期：初始时刻，项目更多关注的是功能实现，此时功能测试显得尤为重要，测试的提前介入，可以提前预测风险，减少项目开发周期、节约开发成本；功能测试后的阶段，个人认为应该是性能测试（试想，如果一个项目连功能都实现不了，更何谈性能测试）；在功能完毕之后，引入性能测试，通过性能测试对开发项目潜在的问题进行排查（功能测试，仅仅是几个人或者几十个人简单的对应用功能的一个测试，对于应用真正上线后的大量用户使用，应用存在的潜在风险，并不能做很好的预估，尤其是当前空前的竞争压力下，应用上线后的失败，很可能导致整个项目的失败；例如：12306订票网站，使用量之大，可能全世界前所未有，调动全国人力去测试应用性能问题，肯定是不可能的。如果事先不经过性能测试，贸然上线，在如此之多的用户使用情况下，系统崩溃将是怎样的一种后果。）；

　　案例分享：编者曾经从事过一个项目，伴随项目的始终。前期阶段，由于测试提前介入，以及项目开发采用的敏捷开发方式，项目很快在不到半年的时间内，功能近乎完美完成。项目经理本着稳妥起见，引入性能测试，对项目潜在的风险进行评估，然后就搭建了一套模拟环境，专用于性能测试，搭建的模拟环境30用户并发运行，项目一点问题没有，进一步提升并发用户数，各种问题接踵而来；经过系统调优后（发布的应用系统参数等），部分问题解决；为了进一步测试实际情况下存在问题，性能测试环境由模拟环境切到了生产环境上，此时是大量用户下的并发，部分业务是没有问题的，但是更多的问题是集中在涉及到工作流的一些业务场景上，后台日志各种报错；通过抓取后台日志，对问题进行定位分析，很快排查解决了代码开发中存在的一些逻辑问题；代码修复后重新上线，问题已基本不存在了；项目也很快结束，大大的缩短了项目开发周期、节约了开发成功、更好的适用于用户；

　　性能测试注意点：

　　录制脚本尽量模拟实际用户操作，在场景设计时，尽量与实际场景一致，对于用户使用比较多的业务，应着重关注；

　　性能测试尽可能在实际生产环境上进行，普通模拟环境并不能真正发现实际生产环境下，应用存在的问题，但是并非弃用模拟环境；

　　性能测试，对于应用系统部署的环境上，可能需要部署一些系统性能监控软件，在软件的选取上，尽可能降低软件自身运行对系统性能的影响；

　　性能测试，特别是应用与数据库交互的业务操作上，需要提前预制符合性能测试业务需求的数据，在此基础上，尽量让环境测试环境可多次重复使用，这就要求数据、应用可还原；

　　性能测试技能掌握要求：

　　测试环境搭建，环境搭建不仅仅是性能测试所需要具备的技能，也是测试人员所需要具备的基本技能；很多测试，包括应用的安装卸载，都需要测试人员具备这一技能；

　　应用搭建使用协议的了解，很多情况下，性能测试人员需要录制测试脚本，这就要测试人员对应用采用的协议有充分的了解；

　　服务器架构的了解，单一的一台服务器、多台服务器情况下的集群架构等，了解服务器架构，可以为性能测试人员初期性能调优提供帮助；

　　操作系统机能的掌握，特别是Linux操作系统的了解，当前大多数的应用部署在Linux操作系统之上，性能测试人员需要掌握操作系统知识这一基础技能；

　　数据库知识，面对大数据时代，数据库机能的掌握不仅仅可以为性能测试服务，还可以为你今后的华丽转型，提供良好保障，华丽的DBA；

　　良好的编码思量。基础的编码知识，对于编码的了解，可以为你今后冲击高级性能测试工程师提供有力保障，一个高级性能测试工程师，应当具有性能调优这一技能，编码就显得尤为重要；

　　对于新技术、新思想的一种追求与掌握；

顺其自然EVO 2014-07-30 09:38 发表评论

设置Loadrunner负载机临时文件目录

顺其自然EVO — Fri, 25 Jul 2014 03:55:00 GMT

　　最近在跑稳定性测试 3 X 24小时的时候,发现负载机产生的日志还运行记录等等竟然有100多G! C盘空间不足,但是D盘还有700多G空间呢,怎么让临时文件转移到D盘?

　　此处分两种情况:

　　一. 修改本机的临时文件

　　1. 观察压力机产生的临时文件都是在 %USERPROFILE%\Local Settings\Temp 下,于是在“我的电脑”——“属性”——“高级”——“环境变量”里修改了TEMP和TMP变量

　　此处设置它们的值都未 "D:\TEMP"，运行发现结果仍然保存在%USERPROFILE%\Local Settings\Temp下。

　　2. 百度发现, loadrunner执行时用的"NT AUTHORITY\SYSTEM"用户,修改此用户的 TEMP和TMP变量路径要用到WMI相关的知识.

　　在MS-DOS窗口执行

　　wmic ENVIRONMENT where "name='temp'" get UserName,VariableValue

　　wmic ENVIRONMENT where "name='tmp'" get UserName,VariableValue

　　wmic ENVIRONMENT where "name='temp'" get UserName,VariableValue

　　wmic ENVIRONMENT where "name='tmp'" get UserName,VariableValue

　　查看‘NT AUTHORITY\SYSTEM’ TEMP和TMP 环境变量仍然是%USERPROFILE%\Local Settings\Temp ,并没用因为上面的设置而改变,所以没有起到效果

　　为了修改它们,分别执行

　　wmic ENVIRONMENT where "name='temp' and username like '%SYSTEM'" set VariableValue='%temp%'

　　wmic ENVIRONMENT where "name='tmp' and username like '%SYSTEM'" set VariableValue='%temp%'

　　wmic ENVIRONMENT where "name='temp' and username like '%SYSTEM'" set VariableValue='%temp%'

　　wmic ENVIRONMENT where "name='tmp' and username like '%SYSTEM'" set VariableValue='%temp%'

　　将NT AUTHORITY\SYSTEM的环境变量指向系统的Temp变量! 执行成功. 再次运行压测,发现临时文件已经到d:\temp文件夹了..

　　二. 修改其他负载机(协作施压)

　　1 .“我的电脑”——“属性”——“高级”——“环境变量”里修改了TEMP和TMP变量

　　此处设置它们的值都为 "D:\TEMP"，

　　2. 进入loadrunner controller ,菜单 secnario --- load generator --- 设置协作负载机的临时文件路径

　　单击 Details按钮 --->

　　在如图选项卡中中,选择第二个选项....

　　即可...

顺其自然EVO 2014-07-25 11:55 发表评论

网站性能测试工具—ApacheBench

顺其自然EVO — Fri, 18 Jul 2014 02:00:00 GMT

　　对于网站性能测试来说,一般我们会使用loadrunner来实现,而它过于庞大,使我们感到有些不爽,而今天介绍的ApacheBench工具,它小而精,使用简单,效果直观,可以说,是比lr更好用的性能测试工具.

　　下面介绍几个概念

　　1：吞吐率（Requests per second）

　　服务器并发处理能力的量化描述，单位是reqs/s，指的是某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。

　　记住：吞吐率是基于并发用户数的。这句话代表了两个含义，1：吞吐率和并发用户数相关；2：不同的并发用户数下，吞吐率一般是不同的。

　　计算公式：总请求数 / 处理完成这些请求数所花费的时间，即

　　Request per second = Complete requests / Time taken for tests

　　2：并发连接数（The number of concurrent connections）

　　并发连接数指的是某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。

　　3：并发用户数（The number of concurrent users，Concurrency Level）

　　要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。在HTTP/1.1下，IE7支持两个并发连接，IE8支持6个并发连接，FireFox3支持4个并发连接，所以相应的，我们的并发用户数就得除以这个基数。

　　下面主要说一下它的几个主要的参数

　　运行参数

　　请求为100,并发为10,命令如下:ApacheBench -n100 -c10 http://uri

　　运行结果

Benchmarking www.cnblogs.com (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Finished 1000 requests

Server Software:

Server Hostname: www.cnblogs.com

Server Port: 80

Document Path: /

Document Length: 45373 bytes

Concurrency Level: 10

Time taken for tests: 45.299591 seconds

Complete requests: 1000

Failed requests: 0

Write errors: 0

Total transferred: 45679011 bytes

HTML transferred: 45373000 bytes

Requests per second: 22.08 [#/sec] (mean)

Time per request: 452.996 [ms] (mean)

Time per request: 45.300 [ms] (mean, across all concurrent requests)

Transfer rate: 984.73 [Kbytes/sec] received

Connection Times (ms)

min mean[+/-sd] median max

Connect: 26 44 189.5 31 3035

Processing: 89 405 583.3 284 5190

Waiting: 30 143 344.6 97 5031

Total: 116 450 611.7 315 5224

Percentage of the requests served within a certain time (ms)

50% 315

66% 322

75% 331

80% 343

90% 408

95% 549

98% 3333

99% 3375

100% 5224 (longest request)

顺其自然EVO 2014-07-18 10:00 发表评论

成为无可替代，从提升自己的贡献开始！

顺其自然EVO — Tue, 15 Jul 2014 02:25:00 GMT

2007年8月13日，在刚刚开始我工作的第七个年头时，终于顺利的进入了M公司，并得到了一个测试管理方面的职位。虽然之前的六年工作中，我一直在偏技术和偏管理的角色中游移，自信自己在两个方面都有一些积累，足以胜任技术管理工作。可是在M公司的这一个半月，的确又真的让我重新开始思考自己的工作。

　　零零碎碎想到一些东西，先写下来，以后继续慢慢补充，也欢迎大家一起讨论。另外，虽然我的视角是从 Test Team 的角度出发的，但是也应该可以适用于其他想进一步提升自己价值的Team。

　　在大多数情况下，Test Team并不是以软件的直接生产者的身份出现的，而是作为一个附属的功能团队承担开发过程中的一部分职责。这也决定了Test Team 的工作并不不能直接的体现出价值，而是只有当Test Team的工作成果被其他人或Team所使用，为其他人或Team带来价值时，才能真正的体现出Test Team的价值。

　　换句话说，当我们的“产品”能够服务于他人时，我们的工作才有了价值；而当接受或使用我们的“服务”的组织越多时，则我们的Test Team的价值也就越大。

　　举个例子。当一个 Test Team 仅仅认为自己的工作只是“尽早的找到bug，并确认每个bug都得到合理的解决（这是对软件测试工作的经典定义）”时，一个Test Team产生的价值仅仅作用于某个Develop Team甚至某个Developer。这时，Test Team的大多数工作都属于Team内部的工作，与其他Team的接口可能仅仅限于一个bug tracking system，所产生交互的工作也仅仅限于对bug的讨论和状态的跟踪。这种情况下的 Test Team的工作甚至存在的理由都无法被项目之外或部门之外的人或组织所了解。

　　但是当我们留意到我们可以为整个项目中的多个Team，甚至整个部门的多个项目或者企业中的多个部门提供我们的“服务”时，一切都会变得完全不同了。例如

　　为项目团队提供每个版本的bug趋势分析数据，让项目中的每个人都了解项目当前的状态

　　通过分析bug数据来建立或完善各种Checklist，帮助项目团队更好的完成需求评审、设计评审以及代码评审，减少bug出现的机会。同时，可以定期将多个项目的Checklist进行合并，使单个项目的经验可以通过Test Team快速的流动起来，及时的作用于其他项目

　　主动为Architect Team提供每个项目的性能测试数据，帮助他们获取更多的实际项目信息，减少踏入“陷阱”的几率

　　……

　　我们可以做得事情还可以有很多，而关键在于我们是否有积极主动的与其他部门内或部门外的Team进行沟通，去努力了解他们的工作和需求，并开发我们已有的“产品”所能提供的价值。也只有当我们把自己成功的“推销”出去，并与更多的Team在工作上有了越来越深的融合，我们为别人提供的价值也越来越大时，我们自己的价值也才会变得越来越大，并且逐渐成为组织中无可替代的部分！

顺其自然EVO 2014-07-15 10:25 发表评论

如何做好安卓手机的performance测试？

顺其自然EVO — Thu, 10 Jul 2014 11:21:00 GMT

提问：如何做好安卓手机的performance测试？

　　回答：任何测试在测试之前都应该建立相应的计划或方案，手机的performance测试同样也不例外，如何做好performance测试我认为就是制定1个适应公司需求的性能测试计划，而好的测试计划就需要包含下面几个方面：

　　1.Performance范围的确立，手机常用的模块性能必然需要纳入测试范围，如打开联系人界面的时间、点击拨号按钮到显示拨号UI的时间，这些都是重要的performance测试范围，这些模块的性能会影响到最终用户的使用体验；其次手机一些附件的性能需要考虑是否加入性能测试，如WIFI的吞吐率和距离、蓝牙的吞吐率和距离、数据网络的传输速率等等，这些在定制测试时一般是会有要求的，但由于附件性能是偏硬件的，需根据公司的实际情况，确定是否将其纳入测试范围

　　2.Performance目标的确立，我们不可能把被测手机最终的性能结果作为我们的验收结果，这样就失去了性能测试的意义。确定performance的目标是测试重要的1个环节，如果用户提供验收标准，当然是求之不得的，但实际中性能的标准往往是参考某一配置相近的上市机器来确定标准的，这种参考并不等于照搬，由于存在误差，我的经验是在参考机的基础上乘以1.5的系数。

　　3.Performance测试方法的确立，安卓手机模块的性能测试有很多方法，最简单的可以用秒表计时，当然这样的误差会较大。如果需要精确一点的可以通过log确定，从打开1个activity的开始时间到结束时间，adb的log都是可以看到的，但这个时间和用户实际操作的时间仍然是有误差的，这个只是程序逻辑上的时间，不等于用户操作时的时间。最贴近用户体验的方法是用精度高的摄像机拍摄视频，然后通过软件拆分视频帧来计算时间，这样的结果是最可靠的。无论才用什么方法，都需要采用多次测试求平均值的方法来减少误差。关于附件性能的测试，一般都是使用相应的工具进行测试。

　　4.Performance测试实施，测试范围、测试目标、测试方法确定完毕后，就需要明确性能测试什么时候进行，什么时候结束，什么阶段实现什么目标，最主要的是这些都必须时可衡量的。一般性能测试都是在alpha版本的milestone通过之后开始进行，各个阶段都需要执行1个轮次或多个轮次的性能测试

顺其自然EVO 2014-07-10 19:21 发表评论

Django性能测试—一个现实世界的例子

顺其自然EVO — Wed, 02 Jul 2014 08:35:00 GMT

　大约一个星期前，安德鲁和我启动一个新的 Django 打造的网站，站名叫 Hey!Wall 。这是一个按照社交网络中的“墙”的概念建立的社交网站，它为各类朋友提供了一个留言及分享照片、视频和链接的空间。

　　我们想对其进行性能评估，并进行一些服务器配置和代码修改来决定采取何种步骤进行改进。我们使用 httperf 进行了测试，并通过优化将其性能提高了整整一倍。

　　服务器和客户端

　　服务器一是一台 Slicehost 提供的 Xen VPS ，配有 256MB 内存，运行的是 Debian Etch 系统。部署在美国中西部。

　　为了测试，采用了一台位于英国的 Xtraordinary Hosting 提供的 Xen VPS，作为客户端。通常我们使用的 ADSL 访问互联网络，但这让我们很难向服务器发起足够多的访问请求。使用连接良好的 VPS 作为客户端使我们可以真正地对服务器加以考验。

　　服务器规格说明

　　很难确切地描述服务器的规格。该 VPS 配有 256MB 内存，与数个类似的 VPS 同居一台主机（大概是一台装有 16GB 内存的 Quad Core 服务器）之上。假定装满了 256MB 切片的话，物理服务器上最多装有 64 台 VPS 。如果四个处理器都是 2.4GHz，那么共 9.6 GHz ，除以 64 得到最少 150MHz 的 CPU 。

　　在 Xen VPS 上，无需竞争你就可以获得稳定的内存和 CPU 分配，但通常主机上任何空闲的 CPU 都将得到使用。如果在同一机器上的其它 VPS 处于空闲状态，你的 VPS 将能够使用更多的 CPU 。这也许意味着在测试期间使用了更多的 CPU ，即某些测试可能比其它的使用了更多的 CPU 资源。

　　使用 httperf 评估性能

　　现有各式各样的网络性能测试工具，主要包括 ab (来自 Apache), Flood 和 httperf。我们使用 httperf 并没有任何特别理由。

　　httperf 命令看起来如下所示：

　　httperf --hog --server=example.com --uri=/ --timeout=10 --num-conns=200 --rate=5

　　在该例中，我们向 http://example.com/ 发起了 200 次访问请求，每秒最多 5 次。

　　测试计划

　　某些工具支持进程，可以模仿用户对网站提交任务。我们使用了一种简单的“暴力”测试来了解该站点每秒能够处理多少请求。

　　该基本方法是发起一定数量的请求，能够判断服务器如何反应：状态 200 为成功，状态 500 为失败。提高频率（每秒制造的请求数量）然后再试一遍。如果开始返回大量的 500 ，则已经达到极限。

　　监测服务器资源

　　另一个方面是要掌握服务器在内存和 CPU 使用方面的情况。要跟踪这一情况，我们运行 top 并将输出记录为日志文件以供稍后查阅。该 top 命令如下所示：

　　top -b -d 3 -U www-data > top.txt

　　在该例中，我们以用户 www-data 每三秒记录一次进程的日志信息。如果你想更加明确的指定目标，可以使用 -p 1, 2, 3 ，而不是 -U username ，其中 1、2 和 3 是 pid（即要观测进程的进程ID）。

　　网页服务器为配有以 FastCGI processes 方式运行的 Python 2.5 的 Lighttpd 。尽管数据库的日志也是很有用的信息，但我们没有记录该进程（PostgreSQL）的日志。

　　另一个有用的工具是 vmstat，特别是 swap 列显示了有多少内存进行了交换。交换的意思是你没有足够的内存，它是一种性能杀手。要想反复运行 vmstat 的话，必须指定每次检查间隔的秒数。如：

　　vmstat 2

　　使用 httperf 进行已认证访问

　　httperf 只是简单地向某个 URL 发出简单的 GET 请求，并下载 html 文本（但不包括任何媒体文件）。对公共/匿名（public/anonymous）网页发起的访问请求是件轻松的事情，但如果要访问需要登录的页面怎么办呢？

　　httperf 可以传递请求头部信息。Django 身份校验（ authentication）（由 django.contrib.auth 提供）使用的进程依赖于在客户端 cookie 中所保存的进程 id 。而客户端在请求的头部信息中传递 cookie 。你可以看到这一切是如何进行的。

　　登录站点，查看 cookies 信息。其中应该有个类似 sessionid=97d674a05b2614e98411553b28f909de 的数值。要通过 httperf 传递该 cookie，可以使用 --add-header 参数选项。如：

　　httperf ... --add-header='Cookie: sessionid=97d674a05b2614e98411553b28f909den'

　　小心头部信息之后的 n 。如果少了该字符，你的每个请求可能都会返回超时信息。

　测试哪个页面？

　　考虑到这一点，我们测试了网站的两个网页：

　　主页: 对主页的匿名访问

　　“墙”: 对某个“墙”已认证访问，该网页包括从数据库获取的内容

　　事实静态与高度动态

　　对于匿名用户来说，主页基本上是静态的，它只是简单的渲染某个模板而无需数据库的任何数据。

　　“墙”页面则非常动态，包括了从数据库获取的主要数据。该模板在被渲染时，针对不同时区用户的日期设置“删除”了指向某些物件的链接，等等。某些“墙”包含了大约50个物件，在被优化前，大约要发起 80 条数据库查询。

　　第一次测试时，我们运行了两个可以从 Django 接受请求 FastCGI 后端。

　　Home: 175 req/s （即每秒请求数量）Wall: 8 req/s.

　　经压缩的内容

　　第一个配置优化是使用 GZipMiddleware 激活输出的 gzip 压缩。性能轻微提高，没有大的变化。但无论如何为了节约带宽，这么做还是值得的。

　　Home: 200 req/s.

　　Wall: 8 req/s.

　　更多进程，更短的队列

　　然后，我们将 FastCGI 后端的数量从 2 个提升到 5 个。这项改进减少了 500 响应的数量，因为更多的请求可以由额外的后端来处理。

　　Home: 200 req/s.

　　Wall: 11 req/s.

　　更多的进程，更多的问题

　　从 2 到 5 的改进非常不错，因此我们决定将 FastCGI 后端数量提升到 10 。性能却显著地下降了。

　　经查看服务器上的 vmstat ，可以看到原因是出现了内存交换。太多的进程，每个都为 Python 使用了内存，导致 VPS 内存耗尽，从而不得不从硬盘往返交换内存。

　　Home: 150 req/s.

　　Wall: 7 req/s.

　　基于此，我们将 FastCGI 后端数量降回 5 以进行更多测试。

　　分析——时间耗到哪里去了

　　“墙”页面的性能令人失望，因此我们开始进行优化。我们所做第一件事情是分析代码以确定时间都被花费在何处。

　　使用一些简单的分析中间件之后，很清楚地发现时间被消耗在数据库查询之上。“墙”页面包括许多查询，且数量与其所包含的物件数量呈正比。测试墙页面上引发了大约 80 个查询。毫无疑问其性能是糟糕的。

　　进行优化

　　通过优化物件附加媒体的处理方式，我们直接给每个物件剔除了一次查询。该措施稍微地减少了请求所需时间，因此也提高了每秒可处理的查询数量。

　　Wall: 12 req/s.

　　导致低效的另一个原因是无论页面是否被请求，对每个物件的内容都应用了多个过滤器（Filter）。经我们修改，被过滤内容的 HTML 输出都被存储在物件当中，节约了页面被查阅时的需要进程。这又带来一点小小改进。

　　Wall: 13 req/s.

　　通过减少数据库查询，我们以修改用户配置文件（用于显示是谁将该物件粘贴到墙上）的获取方式为每个物件剔除了一次查询。这次修改又提高了不少。

　　Wall: 15 req/s.

　　这场测试的最后一次优化目标是减少获取物件所附加媒体的查询数量。我们再一次削减了一些查询，稍微地提高了性能。

　　Wall: 17 req/s.

　　下一步：缓存

　　在尽可能地减少查询之后，接下来要进行一些缓冲工作。获取缓存数据通常比查询数据库更加快捷，因此我们期待性能有一个显著提升。

　　对整个页面的输出进行缓存是没有意义的，因为每个页面根据发出请求的用户不同而截然不同。只有当用户对同一页面的两次请求之间，情况没有发生任何变化，才可能出现缓存命中。

　　对墙、物件及用户的列表进行缓存的作用更大。被缓存的数据将被用于从同一用户发出的多个请求，及在对于墙壁的不同程度和不同用户访问之间共享。这未必是巨大的胜利，因为每个“墙”很可能只有极少数的用户，而数据必须在高速缓存中停留足够长的时间以被别人获取。

　　在这种情况下，我们简化的 httperf 测试将会被极大地误导。每个请求都由同一用户发出，因此缓存命中几乎是100%，而性能将因此极高！这反映不出真实世界的站点使用情况，因此我们最好进行一些更好的测试。

　　目前我们还没有使用缓存，因为站点可以轻松地应对的当前活动水平，但一旦 Hey! Wall 流行起来，这将是我们的下一个步骤。

　　多少用户能够导致每秒17次请求？

　　提供每秒 17 次请求相应看起来仍然非常少，但将该数据翻译成站点的实际用户量是非常有趣的事情。显然，这数据不包括提供像图片、CSS 和 JavaScript 文件之类的媒体文件服务。相对来说，媒体文件个头要大一些，但它们直接由 Lighttpd （而不是 Django）处理，并提供了 Expires 头部信息来允许客户端对它们进行缓存。不过，为了在测试中更好地进行评估，我们还是需要对服务器进行一些处理。

　　现在说采用何种通用模式还为时过早，因此我说的只能是猜测。请允许我这么说！

　　我将假定每个用户平均访问三个“墙”，并按顺序查看它们的内容，暂停10至20秒时间以阅读新的评论，或查看一些照片和打开一些链接。该用户每天进行三次这种操作。

　　只看墙页面，不看媒体的话，用户将每天对墙页面发起 9 次访问请求。每个用户一次只能发起一次访问请求，因此在时间上，任何一秒内 17 个用户可以同时进行该操作。一分钟内，用户只发出3次访问请求，因此17个并发用户只用去了60 秒中的 3 秒（或20秒中的1秒）。

　　如果一段时间内用户的请求分布是完全平衡的（提示：不可能的！），那也就意味着每分钟可以有 340 用户（17 * 20）访问该网站。延续这个不真实的例子，我们可以说每天有 1440 分钟，而每个用户每天访问网站 3 分钟，因此该网站可以应对大约 163,000 个用户。这对于一个每月 20 美元的 VPS 来说已经非常棒了！

　　为了更多统计一下这些数字，让我们假定每天6小时内，我们每分钟应对 200 个并发用户，另 6 个小时内（每分钟）应对 100 个并发用户，剩下的 12 小时内（每分钟）应对 10 个并发用户。基于每秒 17 次请求的最大负荷，网站每天仍然可以应对的大约 115,000 个用户。

　　我确信这些数字并不虚假和荒谬。如果有人在评论中提出更好的评估方案或者真实世界的数据，我将非常感兴趣。

　　我们学到了什么？

　　概括：

　　测试网站性能可能会产生令人惊异的结果

　　过多的数据库查询对性能（duh）来说不是件好事

　　对站点的某类内容进行缓存比对其他一些更好

　　一台廉价的 VPS 所能应对的用户数量比你所想像的要多得多

顺其自然EVO 2014-07-02 16:35 发表评论

线程上下文切换的性能损耗测试

顺其自然EVO — Fri, 20 Jun 2014 03:30:00 GMT

线程上下文切换的性能损耗到底有多少，一直没有直观的理解，今天写个程序测试一下。先看看下面的程序（点击下载）：

　　ThreadTester是所有Tester的基类。所有的Tester都干的是同样一件事情，把counter增加到100000000，每次只能加1。

1: public abstract class ThreadTester

2: {

3: public const long MAX_COUNTER_NUMBER = 100000000;

5: private long _counter = 0;

7: //获得计数

8: public virtual long GetCounter()

9: {

10: return this._counter;

11: }

12:

13: //增加计数器

14: protected virtual void IncreaseCounter()

15: {

16: this._counter += 1;

17: }

18:

19: //启动测试

20: public abstract void Start();

21:

22: //获得Counter从开始增加到现在的数字所耗的时间

23: public abstract long GetElapsedMillisecondsOfIncreaseCounter();

24:

25: //测试是否正在运行

26: public abstract bool IsTesterRunning();

27: }

SingleThreadTester是单线程计数。

1: class SingleThreadTester : ThreadTester

2: {

3: private Stopwatch _aStopWatch = new Stopwatch();

5: public override void Start()

6: {

7: _aStopWatch.Start();

9: Thread aThread = new Thread(() => WorkInThread());

10: aThread.Start();

11: }

12:

13: public override long GetElapsedMillisecondsOfIncreaseCounter()

14: {

15: return this._aStopWatch.ElapsedMilliseconds;

16: }

17:

18: public override bool IsTesterRunning()

19: {

20: return _aStopWatch.IsRunning;

21: }

22:

23: private void WorkInThread()

24: {

25: while (true)

26: {

27: if (this.GetCounter() > ThreadTester.MAX_COUNTER_NUMBER)

28: {

29: _aStopWatch.Stop();

30: break;

31: }

32:

33: this.IncreaseCounter();

34: }

35: }

36: }

　　TwoThreadSwitchTester是两个线程交替计数。

1: class TwoThreadSwitchTester : ThreadTester

2: {

3: private Stopwatch _aStopWatch = new Stopwatch();

4: private AutoResetEvent _autoResetEvent = new AutoResetEvent(false);

6: public override void Start()

7: {

8: _aStopWatch.Start();

10: Thread aThread1 = new Thread(() => Work1InThread());

11: aThread1.Start();

12:

13: Thread aThread2 = new Thread(() => Work2InThread());

14: aThread2.Start();

15: }

16:

17: public override long GetElapsedMillisecondsOfIncreaseCounter()

18: {

19: return this._aStopWatch.ElapsedMilliseconds;

20: }

21:

22: public override bool IsTesterRunning()

23: {

24: return _aStopWatch.IsRunning;

25: }

26:

27: private void Work1InThread()

28: {

29: while (true)

30: {

31: _autoResetEvent.WaitOne();

32:

33: this.IncreaseCounter();

34:

35: if (this.GetCounter() > ThreadTester.MAX_COUNTER_NUMBER)

36: {

37: _aStopWatch.Stop();

38: break;

39: }

40:

41: _autoResetEvent.Set();

42: }

43: }

44:

45: private void Work2InThread()

46: {

47: while (true)

48: {

49: _autoResetEvent.Set();

50: _autoResetEvent.WaitOne();

51: this.IncreaseCounter();

52:

53: if (this.GetCounter() > ThreadTester.MAX_COUNTER_NUMBER)

54: {

55: _aStopWatch.Stop();

56: break;

57: }

58: }

59: }

60: }

　MultiThreadTester可以指定线程数，多个线程争抢计数。

1: class MultiThreadTester : ThreadTester

2: {

3: private Stopwatch _aStopWatch = new Stopwatch();

4: private readonly int _threadCount = 0;

5: private readonly object _counterLock = new object();

7: public MultiThreadTester(int threadCount)

8: {

9: this._threadCount = threadCount;

10: }

11:

12: public override void Start()

13: {

14: _aStopWatch.Start();

15:

16: for (int i = 0; i < _threadCount; i++)

17: {

18: Thread aThread = new Thread(() => WorkInThread());

19: aThread.Start();

20: }

21: }

22:

23: public override long GetElapsedMillisecondsOfIncreaseCounter()

24: {

25: return this._aStopWatch.ElapsedMilliseconds;

26: }

27:

28: public override bool IsTesterRunning()

29: {

30: return _aStopWatch.IsRunning;

31: }

32:

33: private void WorkInThread()

34: {

35: while (true)

36: {

37: lock (_counterLock)

38: {

39: if (this.GetCounter() > ThreadTester.MAX_COUNTER_NUMBER)

40: {

41: _aStopWatch.Stop();

42: break;

43: }

44:

45: this.IncreaseCounter();

46: }

47: }

48: }

49: }

　　Program的Main函数中，根据用户的选择来决定执行哪个测试类。

1: class Program

2: {

3: static void Main(string[] args)

4: {

6: string inputText = GetUserChoice();

8: while (!"4".Equals(inputText))

9: {

10: ThreadTester tester = GreateThreadTesterByInputText(inputText);

11: tester.Start();

12:

13: while (true)

14: {

15: Console.WriteLine(GetStatusOfThreadTester(tester));

16: if (!tester.IsTesterRunning())

17: {

18: break;

19: }

20: Thread.Sleep(100);

21: }

22:

23: inputText = GetUserChoice();

24: }

25:

26: Console.Write("Click enter to exit...");

27: }

28:

29: private static string GetStatusOfThreadTester(ThreadTester tester)

30: {

31: return string.Format("[耗时{0}ms] counter = {1}, {2}",

32: tester.GetElapsedMillisecondsOfIncreaseCounter(), tester.GetCounter(),

33: tester.IsTesterRunning() ? "running" : "stopped");

34: }

35:

36: private static ThreadTester GreateThreadTesterByInputText(string inputText)

37: {

38: switch (inputText)

39: {

40: case "1":

41: return new SingleThreadTester();

42: case "2":

43: return new TwoThreadSwitchTester();

44: default:

45: return new MultiThreadTester(100);

46: }

47: }

48:

49: private static string GetUserChoice()

50: {

51: Console.WriteLine(@"==Please select the option in the following list:==

52: 1. SingleThreadTester

53: 2. TwoThreadSwitchTester

54: 3. MultiThreadTester

55: 4. Exit");

56:

57: string inputText = Console.ReadLine();

58:

59: return inputText;

60: }

61: }

三个测试类，运行结果如下：

Single Thread:

[耗时407ms] counter = 100000001, stopped

[耗时453ms] counter = 100000001, stopped

[耗时412ms] counter = 100000001, stopped

Two Thread Switch:

[耗时161503ms] counter = 100000001, stopped

[耗时164508ms] counter = 100000001, stopped

[耗时164201ms] counter = 100000001, stopped

Multi Threads - 100 Threads:

[耗时3659ms] counter = 100000001, stopped

[耗时3950ms] counter = 100000001, stopped

[耗时3720ms] counter = 100000001, stopped

Multi Threads - 2 Threads:

[耗时3078ms] counter = 100000001, stopped

[耗时3160ms] counter = 100000001, stopped

[耗时3106ms] counter = 100000001, stopped

　　什么是线程上下文切换

　　上下文切换的精确定义可以参考: http://www.linfo.org/context_switch.html。多任务系统往往需要同时执行多道作业。作业数往往大于机器的CPU数，然而一颗CPU同时只能执行一项任务，为了让用户感觉这些任务正在同时进行，操作系统的设计者巧妙地利用了时间片轮转的方式，CPU给每个任务都服务一定的时间，然后把当前任务的状态保存下来，在加载下一任务的状态后，继续服务下一任务。任务的状态保存及再加载，这段过程就叫做上下文切换。时间片轮转的方式使多个任务在同一颗CPU上执行变成了可能，但同时也带来了保存现场和加载现场的直接消耗。(Note. 更精确地说, 上下文切换会带来直接和间接两种因素影响程序性能的消耗. 直接消耗包括: CPU寄存器需要保存和加载, 系统调度器的代码需要执行, TLB实例需要重新加载, CPU 的pipeline需要刷掉; 间接消耗指的是多核的cache之间得共享数据, 间接消耗对于程序的影响要看线程工作区操作数据的大小).

　　根据上面上下文切换的定义，我们做出下面的假设：

　　之所以TwoThreadSwitchTester执行速度最慢，因为线程上下文切换的次数最多，时间主要消耗在上下文切换了，两个线程交替计数，每计数一次就要做一次线程切换。

　　“Multi Threads - 100 Threads”比“Multi Threads - 2 Threads”开的线程数量要多，导致线程切换次数也比后者多，执行时间也比后者长。

　　由于Windows下没有像Linux下的vmstat这样的工具，这里我们使用Process Explorer看看程序执行的时候线程上线文切换的次数。

　　Single Thread:

　　计数期间，线程总共切换了580-548=32次。（548是启动程序后，初始的数值）

　　Two Thread Switch:

　　计数期间，线程总共切换了33673295-124=33673171次。（124是启动程序后，初始的数值）

　　Multi Threads - 100 Threads:

　　计数期间，线程总共切换了846-329=517次。（329是启动程序后，初始的数值）

　　Multi Threads - 2 Threads:

　　计数期间，线程总共切换了295-201=94次。（201是启动程序后，初始的数值）

　　从上面收集的数据来看，和我们的判断基本相符。

　　干活的其实是CPU，而不是线程

　　再想想原来学过的知识，之前一直以为线程多干活就快，简直是把学过的计算机原理都还给老师了。真正干活的不是线程，而是CPU。线程越多，干活不一定越快。

　　那么高并发的情况下什么时候适合单线程，什么时候适合多线程呢？

　　适合单线程的场景：单个线程的工作逻辑简单，而且速度非常快，比如从内存中读取某个值，或者从Hash表根据key获得某个value。Redis和Node.js这类程序都是单线程，适合单个线程简单快速的场景。

　　适合多线程的场景：单个线程的工作逻辑复杂，等待时间较长或者需要消耗大量系统运算资源，比如需要从多个远程服务获得数据并计算，或者图像处理。

　　例子程序：http://pan.baidu.com/s/1ntNUPWP

顺其自然EVO 2014-06-20 11:30 发表评论

性能测试—性能环境与数据

顺其自然EVO — Sun, 04 May 2014 04:56:00 GMT

性能环境，也是困扰性能测试人员很重要的一个问题。如何模拟线上真实的环境？如何在测试环境进行的性能测试结果，能准确的反应到生产线上去？

　　先聊下我们的做法。

　　首先确认线上的网络拓扑图。比如：

　　左边是线上环境，线上一般是分布式集群部署。比如用户访问服务器A，而服务器A需要依赖到服务器B和C提供的服务，而服务器C与DB存储打交道。那么在性能测试环境，为了模拟用户的行为，需要搭建服务器A,B,C和DB各一台。通过对单台服务器A的压测结果TPS，再线性乘以机器数量，完成线上服务器A集群的TPS的评估。

　　这样做，简单的完成了线上和线下的结果推算。但是这样做，有一个前提：就是保证线上和性能测试环境的机器配置是一样的。机器的配置分为2个部分：硬件和软件。

　　硬件方面，比如机器是4核4G的xen虚拟机，千兆网卡，SATA磁盘。

　　软件方面，包括操作系统的版本，位数，比如：redhat 5.4，**位机器；JDK版本：openJDK 1.6.0；JVM参数配置；web容器：tomcat7.

　　上面说的是应用层面，性能测试还有很重要的一步，就是性能测试数据的准备。

　　性能测试数据库的环境也与应用层一样，保持和线上一样的硬件与软件配置。这里有个问题就是：生产线上一台数据库，对应多台应用。而在性能测试环境中，被我们映射成1：1的关系后，很难找到数据库层的性能瓶颈，因为在压测过程中，应用层会比数据层更快到达性能瓶颈。

　　接下来，简单描述下性能测试数据的准备。性能测试数据的准备也分为2个部分。1是业务数据，2是基础数据。

　　什么是业务数据？业务数据就是性能测试要模拟的用户拥有的数据。比如卖家A，有100个商品。100就是业务数据。基础数据就是商品所在表的总数据量。比如100W。

　　性能测试的数据，不光要关注业务，更要关注数据库表的量级，因为100条数据，和100W条数据，性能测试出来完全是两个结果。

　　为了数据的准确性，性能测试的数据表，也要满足生产线上表的量级。

　　满足了这些条件，性能环境才能基本真实模拟生产线的环境，测试出来的结果才有推算上线后结果的可能。

　　后记：

　　每个公司的业务不同，系统架构也不同，所以性能测试环境方面肯定有很大的差异。我只是简单的写了我所在公司的性能环境的一些知识，分享给大家，供大家一个参考，希望你能从这里获得有用的东西。关于性能测试环境，我的一些观点：

　　1. 如果允许生产线做性能测试，就尽量做生产线性能测试。同样的环境，性能测试的结果才有意义，性能测试的价值也最大体现。

　　2. 测试环境的配置可以与线上一样，可以做下N：1的映射。结果线性乘以机器数，可以评估线上集群的负载。

　　3. 真没条件，线上线下环境差异很大。就尽量找一些代码级别的性能瓶颈。优化后再上线，线下的结果就不用去推算线上，很不科学

顺其自然EVO 2014-05-04 12:56 发表评论

PAAS平台的web应用性能测试与分析

顺其自然EVO — Tue, 29 Apr 2014 02:46:00 GMT

引言

　　为什么我会写这一篇博客，因为最近很多京东云擎jae的用户反应一个问题就是他们部署在jae上面的应用访问很慢，有极少数应用甚至经常出现504超时现象，当然大家首先想到的是jae性能太差，这也是人之常情，往往出现什么错误的时候首先想到是别人的不好，工作中很多同事也是这样，如果软件系统出现一个bug首先怀疑的肯定不是自己写的代码。今天花时间写这一篇博客主要就是告诉大家怎样确定我们部署在PAAS平台（不仅仅是JAE哦）web应用为什么慢？慢在哪儿了？有什么方法可以解决？

　　原因分析

　　出现访问自己web应用慢从宏观上可以总结为下面三点：

　　（1）网络慢：具体来说就是访问者同部署web应用的PAAS平台之间的网络慢;

　　（2）PAAS平台性能出现问题：具体来说就是由于各种原因导致PAAS平台不能很好服务部署在它上面的应用;

　　（3）web应用本身慢：由于各种原因（频繁读写磁盘，大量耗时的计算，资源竞争等）导致web应用不能很快的响应访问者的请求。

　　上面三点主要总结于web应用的访问路径，因为访问PAAS平台的web应用首先需要经过网络，然后经过PAAS平台的过滤和转发等处理，最后才到达web应用本身处理。这三个环节任何一个出现问题都会导致web应用访问变慢。知道原因了，我们还需要判断到底是哪一个环节出现了问题，下面就说说怎样定位具体的环节。

　　定位具体原因

　　上面分析的三个原因除了第二个原因以外，大家都可以自己定位和排除，首先检查网络，为了更加准确我们可以从一下方面进行排除：

　　（1）首先检查访问其他网站是否出现很慢的现象，如果很快，那么说明你的网络肯定大体上是正常的;

　　（2）访问对应PAAS平台提供的相关网站和PAAS平台所属公司的网站，例如JAE，你可以访问京东商城主站和京东云平台首页等，BAE可以访问百度相关网站，SAE可以访问新浪相关网站，因为这些关联网站一般部署在同一个机房或者同一个城市，如果这些网站也很慢，那多半说明这些网站相关机房网络出现问题或者访问量很大，导致这些网站对外出口流量和访问速度变慢，也就是对外提供服务的能力扛不住了，如果没有问题，那么可以排除大的网络环境是没有问题的;

　　排除了网络因素，我们就可以排除后面两个原因了，由于PAAS平台的性能对用户基本上是透明的，就是用户基本上无从得知，所以可以直接跳过这个原因的排除，当然其实是有手段的，只是稍微复杂，所以不方便所有用户，如果是这种原因最好还是交给PAAS平台的开发人员去处理。

　　最后一个原因当然就是web应用自身的实现了，我发现很多用户反馈的网站访问慢的原因都是由于自己代码实现的问题。

　　首先出现问题的网站大多数是有一定访问量的，特别是某一个时间段出现访问量巨大，而且频繁读写磁盘。为了定位这种原因希望大家把应用部署在自己本地使用web性能测试工具做验证即可，例如比较常用的web性能测试工具ab，这个事apache自带的测试工具，ubuntu下安装和使用都非常方便，例如我们直接在控制台中输入ab，如果没有安装，ubuntu系统会如下提示：

　　The program 'ab' is currently not installed. You can install it by typing:

　　sudo apt-get install apache2-utils

　　然后安装提示安装即可，安装成功以后我们就可以使用ab软件对我们部署在本地的web应用进行性能测试评估了，命令如下：

　　ab -n1000 -c10 http://localhost/

　　上面命令的意思是总共发送1000次请求，每次10各并发请求，访问的路径就是本地web服务器的根路径，结果如下：

This is ApacheBench, Version 2.3 <$Revision: 1430300 $>

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Completed 1000 requests

Finished 1000 requests

Server Software: Apache/2.4.6

Server Hostname: localhost

Server Port: 80

Document Path: /

Document Length: 177 bytes

Concurrency Level: 10

Time taken for tests: 0.075 seconds

Complete requests: 1000

Failed requests: 0

Write errors: 0

Total transferred: 446000 bytes

HTML transferred: 177000 bytes

Requests per second: 13283.74 [#/sec] (mean)

Time per request: 0.753 [ms] (mean)

Time per request: 0.075 [ms] (mean, across all concurrent requests)

Transfer rate: 5785.69 [Kbytes/sec] received

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 0 0.1 0 1

Processing: 0 1 0.2 0 2

Waiting: 0 0 0.2 0 2

Total: 0 1 0.1 1 2

ERROR: The median and mean for the processing time are more than twice the standard

deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)

50% 1

66% 1

75% 1

80% 1

90% 1

95% 1

98% 1

99% 1

100% 2 (longest request)

上面具体每一项代码什么意义可以网上查找，这里我们主要关心一下如下这个选项：

　　Requests per second，从结果看这个值是13283.74 [#/sec] (mean)，表示每一秒钟可以处理13283.74各请求，因为我这个很简单的一个静态页面（就是apache服务器安装后默认的首页），所以看起很不错，而且是通过本地localhost，没有经过网络。我们可以改变访问的条件持续做很多组测试，例如我把并发请求数改为100,即-c100,得到参数值为：

　　Requests per second: 11843.29 [#/sec] (mean)

　　明显比上面减少了一些，继续改总请求数为10000,并发数1000,即-n10000 -c1000得到如下值：

　　Requests per second: 747.98 [#/sec] (mean)

　　这个时候减少的相当的可怕了，所以通过这个ab测试工具就能够知道我们的web应用能够承担多少的并发访问，当然我们可以通过不断的挑战参数进行测试，然后绘制成一个曲线图观察就很方便看出我们web应用的最佳性能点，超过那么最佳性能点可能就导致性能下降，那么访问速度也就跟着下降了。

　　当然只看上面一个参数看不出具体一个用户访问所需要等待的时间，另一个参数可以看出，我对应三次的测试这个参数值分别如下：

　　Time per request: 0.753 [ms] (mean)

　　Time per request: 8.444 [ms] (mean)

　　Time per request: 1336.942 [ms] (mean)

　　从三次测试可以看出，随着并发数的增长，一个用户平均等待的时间也在变长，这个最终就反应到用户web访问的结果（速度的快慢），这里测试的只是一个简单的静态网页，如果是复杂的动态网页（例如访问数据库，读写磁盘和大量的计算等）那么就更加复杂了，一个请求的快慢由于web应用需要处理的业务逻辑有很大的关系，当然怎样让这些业务逻辑执行更快并且并行执行，这个就需要程序实现者考虑了。

　　总结

　　这里只是简单介绍了部署在PAAS平台web应用访问很慢的可能原因和简单定位方法，起始我觉得大家应该中的关注在第三点上，自身应用的优化，因为前面两点都是我们不可控的，网络这个PAAS平台自身也解决不了，最多可以部署多个机房多个宽带运营商和cdn处理等，但是用户自身的网络问题PAAS平台也是解决不了的。至于PAAS平台自身的原因，大家就更不用担心了，他们比你们更关系自身PAAS平台的性能，因为上面托管着成千上万的web应用，他们时时刻刻都在关系着自身平台的性能拼劲，想着各种方法优化。如果PAAS平台的原因导致用户部署的web应用访问很慢甚至不可用那么这个PAAS平台自身也做不下去的。

　　最后还想强调一点就是web应用自身的性能优化问题，现在各种语言都提供了很好的开发框架，理论上都是稳定的并且性能是不错的，当然特殊场景需要特殊考虑。但是我们自身在设计web应用的时候可能需要考虑的更多，不要妄想一个简单的开发框架就能解决所有的问题，尤其是性能问题。设计到web应用优化的知识和技术非常的多也非常的复杂，还有很多场景，所以这是各长久的过程。后面有机会也会给大家介绍一些web性能优化的方法和技术，并且结合实际场景进行分析和演练。

顺其自然EVO 2014-04-29 10:46 发表评论

性能分析软件之yourkit入门介绍

顺其自然EVO — Mon, 28 Apr 2014 02:30:00 GMT

　安装、运行，

　　1 下载windows版本的yourkit，安装并破解。

　　2 在本机tomcat安装yourkit插件

　　2.1 打开tomcat的环境参数配置文件catalina.bat。

　　2.2 增加java系统参数：

　　set JAVA_OPTS=%JAVA_OPTS% -agentpath:D:/java/share/yjpagent.dll

　　yjpagent.dll从your kit的安装目录能找到，如D:\Program Files (x86)\YourKit Java Profiler 9.0.3\bin\win32下。

　　请注意，不能将系统参数设置为-agentpath: D:/Program Files (x86)/YourKit Java Profiler 9.0.3/bin/win32/ yjpagent.dll,否则tomcat将无法启动，因为路径中含有空格。因此将yjpagent.dll复制到无空格的目录，如D:/java/share/yjpagent.dll。（本人当初因踩了“路径有空格”这坑，而折腾了很久）。

　　2.3如果是监控远程linux上的tomcat，唯一的区别是下载linux版yourkit获取linux版的yjpagent库文件。

　　3 启动tomcat

　　4 运行your kit

　　5 在”show all running JVMS” 复选框打勾，能看到本机运行的java进程。

　　6 在列表中双击tomcat对应的进程，即可以看到your kit的监控界面。

　　监控

　　1 看各函数cpu资源消耗比例

　　1.1点Cpu标签页

　　1.2在cpu time图标框，用鼠标水平划一时间区域

　　1.3在底下的分析栏：CPU Usage Estimation，将显示该时间段各个函数cpu资源利用比例。选择函数点击能显示子函数的占用比。

　2 分析内存

　　2.1 选择Memory 标签页

　　2.2 在底下分析栏：CPU List，能看到jvm中各类的内存占用情况，如要查询具体类可在输入类名进行模糊查看那。

顺其自然EVO 2014-04-28 10:30 发表评论

LoadRunner使用入门进行Webservice负载测试

顺其自然EVO — Fri, 25 Apr 2014 02:08:00 GMT

　1.什么是LoadRunner

　　LoadRunner是HP公司的一款付费工具，该工具是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载来确认和查找问题。

　　2.什么是负载测试

　　通过测试系统在资源超负荷的情况下的表现，以发现设计上面的错误或验证系统的负载能力。

　　负载测试的目标是确定并保证系统在超出最大预期工作量的情况下仍能正常运行，还能评估系统的性能特征。

　　下面介绍一下关于负载测试的几个基本概念：

　　2.1吞吐率：服务器并发处理能力的量化描述（单位reqs/s）,单位时间内处理的请求数。

　　2.2并发连接数：某一个时间点允许最大的请求数量，这个常用来衡量系统的并发处理请求的能力，应该区分与下面的并发用户数。

　　2.3并发用户数：一个用户可能会产生多个并发连接，例如IE8目前支持6个并发连接。

　　2.4用户请求平均时间：大量用户请求从发起到接收到处理结果的一个平均时间，在web页面默认不超过3秒是最佳的用户体念。

　　2.5服务器平均处理请求时间：处理完成一个请求所用的平均时间，这个指标可用来衡量业务逻辑复杂度和机器的性能指标。

　　3.使用LoadRunner进行负载测试详解

　　3.1负载测试目标

　　在做任何事情的时候，都应该三思而后行，明确要达到的目标。然后计划一步一步的达到所定的目标。同样在测试初期我们应该明确定义需要达到的测试目标，例如：我们现在要测试一个调用人力资源数据的WebService接口，我们的重点测试规定时间长度的接口并发处理能力，且接口的单次调用时间不超过3秒，在最大并发用户80最小并发用户20平均并发用户40的情况下进行30分钟的接口调，预计总调用次数10000次，用户平均请求时间不超过5秒。

　　怎样定义以上测试目标的呢？第一、写一个脚本顺序多次调用接口获得一个平均单次调用时间，且这个时间作为基础时间。第二、最大并发用户、最小并发用户和平均并发用户来自对原有系统的分析，发现人力资源接口在公司中被大量其他系统所访问经过分析和调查得出最大并发用户80最小并发用户20平均并发用户40的结果。第三、调用次数10000次如何得来，根据设置的3个请求源，分别设置这3个请求开始时间和结束事件计算得来的，如A请求源从0~20分钟并发用户访问数为20，B请求源并发数为30从10分钟~25分钟，C请求源从15分钟至30分钟，并发用户数为30.

　　3.2创建负载测试脚本

　　脚本是用来运行需要测试对象的主要力量。

　　脚本主要分了3个部分vuser_init和Action和vuser_end这三个部分，vuser_init 是虚拟用户创建的函数，vuser_end是运行结束后销毁虚拟用户的函数，Action是主要的代码运行测试的部分。

　　Action可以建立多个，每一个Action都负责各自的事情。

Action()

{

//输入字符串

char input[500]="command=";

//日志记录地址

char *address="D:\\LoadRunnerWorkSpace\\RunLog\\log.log";

long filename;//定义存储文件指针的变量

//输入参数，进行了参数化，可以进行配置

char *cmd = lr_eval_string("{InputParam}");

//输出参数

char *out = "";

lr_start_transaction("init"); //定义初始化事务

strcat(input,cmd);

lr_end_transaction("init", LR_AUTO);//结束初始化事务

lr_rendezvous("beginaction");//事务集结点

lr_start_transaction("call");//初始化访问接口的事务

web_service_call( "StepName=ExecuteCommand_102",

"SOAPMethod=Test|TestSoap|ExecuteCommand",

"ResponseParam=response",

"Service=Test",

"ExpectedResponse=SoapResult",

"Snapshot=t1397177849.inf",

BEGIN_ARGUMENTS,

input,

END_ARGUMENTS,

BEGIN_RESULT,

"ExecuteCommandResult=outPutParams",

END_RESULT,

LAST);

lr_end_transaction("call", LR_AUTO);//结束访问接口事务

lr_start_transaction("log");//初始化记录日志事务

//获取输入值

out = lr_eval_string("{outPutParams}");

//输出信息

lr_output_message("调用日志|Cmd=%s|Re=%s\r\n",cmd,out);

//写自定义日志文件

if ((filename=fopen(address,"a+"))==NULL)//打开文件

{

lr_error_message("can not open this file,address=%s",address);

return -1;

}

fprintf(filename,"调用日志|Cmd=%s|Re=%s\r\n",cmd,out);

lr_end_transaction("log", LR_AUTO);//结束访问接口事务

lr_start_transaction("interval");

lr_think_time(0.1); //定义思考时间，思考时间和模拟程序对业务处理事件有些类似

lr_end_transaction("interval", LR_AUTO);

return 0;

}

　　创建完成脚本之后单次执行该接口查看action程序是否正确，能够正常运行。

　　如果能够正常运行，进行下一步操作。

　　3.3执行负载测试（Run Load Tests）

　　在执行之前（Design）中对我的测试目标的3个请求源进行配置，创建相应的请求场景，这个配置可以在（Interactive Schedule Graph）查看相应请求场景。

　　配置好之后在（Run）点击Start scenario。

　　经过漫长的等待测试运行完毕，系统自己生成响应的测试结果，泡杯茶小酌一杯呵呵。

　　3.4执行测试结果的分析（Analyze Load Tests）

　　导入生成的res1文件，系统会自动生成出相应的测试报表。在Analysis Summary中就可以看出整体的测试结果。

　　还可以通过查看Running Vusers的情况了解整理的并发访问情况。

　　查看Hits per Second，查看每秒的请求数量的走势。

　　查看Throughput，可以查看整个压力测试过程中处理数据的吞吐量情况，是否达到设计的要求。

　　查看Transaction Summary，查看整个压力测试的所处理的事务的汇总统计。

　　查看Average Transaction Response Time ，可以查看整个Action中所有事务处理的时间走势。

　　4.通过上面的测试结果我们可以判定我们的测试是否满足要求

　　不要迷信性能测试，所有的性能“系统的性能不是测试测试出来的，而是系统设计出来的。”

　　LoadRunner能做系统程序的性能测试，在一些大型系统中，可能对系统测试要分为多个目标多个维度，要对硬件架构进行性能测试，对系统进行性能测试，对网络进行性能测试等等多个维度。

　　性能测试的目的有两方面，第一方面是测试系统是否满足设计要求。第二方面发现系统的瓶颈，为系统优化提出修改建议。

顺其自然EVO 2014-04-25 10:08 发表评论

如何用Jmeter做压力测试

顺其自然EVO — Fri, 25 Apr 2014 02:06:00 GMT

Jmeter是一个性能测试工具，同loadrunner类似，他功能较多，我们常用的功能是用jmeter模拟多浏览器对网站做压力测试。

　　下载jmeter地址：http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi

　　我们一般的网站，在进入业务功能前先需登录，然后才能访问业务功能。下面介绍如何用jmeter登录系统再对主业务做压力测试。

　　1. 运行jmeter

　　2. 左边树将出现测试计划、工作台两根节点。

　　3. 选择测试计划，按右键－》添加－》threads（users）线程组

　　线程组能设置以多少个线程并发做压力测试。

　　在”循环次数”设置不选择永远，循环次数设置1。

　　4. 现在先介绍如何设置登录http请求，选择线程组，右键――添加――》sampler－―》http 请求。

　　http请求即模仿浏览器的访问。

　　在“服务器名称或ip”设置127.0.0.1，端口号设置:8080，“方法”设置post，路径设置网站登录的地址，如“/exam/operatorAction”。

　　登录需传入用户、密码。在“同请求一起发送参数”列表中添加参数。参数值根据web应用设置。如login_user=0001;login_password=1;actFlag=login

　　5. 登录成功后，网站一般将跳入主页面。在jmap中可做判断，判断是否登录后按预想进入主页面（此步骤也可不设）。选择4中的“http请求“，右键――》添加――》断言――》响应断言。“Apply to”设置Main smaple only；“要测试的响应字段”设置“url样本”；“模式匹配规则”设置“包括”，“要测试的模式”增加页面跳转到的主页面，如：“studentMain.jsp”

　　6. 一般网站登录后，在tomcat中生成了session，之后访问其他页面将无需再次登录，前提是浏览器需支持cookie。在jmap中也同样，如要继续访问其他页面，还需做下面关键的设置。

　　选择“线程组”――》右键――》添加――》配置元件――》Http cookie管理器。加了此步骤后，http请求将具备cookie功能，即登录成功后访问其他页面将不会跳转到登录页面重新登录。

　　7. 对目标页面反复压力测试。

　　7.1 如何使被测页面反复访问达到测压效果。选“线程组”―》右键――》逻辑控制器――》循环控制器。循环次数中选择“永远”。

　　7.2 选择刚加的“循环控制器”，右键――》添加――》sampler－―》http 请求，按4步骤设置ip、端口，http请求方法为“get”，路径为被压力测试的url，如：“exam/business/studentExam.action.StudentExamAction?action=goIntoMockExam”。

　　按上面的设置后，已完成配置，可做压力测试。只需点菜单“运行”――》启动，即运行压力测试。

　　8. jmeter提供了许多压力结果查看工具。是压力测试时非常好的分析工具。下面几种查看工具可有选择的添加。

　　8.1 察看结果树。他记录每次请求发送数据、响应返回数据。选择“线程组”――》右键――》添加――》察看结果树。

　　8.2 用表格查看结果。可查看每次请求的响应时间等。选择“线程组”――》右键――》添加――》用表格查看结果。

　　8.3 Summary Report。可查看平均响应时间、最长响应时间等。

顺其自然EVO 2014-04-25 10:06 发表评论

性能测试学习内容指南

顺其自然EVO — Wed, 26 Mar 2014 02:50:00 GMT

1. 性能测试理论

　　性能测试常用术语

　　性能测试的应用领域

　　性能测试工具原理

　　2.LoardRunner基本操作及应用

　　LoardRunner原理分析

　　LoardRunner脚本开发流程

　　VuGen(基本设置、检查点、参数化、关联、调试、事物)

　　Controller(场景设计、场景监视数据库服务器>、集合点、IP欺骗技术、负载均衡、场景执行)

　　Analysis(摘要报告、常见图分析、结果分析实践<分析图合并、分析图关联、页面细分、钻取技术、外部数据导入、HttpWatch分析>)

　　3.Linux监测、分析、调优

　　CPU监控

　　内存监控

　　磁盘监控

　　网络监控

　　4.Windows监测、分析、调优

　　LoardRunner直接监控、Windows性能工具监控、Windows计数器

　　5. 数据库监测、分析、调优

　　6. 常用的服务器监测、分析、调优

　　Apache监控

　　Apache调优

　　Tomcat监控

　　7. 前端性能调优

　　前端性能分析概要

　　Firebug工具

　　HttpWatch

　　Chrome自带的开发工具

　　DynaTrace Ajax Edition工具

　　8.网络分析

　　9.代码分析与调优

　　10.项目实战

　　11.推荐书籍

　　<<软件性能测试过程详解与案例剖析>>

　　<<性能测试进阶指南>>

　　<<深入性能测试LoardRunner>>

顺其自然EVO 2014-03-26 10:50 发表评论

性能测试之系统监控工具nmon

顺其自然EVO — Tue, 25 Mar 2014 02:58:00 GMT

一、概述

　　本篇文章主要讲解nmon，以下为目录

　　1.nmon介绍

　　2.nmon下载、安装及使用

　　3.nmon analysis 分析及使用，各个项的含义

　　二、详细信息：

　　1.nmon介绍:

　　nmon(Nigel's Monitor)是由IBM公司提供的、免费监控AIX系统与Linux系统资源的工具，该工具可以将服务器系统资源消耗的数据收集起来并输出一个特定的文件，再使用分析工具(nmon analyser)进行数据统计分析。

　　nmon主要记录以下方面的数据：

　　CPU占用率

　　内存使用情况

　　磁盘I/O速度、传输和读写比率、错误统计率与传输包的大小

　　消耗最多的进程

　　计算机详细信息和资源

　　页面空间和页面I/O速度

　　用户自定义的磁盘组

　　网络文件系统

　　nmon工具工作流程

　　Step1.执行nmon工具命令，nmon工具会将输出的内容显示到计算机屏幕，同时生成一份nmon文件

　　Step2.将生成的nmon文件导出到Windows 操作系统，使用分析工具对生成的数据文件进行分析

　　Step3.该分析工具将收集到的数据绘制成相关的图表，供分析使用

　　2.nmon下载、安装及使用

　　nmon下载地址：

　　官网下载地址：下载linux 对应的 nmon

　　其它方式下载：http://down.51cto.com/data/849411

　　a.安装：下载完后，将其上传到linux下的某个目录下,运行命令tar –xvf file.tar,解压后

　b.修改权限chmod nmon_linux_x86,

　　c.运行./nmon_linux_x86 -f -r test -s 10 -c 15，此时会生成一个test文件，主要是把监测的结果实时的写进该文件

　　d.运行./nmon_linux_x86,出现监测主窗口，按照菜单输入相应的字母，即可监测，比如输入c,m,d,n等，即监测CPU,Memory,Disks,Netword

　　e.一段时间后，将生成的test.nmon文件转化成csv文件，sort test.nmon >test.csv,然后download wondinds本地

　　f.打开nmon analysis 工具，导入test.csv,即生成如下图

　　3.nmon analysis 分析及使用，各个项的含义

　　具体可以google或者百度或者参考nmon analysis user guide,这里不再赘述

顺其自然EVO 2014-03-25 10:58 发表评论

BlogJava-qileilove-随笔分类-性能测试

Jenkins+Ant+Jmeter自动化性能测试平台

记一次性能测试实践

LoadRunner运行过程中的一个诡异问题

性能测试过程模型

性能测试中如何确定并发用户数

LoadRunner 12 发布—主推云测试平台

VM性能的快速测试方法

LoadRunner监控数据库服务器

Jmeter在命令行运行技巧

使用SoapUI测试Web Service

性能测试流程剖析

性能测试URL自动转码

Jmeter性能测试报告解析

码农的性能测试

谈谈性能测试分类

Lr11、QTP11破解时需要注意的问题

性能测试个人经验小结

设置Loadrunner负载机临时文件目录

网站性能测试工具—ApacheBench

成为无可替代，从提升自己的贡献开始！

如何做好安卓手机的performance测试？

Django性能测试—一个现实世界的例子

线程上下文切换的性能损耗测试

性能测试—性能环境与数据

PAAS平台的web应用性能测试与分析

性能分析软件之yourkit入门介绍

LoadRunner使用入门 进行Webservice负载测试

如何用Jmeter做压力测试

性能测试学习内容指南

性能测试之系统监控工具nmon

LoadRunner使用入门进行Webservice负载测试