概述 Hadoop Mapreduce是一个简单易用的框架。基于MapReduce写出来的程序能够运行在由上千台商用机器组成的大型集群上,以一种可靠的容错的方式并行处理T级别的海量数据。 一个MapReduce作业通常会把输入的数据集拆分成独立的块,由map任务(task)以完全并行的方式处理。框架先对map的输出结果进行排序,排好序的结果会做为reduce任务的输入。通常作业的输入和输出都存放在一个文件系统里。MapReduce框架负责任务的调度和监控,并重新执行已经失败的任务。 一般来说Hadoop的计算节点和存储节点是在相同的机器上。这是因为MapReduce和HDFS运行在一组相同的节点上。这种设计允许MapReduce在已经存储好数据的节点上高效地进行任务调度,从而更集中高效地使用整个集群的带宽。 MapReduce框架的组成包括:一个单独的master(ResourceManager),集群每个节点上都有一个slave(NodeManager),以及每个应用程序上的MRAppMaster(参考YARN架构)。 应用程序最少应该指定输入输出的位置,并通过实现合适的接口和(或)抽象类来提供map和reduce函数。有了这些设置,再加上其他作业参数,就组成了作业配置(job configuration)。 接下来,Hadoop的作业客户端(job client)就会提交作业(job, 一般是jar包或其他可执行程序)和配置信息给ResourceManager,ResourceManager负责分发软件和配置信息给slave,调度并监控任务执行,并提供状态和诊断信息给作业客户端(job-client)。 尽管Hadoop框架是使用Java实现的,但是MapReduce程序不一定要用Java来写,比如我们可以使用Hadoop Streaming和Hadoop Pipes。 Hadoop Streaming是一种运行作业的实用工具,它允许用户创建和运行任何可执行程序(例如:Shell)来做为mapper和reducer。 Hadoop Pipes是一个与SWIG兼容的C++ API (没有基于JNITM技术),它也可用于实现Map/Reduce应用程序。 输入和输出 MapReduce框架基于<key, value>对执行,也就是说,MapReduce框架把作业的输入视为一组<key, value>对,并生产一组<key, value>对作为作业的输出。这两组<key, value>对可以是不同的类型。 MapReduce框架需要对key和value的实例进行序列化操作,因此这些类需要实现Writable接口。此外,key对应的类还要实现WritableComparable接口以适应MapReduce框架对排序的要求。 一个Mapreduce作业的输入输出类型如下: 注意combin的输出类型是要和map的输出类型一致的。 实例:WordCount v1.0 在深入细节之前,我们先看一个MapReduce的应用示例,以对MapReduce的工作方式有一个初步的认识。 WordCount 是一个简单的应用,可以用来统计在一组输入数据中某个单词出现的次数。 这个应用适用于单机模式,伪分布式模式或完全分布式模式三种Hadoop安装方式。 源码如下,我做了折叠,点开查看就好: 工程的maven的配置如下,也是做了折叠,点开查看就好: 执行“mvn clean package”完成打包。 执行如下命令运行MapReduce任务: 其中/adt/input是输入目录,/adt/output是输出目录,输入和输出目录都在HDFS上。输入目录下可以有多个输入文件。在/adt/input下有两个输入文件,可以看一下文件的内容: 看一下输出结果: 运行命令说明 应用程序能够使用-files选项来指定一个由逗号分隔的路径列表,这些路径是task的当前工作目录。使用选项-libjars可以向map和reduce的classpath中添加jar包。使用-archives选项程序可以传递压缩文档做为参数,这些压缩文档会被解压并且在task的当前工作目录下会创建一个指向解压生成的目录的符号链接(以压缩包的名字命名)。 使用-libjars, -files and -archives运行wordcount实例: 在这里,压缩文档myarchive.zip将被解压并存放在以“myarchive.zip”命名的目录下。 用户也可以使用#标识通过-files或者-archives为文件或压缩文档指定一个别名。 举个例子: 在这个例子中,通过别名dict1和dict2分别访问文件dir1/dict.txt和dir2/dict.txt。而压缩文档mytar.tgz将会被解压并置于名为“tgzdir”的目录下。 关于Map 程序中的map方法: Mapper的实现类通过map方法,一次处理一行由指定的FileInputFormat提供的记录。然后Mapper通过StringTokenizer将这一行记录以空格为分隔符分割成若干Tokens,而后输出格式为< <word>, 1>的key-value对。 对于提供的第一个输入样本,map的输出内容为: 第二个样本的map输出内容为: 在我们的WordCount程序里还指定了一个combiner。 每个map运行后,会对输出按照key进行排序,然后把输出传递给本地的combiner(按照作业的配置与Reducer一样),进行本地聚合。 第一个map的输出: 第二个map的输出: 关于reduce reduce的代码: Reducer实现类的reduce方法只是将每个key(本例中就是单词)出现的次数求和。 因此这个作业的输出就是: 关于main方法 main方法指定了作业的几个方面,比如说输入输出路径(通过命令行提供),key和value的类型,输入输出的格式等信息。在作业中,调用了job.waitForCompletion函数提交作业并监控它的执行。 ############
[阅读更多...]-
关于MapReduce1 – QuickStart
-
使用PyMySQL
适用环境 python版本 >=2.6或3.3,mysql版本>=4.1。 安装 可以使用pip安装也可以手动下载安装。 使用pip安装,在命令行执行如下命令: 如需要手动安装,请先下载,下载地址:https://github.com/PyMySQL/PyMySQL/tarball/pymysql-X.X。其中的X.X是版本号(目前可以获取的最新版本是0.6.6)。 下载后解压压缩包。在命令行中进入解压后的目录,执行如下的指令: 建议使用pip安装。 使用示例 连接数据库如下: 也可以使用字典进行连接参数的管理,我觉得这样子更优雅一些: 写入数据的代码: 执行sql语句前需要获取cursor,因为配置默认自动提交,故在执行sql语句后需要主动commit,最后不要忘记关闭连接。 执行查询: 这里的查询支取了一条查询结果,查询结果以字典的形式返回。 从结果集中获取指定数目的记录,可以使用fetchmany方法: 不过不建议这样使用,最好在sql语句中设置查询的记录总数。 获取全部结果集可以使用fetchall方法: 因为只有两条记录,所以上面提到的这两种查询方式查到的结果是一样的: 在django中使用 在django中使用是我找这个库的最初目的。目前同时支持python3.4、django1.8的数据库backend并不好找。PyMySQL是我目前找到的最好用的。 设置DATABASES和官方推荐使用的MySQLdb的设置没什么区别: 关键是这里:我们还需要在站点的__init__.py文件中添加如下的内容: All! #####
[阅读更多...] -
搭建Hadoop运行环境
准备工作 安装JDK JDK版本一般要求是JDK1.7。JDK1.6较新的版本也可以使用。这里使用的是JDK1.8。 官方有一个JDK与Hadoop版本对照表,可以参考一下:http://wiki.apache.org/hadoop/HadoopJavaVersions。 JDK安装完成后需要配置PATH环境变量和JAVA_HOME环境变量。 安装ssh和rsync软件 执行如下的命令安装: 下载Hadoop Hadoop的下载地址:http://www.apache.org/dyn/closer.cgi/hadoop/common/。选择需要的版本下载即可。 配置Hadoop的hadoop_env.sh文件 hadoop-env.sh文件用于配置hadoop集群特有的变量信息。在这里至少需要配置JAVA_HOME变量。解压下载的hadoop-xxx.tar.gz文件,移动到部署位置,打开etc/hadoop/hadoop-env.sh文件,添加如下的参数: 这里需要说明一下,如果是单机模式,这一行可以不用配置,但是伪分布式模式下,这一行一定需要配置。虽然可能已经正确的配置了JAVA_HOME环境变量,但是启动时还是可能会报出上述错误,从etc/hadoop/hadoop-env.sh文件关于第一行配置:export JAVA_HOME=${JAVA_HOME}的注释上来看,对于一个分布式集群,这里JAVA_HOME最好显式地指明而不要使用默认的${JAVA_HOME}。对于etc/hadoop/yarn-env.sh也是如此! 到此准备工作算是已经完成。 此外还建议将hadoop的bin和sbin目录添加到系统环境变量PATH中,这样使用起来也方便些。 环境搭建 Hadoop环境搭建有三种模式: 单机模式 伪分布模式 分布模式 因为只是自己使用而且条件也有限,所以只在这里说下前两种方式。 单机模式 默认情况下,hadoop被设置为在非分布式模式下,以单一java进程运行。也就是说完成了准备工作后我们就做好了Hadoop单机模式的搭建。单机模式的Hadoop在程序调试时是很有用的。 在下面的例子中将使用hadoop自带的示例程序做一个演示。我们使用解压后的hadoop的conf目录作为输入内容,通过hadoop中自带的示例程序筛选出符合所提供的正则表达式的内容,并进行展示。进入hadoop安装目录,执行如下脚本: 上面的代码使用hadoop安装文件中提供的示例应用,完成了在一批文本文件中查找特征文字的工作。 伪分布模式 以伪分布模式部署hadoop后,每个hadoop后台进程都会在独立的java进程上运行。 配置伪分布式hadoop需要按以下步骤来完成。 1.参数设置 配置hadoop伪分布式运行环境至少需要配置两个文件:core-site.xml和hdfs-site.xml。这两个文件位于hadoop的安装目录/etc/hadoop目录下。 core-site.xml是hadoop的核心配置文件。在core-site中至少需要配置HDFS的地址及端口号。如下是core-site.xml的配置信息: hdfs-site.xml主要用于配置HDFS的相关属性参数。如下是hdfs-site.xml的配置信息: hdfs-site.xml主要用于配置HDFS的相关属性参数。在这里配置了dfs.replication属性。Dfs.replication用于指定HDFS中每个Block块被复制的次数。起到数据备份的作用。在生产环境中这个属性的值一般被设置为3。这里是伪分布式环境,只有一个节点,因此将之设置为1。 此外,有的人还会考虑将hadoop的tmp目录以及hdfs的namenode和datanode对应的文件目录重置。 调整tmp目录的位置需要修改core-site.xml: 修改hdfs的namenode和datanode对应的文件目录需要修改hdfs-site.xml: 再就是日志目录的调整了。如果有修改日志目录的需要的话可以直接修改hadoop-env.sh 文件,在最前方插入如下内容: 以上配置中关于目录的参数取自我自己的开发环境,使用时要根据自己情况重新调整。 2.SSH配置 Hadoop使用ssh协议来管理远程守护进程。首先检查一下是否能使用ssh免密码登录到localhost。指令如下: 如果ssh不能免密码登录到localhost。还需要执行如下指令: 配置完成后如果是首次ssh访问本机,还需要输入yes完成确认。 运行hadoop作业 这一节的内容演示了如何在本地执行MapReduce的Job。下一节会说明如何在yarn上运行MapReduce的Job。执行MapReduce作业可以按如下的步骤。 1. 格式化名称节点 执行如下命令: namenode主要用来存储HDFS上的文件的元数据信息。而format操作的作用就是为记录元数据做初始化准备。在单机开发环境下,系统可能会多次关闭和重启,然而上面这条命令只能执行一次。如果重复执行了,hdfs上已有的文件就会变成“黑记录”,影响hdfs的正常运行。 2.启动namenode和datanode的守护进程 执行如下命令: Hadoop守护进程的输出日志位于$HADOOP_LOG_DIR(在hadoop-env.sh中配置)下,默认是$HADOOP_HOME/logs下。 3.访问名称节点 可以使用浏览器通过web接口访问namenode,默认的访问地址是: 界面如下图: 可以看到通过这个地址能够看到一些关于hdfs的信息。前面也提到过namenode中记录的就是hdfs的元数据信息。 4. 设置执行MapReduce job的hdfs目录 执行mapreduce作业如果用到了hdfs,需要先准备一些必要的目录,比如user目录: 这里的username指的是hdfs所在的系统的用户名。 5.拷贝输入文件到hdfs 执行如下命令: 命令在hdfs创建了一个新的input目录,而后将hadoop安装目录/etc/hadoop下的所有xml文件复制到hdfs上的input目录下。 6. 运行hadoop提供的示例 代码如下: 这里执行的就是单机模式中的那个程序。 7. 查看输出结果 查看输出结果有两种方式,一是将hdfs文件系统中的文件copy到本地文件系统进行查看,如下面的代码: 查看结果: 结果: 或者直接在hdfs上查看: 8.退出 在执行完成后,关闭后台进程: 在伪分布式节点上运行yarn Hadoop2较之hadoop1的一个变化就是引入了YARN。接下来说一下如何在伪分布模式下配置YARN,并在YARN上运行MapReduce的job。在伪分布模式下配置YARN很简单,只需要修改几个配置文件,然后启动资源管理进程和节点管理进程即可。 1.配置 配置etc/hadoop/mapred-site.xml: 这里的配置说明了要使用yarn框架执行mapreduce的任务。 配置etc/hadoop/yarn-site.xml: 这里通过yarn的yarn.nodemanager.aux-services项自定义了shuffle服务。 2.启动 启动ResourceManager和NodeManager进程: 3.通过浏览器访问ResourceManager 访问地址是: 4.运行一个mapreduce作业 可以再执行一遍上面的2-7步。 5.关闭yarn 所有工作做完后,关闭yarn: 参考文档 namenode format做了什么:http://blog.csdn.net/xhh198781/article/details/6904615 hadoop native本地库问题总结:http://blog.csdn.net/ligt0610/article/details/47757013 英文原文:http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/SingleCluster.html ##########
[阅读更多...] -
基于JMeter进行分布式测试
我工作中的笔记本配置还可以。但是在测试一个简单的TCP连接时,发现把线程数设置为10000时,我的笔记本会很快死掉。最终实验出我的笔记本可以承受的安全线程数是5000。可是对应用的最低性能要求就是能承受1w的并发。此时可以采用基于JMeter的分布式测试方案。 如刚才提到的,要求测试应用在1w并发下的表现,而一部计算机所能承受的线程数是5000,那么需要两部计算机。 步骤 具体步骤如下: 为两部机器都安装JMeter; 定义两部机器的角色,一部是master,一部是slave;我们直接操作master,而slave只是负责分担master的压力; 获取slave的ip地址,比如是192.168.1.12; 在master的JMeter目录下打开bin目录,编辑jmeter.properties文件。找到“remote_hosts=127.0.0.1”这一行,将之修改为“remote_hosts=127.0.0.1,192.168.1.112:1099”。其中1099是master和slave的RMI通信端口。编辑完后记得保存; 打开master上的JMeter,点击运行菜单项,运行->远程启动->选择要启动的slave的IP;如果需要全部启动,运行->远程全部启动即可。 注意事项 有几点需要注意: 1. 启动jmeter-server服务时,提示: 这个是开始没有找到ApacheJmeter_core.jar,后来去JMETER_HOME目录下去查找,最后找到了,如果不希望看到Could not find的字样,可以配置一下jmeter_home的路径(即bin目录的上一级目录),这样启动jmeter-server服务时,就只会看到Found ApacheJMeter_core.jar,当远程访问时,会看到控制台上打印出一行:Starting the test on host [ip]:1099 @….(大概是这样的,@后面是执行开始的时间),远程执行结束,会打印一行:Finished the test on host [ip]:1099 @…,表示远程执行结束。 2. 留意一下1099端口,目前暂未确定这个端口是不是可以改的(按理说这个是可以从配置文件中修改的,目前还没有找到如何修改Agent上面的配置,Controller上面的还好修改) 3. Jmeter分布式控制过程中,各个Agent启动的线程数等于线程组中的配置,不是均分线程组中的配置。 参考文档 http://blog.chinaunix.net/uid-26884465-id-3419474.html http://www.51testing.com/html/12/252512-223613.html
[阅读更多...] -
JMeter监听器说明
JMeter的监听器可以理解为JMeter提供的测试分析工具(或者测试结果报告)。JMeter监听器的监听范围是当前节点及其子节点。JMeter提供了多种测试监听器,这里简单说几个用过的监听器。 创建测试计划 为了演示监视器的作用,我这里做了一个简单的HTTP请求测试。 如何创建测试计划就不多说了,可以参看这篇文章:《使用JMeter》 下图是线程组的配置: 下图是HTTP请求的配置参数: 启动测试,很快就可以生成测试结果报告。 用表格查看结果 下图是表格结果: 还有几个重要的指数: 简单说下表格中的字段: Sample#——每个请求的ID; StartTime——每个请求启动时间; SampleTime——响应每个请求的时间(以毫秒为单位); Status——请求状态,如果为勾则表示成功,如果为叉表示失败; Bytes——请求的字节数; Latency——延迟时间; ConnectTime——请求连接用时。 几个指数: 样本数目——样本总数(线程数*循环次数),或者说是发送给测试应用的请求总数; 最新样本——服务器响应最后一个请求的时间; 平均——请求响应时间的平均值; 偏离——请求响应时间的标准差。 聚合报告 下图是本次测试的聚合报告: Label——取样器名称; Samples——发给被测试应用的请求总数; Average——请求响应时间的平均值; Median——请求响应时间中值,即50%的请求响应时间都小于该值(一个统计学的概念); 90%Line——请求响应时间90%线,即90%的请求响应时间都小于该值; Min——最小响应时间; Max——最大响应时间; Error%——出错率(出错的请求数/所有的请求数); Throughput——吞吐量,每秒/每分钟(具体看“/”后面的单位)处理的请求数; KB/sec——每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec; 【注意】总体值并不是各列对应记录的累加。是以所有Samples为样本的统计值,如:总体Min=min{各个Samples的Min},总体Max=max{各个Samples的Max}。 Summary Report(总结报告) 下图是本次测试的Summary Report: 觉得这个和聚合报告一起看有点意思。 Label——取样器名称; Samples——发给被测试应用的请求总数; Average——请求响应时间的平均值; Median——请求响应时间中值,即50%的请求响应时间都小于该值(一个统计学的概念); 90%Line——请求响应时间90%线,即90%的请求响应时间都小于该值; Min:最小响应时间; Max:最大响应时间; Std.Dev——所有请求响应时间的标准差,即是“用表格查看结果”中的偏离; Error%——出错率(出错的请求数/所有的请求数); Throughput——吞吐量,每秒/每分钟(具体看“/”后面的单位)处理的请求数; KB/sec——每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec; Avg.Bytes——服务端返回给Request数据的平均值(服务端返回所有数据/请求数)。 图形结果 本次测试的图形结果如下图: 这里的几个指数上面都有提到。还是再说一次吧: 样本数目——样本总数(线程数*循环次数),或者说是发送给测试应用的请求总数; 最新样本——服务器响应最后一个请求的时间; 平均——请求响应时间的平均值; 偏离——请求响应时间的标准差; 吞吐量——每秒/每分钟(具体看“/”后面的单位)处理的请求数; 中值——请求响应时间中值,即50%的请求响应时间都小于该值。 查看结果树 下图是查看结果树: 简单说几个概念: 取样器结果——显示的是请求样本相关参数(客户端参数与响应参数) 请求——发送请求的具体值 响应数据——服务端返回的相应参数 ALL! 参考文章 http://www.51testing.com/html/12/252512-223091.html http://www.cnblogs.com/jackei/archive/2007/01/17/623166.html http://www.cnblogs.com/Carrie_Liang/archive/2008/11/10/1330997.html http://zuoye.baidu.com/question/1d937880d6e95b419397e16b267a71ba.html
[阅读更多...] -
使用JMeter
JMeter是一款基于java开发的压力测试应用。最初是为测试 Apache JServ(tomcat的前身)的性能而开发的。不久以后,JMeter也成为了jakarta的一个子项目。 安装 截至目前(20150408),JMeter最新的版本是2.13。用户可以在JMeter官网下载最新的稳定版本。官网提供了.zip和.gz两种格式的下载文件。JMeter2.13需要JDK1.6或更高版本的环境。 下载解压完成后,可以尝试启动jmeter。在linux环境下,运行bin目录下的jmeter脚本,在windows环境下,需要调用jmeter.bat文件。建议将bin目录添加到系统环境变量下,以便调用。下图是JMeter的主窗口: 可以看到,整个界面分为两部分。左侧是测试中需要使用的元素,包括测试计划和工作台。在这篇文章里,我们主要说说测试计划的使用。右键点击测试计划(或工作台),可以添加新的测试计划(或工作台)元素。右键点击新增的测试计划(或工作台)内容,可以选择将之删除。右侧面板则展示了测试计划或工作台的详细信息。 现在可以准备使用JMeter了,但是有两点需要注意: 不可以将JMeter和被测试的应用在同一台机器上运行。因为JMeter会占用大量的系统资源,如果被测试的应用在同一台机器上的话,应用的性能会受到影响; 尽量避免测试受到网络因素的影响。最好可以让网络管理员建立一个隔离的子网络来运行JMeter和被测试的应用。 一个简单的测试 首先,我们进行一个非常简单的测试。在这个测试里,我们将建立一个测试计划,并对一个web应用进行测试。通过这个测试,你可以了解到JMeter的一些常用概念,并基本掌握使用JMeter进行测试的能力。 在实施测试前,我们需要先创建一个测试计划。测试计划描述了使用JMeter进行测试的步骤。一个测试计划包括一个或多个线程组、逻辑控制器、配置元件、定时器、前置处理器、后置处理器、Sampler、断言、监听器等等。如果不懂这些东西是做什么的,先不要担心,我们会在后面的部分说清这些元素的用法。 一个测试计划需要有至少一个线程组。线程组是测试计划实施的起点,它可以包含JMeter实施测试的其它元素。在测试中,线程组负责控制JMeter模拟的用户线程。 现在我们从创建线程组开始。右键点击测试计划,添加->Threads(Users)->线程组,这样就可以在测试计划下新增一个线程组元素了。点击新建的线程组,可以看到下图: 简单介绍下面板中的几个属性: 名称——线程组的名字。可以用一个简短的名称来描述线程组,也可以在注释中给它添加说明; 线程数——JMeter创建的线程数。每个线程代表一个用户。如果想测试10个用户同步操作,那么输入10; Ramp-Up Period——这里标识JMeter创建所有的线程所需要的时间,时间单位是秒。如果线程数是10,Ramp-Up Period是20秒,那么就表示JMeter将在20秒内创建10个线程,即每2秒创建一个线程。如果要20个线程立刻创建完成的话,那么输入0; 永远——如果勾选的话,这个选项会使JMeter无限次地发送请求给被测试应用。如果不勾选的话,那么JMeter只会重复发送指定循环次数的请求; 循环次数——这个属性只会在“永远”复选框没有勾选的情况下发挥作用。这个属性是用来告诉JMeter循环发送多少次请求。 在我们这个小测试中,按照下图来填充测试时的属性。我们模拟了两个用户,每个用户会发送三次请求。这次我们使用了几个非常小的数,这是为了方便我们接下来解释测试结果。在真正的测试环境中,我们更喜欢使用一些很大的数字。 接下来,我们将添加一些测试HTTP 请求的元素。右键点击线程组,添加->Sampler->HTTP请求,这样就添加了一个HTTP请求元素。点击“HTTP请求”,可以看到如下图所示的界面: 在“HTTP请求”面板上,可以设置HTTP请求的参数。这里,有如下几个属性: 名称——HTTP请求的名称。名称需要有足够的代表性,要知道一个线程组中一般会有多个HTTP 请求; 服务器名称或IP——测试应用所在的主机名称或IP地址; 端口号——测试应用所占用的端口号; 协议——所使用的协议,如HTTP或HTTPS; 方法——请求方法,如GET或POST; 路径——资源请求的路径; 跟随重定向——如果有重定向的话是否跟随; Use KeepAlive——如果勾选的话,在请求头中将会包含“Connection = Keep-Alive”;一般的浏览器,在使用HTTP1.1协议发送请求的时候会默认使用“Connection = Keep-Alive”作为连接头。因此,这个复选框一般都会被勾选上; Parameters——请求中所发送的参数列表,可以使用添加、删除按钮添加或删除参数; 同请求一起发送文件——模拟文件上传。 现在,弄清“HTTP请求”中的配置参数了吧。我们还有最后一个要添加到ThreadGroup中的元素,就是监听器。监听器在JMeter中的作用类似于报表。JMeter提供了多种报表,包括图形报表和表格报表。在这次测试中,我们使用最简单的表格报表。右键点击线程组元素,添加->监听器->用表格查看结果,添加表格报表。 好了,一切就绪,可以运行我们的测试计划了。在这之前还有最后一个忠告:在执行测试计划前一定要先保存测试计划,因为JMeter有可能会导致系统崩溃(在线程和循环次数较多的情况下可能会发生这样的情况)。现在,点击绿色的启动按钮运行我们的测试计划吧。 在测试计划运行期间,工具栏右侧有个小方块会变成绿色(有时需要将窗口最大化)。 因为一个测试不会无限期的执行下去,当测试计划执行完毕时,JMeter会自动将之关闭。若JMeter无法自动关闭测试,就需要我们做出干预。点击红色的停止或关闭按钮,关闭所有的连接,结束当前的测试计划。 运行我们的测试计划,得到的结果如下图: 表格中的信息还是比较容易理解的。一共产生了6个测试样本(2个线程,3个循环次数,2*3=6)。表格的第6列标识所有的样本都已测试成功。表格的第5列是样本响应时间,分别是33,32,11,11,10,10。平均响应时间是(33+32+11+11+10+10)/6 = 17(这里是向下取整)。 另外一个重要的指数是偏离度。偏离度是每个样本的响应时间与平均值之间偏差的平方之和的平方根(有点绕,实际上就是标准差,可以据此分析离散性,概率论相关概念)。这个数值标识了被测试应用的稳定性。如果偏离度比较高的话,说明一部分用户会得到非常快速的响应,而另一部分用户却会等上很长的时间。总之,偏离度这个值是越小越好。 练习了这样一个简单的测试后,也就可以从容应对一些复杂的测试了。在进行Web应用的压力测试时,可以逐步提高线程数和循环数,以便观察被测试应用是怎样应对高负载压力的。 接下来的几节将说明一些使用JMeter进行压力测试的一些比较重要的内容。 监听器 JMeter提供了多种监听器(或者说是报表)。在刚才的测试中,我们使用了表格来展示测试结果。如果表格报表不能满足需求的话,还可以为线程组选择一个或者多个监听器。其中比较常用的一个监听器是“图形结果”,如下图所示: 复合HTTP请求 一个web应用可能同时包含静态的和动态的资源。如果想查看这些资源的性能,JMeter可以很轻松地实现发送复合式的HTTP请求。实现这个测试,只需要添加一定数目的“HTTP请求”元素,并分别进行配置即可。当建立了多个HTTP请求元素时,你可能会希望为所有的HTTP请求创建默认值,下一节会说明如何建立HTTP请求默认值元素。 HTTP请求默认值 右键点击线程组元素,添加->配置元件->HTTP请求默认值,添加HTTP请求默认值元素。正如其名,HTTP请求默认值元素指定了同一个线程组下所有的HTTP请求元素的配置参数默认值。HTTP请求默认值是一个非常有用的元素。在绝大多数情况下,HTTP请求总会有些相同的配置参数属性,比如服务器和端口。 HTTP Cookie 管理器 许多web应用都使用了cookie。JMeter通过HTTP Cookie管理器提供了cookie管理功能。在线程组中添加了cookie管理器后,就可以像浏览器一样发送cookie信息了。右键点击线程组元素,添加->配置元件->HTTP Cookie 管理器,可以添加HTTP Cookie管理器,下图是cookie管理器的配置页: 总结 这次我们只是做了一个十分简单的测试,而使用JMeter能做的事情远远不止这些。通过我们提到的这些元素,可以使用JMeter进行各种测试并取得详尽的测试结果报告。这样得到有价值的结果也很容易了。 OK! 本文是翻译的一篇英文文章。难免有词不达意的地方,还请见谅。 原文在这里:http://www.onjava.com/pub/a/onjava/2003/01/15/jmeter.html 还有,这是JMeter的用户手册,虽然说得比较简略,可还是聊胜于无:http://jmeter.apache.org/usermanual/index.html
[阅读更多...]