如何用各大运营商网络去测试一个服务器的网络性能
需要自己用不同的运营商的网络,连接这个服务器,不同的服务有不同的软件,比如下载服务器,那么直接找个服务器上的大文件进行下载,就可以检测连接到这个服务器连接速度。
至于稳定性,需要在多个时间点进行连接,看是否能正常运行。
Apache jmeter 可以用于对静态的和动态的资源(文件,Servlet,Perl脚本,java
对象,数据库和查询,FTP服务器等等)的性能进行测试。它可以用于对服务器,网络或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。
JMeter主要特性:
能够对HTTP和FTP服务器进行压力和性能测试, 也可以对任何数据库进行同样的测试(通过JDBC)。
完全的可移植性和100% 纯java。
完全 Swing 和轻量组件支持(预编译的JAR使用 javaxswing)包。
完全多线程 框架允许通过多个线程并发取样和 通过单独的线程组对不同的功能同时取样。
精心的GUI设计允许快速操作和更精确的计时。
缓存和离线分析/回放测试结果。
高可扩展性:
可链接的取样器允许无限制的测试能力。
各种负载统计表和可链接的计时器可供选择。
数据分析和可视化插件提供了很好的可扩展性以及 以及个性化。
具有提供动态输入到测试的功能(包括Javascrīpt)。
支持脚本变成的取样器(在192及以上版本支持BeanShell)。
常见的性能测试方法有以下几种:
1.负载测试
在这里,负载测试指的是最常见的验证一般性能需求而进行的性能测试,在上面我们提到了用户最常见的性能需求就是“既要马儿跑,又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下的性能表现。我们对负载测试可以有如下理解:
(1)负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。
(2)负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。
2.压力测试
压力测试是为了考察系统在极端条件下的表现,极端条件可以是超负荷的交易量和并发用户数。注意,这个极端条件并不一定是用户的性能需求,可能要远远高于用户的性能需求。可以这样理解,压力测试和负载测试不同的是,压力测试的预期结果就是系统出现问题,而我们要考察的是系统处理问题的方式。比如说,我们期待一个系统在面临压力的情况下能够保持稳定,处理速度可以变慢,但不能系统崩溃。因此,压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。
例子:负载测试关心的是用户规则和需求,压力测试关心的是软件系统本身。对于它们的区别,我们可以用华山论剑的例子来更加形象地描述一下。如果把郭靖看做被测试对象,那么压力测试就像是郭靖和已经走火入魔的欧阳峰过招,欧阳锋蛮打乱来,毫无套路,尽可能地去打倒对方。郭靖要能应对住,并且不能丢进小命。而常规性能测试就好比郭靖和黄药师、洪七公三人约定,只要郭靖能分别接两位高手一百招,郭靖就算胜。至于三百招后哪怕郭靖会输掉那也不用管了。他只要能做到接下一百招,就算通过。
思考:
我们在做软件压力测试时,往往要增加比负载测试更多的并发用户和交易,这是为什么?
3.并发测试
验证系统的并发处理能力。一般是和服务器端建立大量的并发连接,通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载,之所以把并发测试单独提出来,是因为并发测试往往涉及服务器的并发容量,以及多进程/多线程协调同步可能带来的问题。这是要特别注意,必须测试的。
4.基准测试
当软件系统中增加一个新的模块的时候,需要做基准测试,以判断新模块对整个软件系统的性能影响。按照基准测试的方法,需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准(Benchmark),然后与打开模块状态下的系统性能指标作比较,以判断模块对系统性能的影响。
5.稳定性测试
“路遥知马力”,在这里我们要说的是和性能测试有关的稳定性测试,即测试系统在一定负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的,或者说是需要时间积累才能达到能够度量的程度。为什么会需要这样的测试呢?因为有些软件的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如,内存泄漏问题就是经过一段时间积累才会慢慢变得显著,在运行初期却很难检测出来;还有客户端和服务器在负载运行一段时间后,建立了大量的连接通路,却不能有效地复用或及时释放。
6.可恢复测试
测试系统能否快速地从错误状态中恢复到正常状态。比如,在一个配有负载均衡的系统中,主机承受了压力无法正常工作后,备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。
提示:每种测试有其存在的空间和目的。当我们接手一个软件项目后,在有限的资源条件下,选择去做哪一种测试,这应该根据当前软件过程阶段和项目的本身特点来做选择。比如,在集成测试的时候要做基准测试,在软件产品每个发布点要做性能测试。
一、 IP 网络测试工具背景
1 当前网络评估与测试现状
●网络评估与测试需求广泛
(1)业务部署前的网络质量评估
(2)端到端网络性能优化与验证
(3)广域网线路质量的日常评估验证
(4)AP路由器&无线终端WIFI测试
(5)服务器网络性能测试
(6)数据中心虚拟化平台性能测试
●缺乏专业网络性能测试工具
(1)开源测试工具
性能较差;
兼容性较差。
无详细测试评估报告
(2)自研测试工具
缺乏测试公正性;
场景易受限;
兼容性较差。
2 理想的网络测试工具
(1)快速部署,高效配置
安装简易快速,无需安装额外的系统组件;
点击鼠标次数尽量少;
修改配置便利。
(2)兼容性好
适配主流的国内外操作系统;
适配主流的CPU架构。
(3)测试结果精准且一致性好
每次测试结果公差小;
不同软件版本结果差异小。
(4)详尽的统计报告
基于整体测试的概要统计结果;
可展现历史详细测试数据。
二、 IP 网络测试工具 X-Launch
1X-Launch 网络测试工具
(1)基于软件的网络及应用服务性能测试工具
双臂测试;
单臂测试。
(2)通过测试端点产生网络流量对性能进行测量
TCP、UDP、PING;
语音、视频、HTTP、FTP、MAIL、组播。
(3)测试端点软件可以快速安装部署
2X-Launch 测试部署方式
局域网公网
(1)控制端(TestConsole)
安装于Windows 7(64位);
4核CPU,8 GB内存。
150 GB硬盘
(2)测试端点(TestPoint)
软件测试端点支持Linux、Windows、Android、VxWorks、各种国产OS
3X-Launch 测试工作原理
4 灵活部署于各类终端或系统
(1)支持的OS
Windows;Linux;Android;国产OS
(2)支持的CPU架构
x86;PCPU;ARM;MIPS;Alpha;网络接口;以太网;WiFi;3G、4G、5G
(3)网络接口
以太网;WiFi;3G、4G、5G
5 具备丰富的测试业务模型
6 测试结果图表与报告
三、 X-Launch 应用场景
1 丰富的应用场景 - 无线 CPE 测试
● 无线基准性能测试;
●无线衰减测试;
●无线方向性测试;
●无线信测试;
●无线竞争测试;
●无线并发测试;
●无线远近距离测试。
2 丰富的应用场景 - 虚拟交换网络测试
(1)在虚拟化平台的VM中部署TestPoint,测试vSwitch的交换性能
(2)常见测试指标
吞吐量;时延;丢失率;乱序
3 丰富的应用场景 - 服务器网络性能测试
(1)在服务器不同类型OS中部署TestPoint实现流量环回,通过硬件仪表打流测试服务器网络性能
(2)常见测试指标
吞吐量;延迟;丢包率
4 丰富的应用场景 - 无线网络性能测试
(1)模拟真实的业务TCP、UDP、语音、HTTP等应用流量
(2)常见测试指标
吞吐量、延迟、抖动、乱序;;TCP建立时间;HTTP 首字节、末字节时间迟;语音MOS
5 丰富的应用场景 - 异地网络专线性能测试
(1)在网络端到端两头部署TestPoint,通过一对一的方式测试网络的承载指标
(2)常见测试指标
TCPUDP吞吐量;单向延迟;抖动;乱序
四、 X-Launch 成功案例
1 成功案例 - 某大 NEM 无线 CPE 测试
(1)测试挑战
国际竞争日益激烈,科技战层出不穷,在网络性能测试领域也需实现自主可控,保障整体业务的持续发展:
测试结果公差范围内;
测试配置可替换。
(2)信而泰解决方案
Windows测试控制端,测试端点支持Windows、Linux以及Android,支持下述常见测试协议:
TCP;UDP;PING;HTTP;FTP;RTSP;Voice
(3)客户收益
测试的自主可控;测试功能更新快;对需求的匹配度更高
2 成功案例 -5G 专线测试
(1)测试挑战
某医院开通电信5G专线,需进行下列测试:
5G端到端切片性能验证,可用性、健康度、丢包率、上下行带宽、延迟和抖动等;
对5G端到端切片场景进行验证大流量上下行(视频、影像);
5G端到端压力测试。
(2)信而泰解决方案
Windows测试控制端以及测试端点部署在医院网络中心机房,Android手机运行测试端点软件在医院区域内进行测试。
使用的测试协议为:
TCP_TP;UDP_STREAM
(3)客户收益
验证了5G专线在医院可用性;
验证了5G专线端到端切片性能以及使用场景;
验证专线的使用范围是否可控。
五、竞争分析
方法/步骤
打开Apache服务器的安装路径,在bin目录中有一个abexe的可执行程序,就是我们要介绍的压力测试工具。
在Windows系统的命令行下,进入abexe程序所在目录,执行abexe程序。注意直接双击无法正确运行。
执行ab命令成功后,可以看到如图提示。该帮助很清楚详细的介绍了ab的用法以及各个参数的含义。
ab 的用法是:ab [options] [http://]hostname[:port]/path
例如:ab -n 5000 -c 200 http://localhost/indexphp
上例表示总共访问http://localhost/indexphp这个脚本5000次,200并发同时执行。
ab常用参数的介绍:
-n :总共的请求执行数,缺省是1;
-c: 并发数,缺省是1;
-t:测试所进行的总时间,秒为单位,缺省50000s
-p:POST时的数据文件
-w: 以HTML表的格式输出结果
执行测试用例:ab -n 1000 -c 100 -w http://localhost/indexphp >>c:\1html
上面的测试用例表示100并发的情况下,共测试访问indexphp脚本1000次,并将测试结果保存到c:\1html文件中。
测试报告如图,可知在该100并发访问的情况下,共测试访问1000次,失败了852次。可知该脚本在此环境无法满足100并发访问的要求。
修改参数继续测试。测试并发50和30两种情况,由测试报告得知,在并发访问降到30时,错误的访问数降为39。
21 测试环境
作者使用了Tomcat作为Web服务器进行测试,被测试的内容是一个jsp文件和一个servlet,jsp文件调用JavaBean、打印相关信息,servlet接受用户参数、调用javabean、输出相关信息。详细的内容请参考作者提供的JMeterwar的内容。
22 安装启动JMeter
大家可以到通过http://apachelinuxforumnet/dist/jakarta/jmeter/binaries/jakarta-jmeter-191zip下载JMeter的release版本,然后将下载的zip文件解压缩到C:/JMeter(后面的文章中将使用%JMeter%来引用这个目录)目录下。
现在,请使用%JMeter%/bin下面的jmeterbat批处理文件来启动JMeter的可视化界面,下面的工作都将在这个可视化界面界面上进行操作。下面的是JMeter的可视化界面的屏幕截图。
图一: JMeter打开时的屏幕截图
图一: JMeter打开时的屏幕截图
23 建立测试计划(Test Plan)
测试计划描述了执行测试过程中JMeter的执行过程和步骤,一个完整的测试计划包括一个或者多个线程组(Thread Groups)、逻辑控制(Logic Controller)、实例产生控制器(Sample Generating Controllers)、侦听器(Listener)、定时器(Timer)、比较(Assertions)、配置元素(Config Elements)。打开JMeter时,它已经建立一个默认的测试计划,一个JMeter应用的实例只能建立或者打开一个测试计划。
现在我们开始填充一个测试计划的内容,这个测试计划向一个jsp文件和一个servlet发出请求,我们需要JMeter模拟五个请求者(也就是五个线程),每个请求者连续请求两次,下面的章节介绍了详细的操作步骤。
24 增加负载信息设置
这一步,我们将向测试计划中增加相关负载设置,是Jmeter知道我们需要模拟五个请求者,每个请求者在测试过程中连续请求两次。详细步骤如下:
1 选中可视化界面中左边树的Test Plan节点,单击右键,选择Add'Thread Group,界面右边将会出现他的设置信息框。
2 Thread Group有三个和负载信息相关的参数:
Number of Threads: 设置发送请求的用户数目
Ramp-up period: 每个请求发生的总时间间隔,单位是秒。比如你的请求数目是5,而这个参数是10,那么每个请求之间的间隔就是10/5,也就是2秒
Loop Count: 请求发生的重复次数,如果选择后面的forever(默认),那么 请求将一直继续,如果不选择forever,而在输入框中输入数字,那么请求将重复 指定的次数,如果输入0,那么请求将执行一次。
根据我们演示例子的设计,我们应该将Number of Threads设置为5,Ramp-up period设置为0(也就是同时并发请求),不选中forever,在Loop Count后面的输入框中输入2,设置后的屏幕截图如下:
图二:设置好参数的Thread Group。
图二:设置好参数的Thread Group。
25 增加默认Http属性(可选)
实际的测试工作往往是针对同一个服务器上Web应用展开的,所以Jmeter提供了这样一种设置, 在默认Http属性设置需要被测试服务器的相关属性,以后的http请求设置中就可以忽略这些相同参数的设置,减少设置参数录入的时间。
我们这里将采用这种属性。你可以通过下面的步骤来设置默认http属性:
1 选中可视化界面中左边树的Test Plan节点,单击右键,选择Add'config element'http request defaults,界面右边将会出现他的设置信息框。
2 默认http属性的主要参数说明如下:
protocal:发送测试请求时使用的协议
server name or ip:被测试服务器的ip地址或者名字
path: 默认的起始位置。比如将path设置为/jmeter,那么所有的http请求的url中都将增加/jmeter路径。
port number: 服务器提供服务的端口号
我们的测试计划将针对本机的Web服务器上的Web应用进行测试,所以protocal应该是http,ip使用localhost,因为这个web应用发布的context路径是/jmeter,所以这里的path设置为/jmeter,因为使用Tomcat服务器,所以port number是8080。设置后的屏幕截图如下:
图三: 测试计划中使用的默认Http参数
图三: 测试计划中使用的默认Http参数
26 增加Http请求
现在我们需要增加http请求了,他也是我们测试的内容主体部分。你可以通过下面的步骤来增加性的http请求:
1 选中可视化界面中左边树的Thread Group节点,单击右键,选择Add'sampler'http request,界面右边将会出现他的设置信息框。
2 他的参数和25中介绍的http属性差不多,增加的属性中有发送http时方法的选择,你可以选择为get或者post。
我们现在增加两个http 请求,因为我们设置了默认的http属性,所以和默认http属性中相同的属性不再重复设置。设置后的屏幕截图如下:
图四:设置好的jsp测试请求
图四:设置好的jsp测试请求
图五:设置好的Servlet测试请求(带参数)
图五:设置好的Servlet测试请求(带参数)
27 增加Listener
增加listener是为了记录测试信息并且可以使用Jmeter提供的可视化界面查看测试结果,里面有好几种结果分析方式可供选择,你可以根据自己习惯的分析方式选择不同的结果显示方式,我们这里使用表格的形式来查看和分析测试结果。你可以通过下面的步骤来增加listener:
1 选中可视化界面中左边树的Test Plan节点,单击右键,选择Add'listener'view result in table,界面右边将会出现他的设置信息和结果显示框。
2 你可以设置界面上面的filename属性设置将测试结果保存到某个文件中 界面下面将使用表格显示测试结果,表格的第一列sampleno显示请求执行的顺序和编号,url显示请求发送的目标,sample-ms列显示这个请求完成耗费的时间,最后的success列显示改请求是否成功执行。
界面的最下面你还可以看到一些统计信息,最关心的应该是Average吧,也就是相应的平均时间。
28 开始执行测试计划
现在你可以通过单击菜单栏run -> Start开始执行测试计划了。下面这两个图是作者第一次、第二次执行该测试计划的结果图:
大家可以看到第一次执行时的几个大时间值均来自于jsp request,这可以通过下面的理由进行解释:jsp执行前都需要被编译成class文件。所以第二次的结果才是正常的结果。
0条评论