(完整版)网站压力测试报告
(完整版)网站压力测试报告

xxxxxxx网站压力测试报告文档修订记录目录一、测试内容 (4)二、测试方法 (4)三、测试目标 (4)四、测试环境 (4)1、系统环境配置 (4)1.1 1cpu 4GB内存: (5)1.2 4cpu 4GB内存: (5)2、测试客户端配置 (5)3、网络环境 (5)4、测试时间 (5)五、系统部署 (6)六、测试说明 (6)七、测试统计及分析 (6)1. 1cpu 4GB内存压测统计 (6)2. 4cpu 4GB内存压测统计 (10)八、结果: (14)1. 1cpu 4GB内存压测: (14)2. 4cpu 4GB内存: (15)九、结论及建议: (15)1.结论: (15)1.1 1cpu 4GB内存压测: (15)1.2 4cpu 4GB内存压测: (15)2. 建议: (16)一、测试内容本次测试是针对《xxxxx》网站进行的压力测试,本次压测主要提取用户最常浏览的页面进行压测:访问首页+新闻动态的场景进行压测。
二、测试方法1.本次采用apache的开源测试工具jmeter,采用badboy录制脚本生成http请求脚本,并通过http协议get方式发送访问请求,收集服务器响应速度,服务器资源耗用情况。
2、安装启动JMeter,分别对以上页面进行压力测试分别测试10、50、100、500个线程,即模拟这些数目的用户并发; Ramp-up period(inseconds)的值设为1(即1s启动10、50、100、500并发访问),并发持续运行为10分钟;。
三、测试目标CPU增加到4核,是否可以达到预期并发数500个。
四、测试环境1、系统环境配置测试分为2轮进行压测,服务器配置有2种:1.1 1cpu 4GB内存:1.2 4cpu 4GB内存:2、测试客户端配置3、网络环境本次测试是在局域网中进行的测试,暂不会对压测造成瓶颈,该方面影响可以忽略。
4、测试时间五、系统部署系统已经经过开发人员部署在xxx这台机子上,无需另外再次进行系统部署。
web压力测试实验报告

软件测试实验报告班级: 030513学号: 03051235姓名:陆义良地点: EⅡ- 508时间: 2008年5月16日实验目的:一、理解web压力测试概念二、熟练运用WAS (web application stress tool)软件进行web 压力测试实验内容:一、WAS软件安装二、设计测试方案三、使用WAS软件进行测试四、分析测试报告,寻找被测网站的最大负载量实验设备:一、WAS软件二、联网的计算机脚本报告:脚本1报告:Overview======================================================================Report name: 2008-5-16 16:01:08Run on: 2008-5-16 16:01:08Run length: 00:24:13Web Application Stress Tool Version:1.1.293.1Number of test clients: 1Number of hits: 11899Requests per Second: 9.01Socket Statistics--------------------------------------------------------------------------------Socket Connects: 12310Total Bytes Sent (in KB): 3323.06Bytes Sent Rate (in KB/s): 2.52Total Bytes Recv (in KB): 105140.76Bytes Recv Rate (in KB/s): 79.65Socket Errors--------------------------------------------------------------------------------Connect: 49332Send: 0Recv: 46Timeouts: 20RDS Results--------------------------------------------------------------------------------Successful Queries: 0Script Settings======================================================================Server: 192.168.1.8Number of threads: 500Test length: 00:22:00Warmup: 00:01:00Cooldown: 00:01:00Use Random Delay: NoFollow Redirects: YesMax Redirect Depth: 15Clients used in test======================================================================localhostClients not used in testResult CodesCode Description Count======================================================================200 OK 11897NA HTTP result code not given 2Page SummaryPage Hits TTFB Avg TTLB Avg Auth Query ======================================================================GET / 5955 11184.14 12031.11 No No GET /tanchu.html 5944 21075.57 21101.67 No No脚本2 报告:Overview======================================================================Report name: 2008-5-16 16:34:24Run on: 2008-5-16 16:34:24Run length: 00:22:12Web Application Stress Tool Version:1.1.293.1Number of test clients: 1Number of hits: 123235Requests per Second: 102.69Socket Statistics--------------------------------------------------------------------------------Socket Connects: 123283Total Bytes Sent (in KB): 33261.82Bytes Sent Rate (in KB/s): 27.72Total Bytes Recv (in KB): 813014.92Bytes Recv Rate (in KB/s): 677.49Socket Errors--------------------------------------------------------------------------------Connect: 3426Send: 0Recv: 17819Timeouts: 0RDS Results--------------------------------------------------------------------------------Successful Queries: 0Script Settings======================================================================Server: 192.168.1.8Number of threads: 500Test length: 00:20:00Warmup: 00:01:00Cooldown: 00:01:00Use Random Delay: NoFollow Redirects: YesMax Redirect Depth: 15Clients used in test======================================================================localhostClients not used in testResult CodesCode Description Count======================================================================200 OK 105414500 Internal Server Error 2NA HTTP result code not given 17819Page SummaryPage Hits TTFB Avg TTLB Avg Auth Query======================================================================GET / 61879 2889.35 4694.87 No No GET /tanchu.html 61356 2469.93 4104.67 No No脚本3 报告:Overview======================================================================Report name: 2008-5-16 17:06:21Run on: 2008-5-16 17:06:21Run length: 00:22:07Web Application Stress Tool Version:1.1.293.1Number of test clients: 1Number of hits: 67632Requests per Second: 56.36Socket Statistics--------------------------------------------------------------------------------Socket Connects: 67585Total Bytes Sent (in KB): 14846.30Bytes Sent Rate (in KB/s): 12.37Total Bytes Recv (in KB): 982958.80Bytes Recv Rate (in KB/s): 819.10Socket Errors--------------------------------------------------------------------------------Connect: 15995Send: 0Recv: 170Timeouts: 0RDS Results--------------------------------------------------------------------------------Successful Queries: 0Script Settings======================================================================Server: 192.168.1.8Number of threads: 500Test length: 00:20:00Warmup: 00:01:00Cooldown: 00:01:00Use Random Delay: NoFollow Redirects: YesMax Redirect Depth: 15Clients used in test======================================================================localhostClients not used in test======================================================================Result CodesCode Description Count======================================================================200 OK 67462NA HTTP result code not given 170Page SummaryPage Hits TTFB Avg TTLB Avg Auth Query ======================================================================GET / 11267 4145.78 7793.87 No No GET /tanchu.html 11257 3815.91 7094.71 No No GET /xuanke.html 11293 3794.80 7555.34 No No GET /guizhang.html 11292 3580.07 7338.23 No No GET /chengguo.html 11270 3804.97 7283.22 No NoGET /ziyuanxiazai.html 11253 3663.53 7382.60 No No 附录:脚本3截图心得体会:进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。
压力测试报告

压⼒测试报告压⼒测试报告在beta阶段尾声时,我们对⽹站进⾏了⼀次压⼒测试。
同时我们也对alpha发布以及去年的产品做了同样的测试进⾏对⽐。
测试代码可以参考我们上⼀篇测试⼯具介绍的博客。
测试环境与项⽬我们使⽤了⼀台vultr服务器进⾏测试,配置为1c/1G RAM+1G swap/1Tbps/LA,与⽣产环境相同,测试时间为凌晨2点左右,确保尽量不影响正常⽤户以及性能瓶颈不在测试服务器上。
测试环境与⽣产环境相对独⽴,是当时⽣产环境的快照,确保⽤户资料的安全性。
在测试时我们临时禁⽤了CSRF,CROS,IP访问限制以及CDN。
我们做了以下测试,测试了去年的⽹站以及alpha(被攻击修改后),beta阶段的⽹站:编号内容⽬的1使⽤siege,并发发起1000个请求,访问⾸页。
测试⽹站的并发处理能⼒2使⽤siege和⾃⼰的脚本,并发发起1000个请求,访问获取评分接⼝。
测试⽹站缓存及⾼资源占⽤接⼝处理能⼒3使⽤⾃⼰的脚本,持续10秒,每秒发起200个请求,访问搜索课程接⼝测试长时间较⼤压⼒的情况(有缓存)4使⽤⾃⼰的脚本,发起1000个请求,向“数据库技术基础”课程评论评分数据库压⼒测试5使⽤⾃⼰的脚本,发起2000个请求,随机访问搜索页⾯,记录执⾏时间,成功率综合测试数据库,缓存,⽹站⾃⼰的测试程序基本结构如下:import requestsimport threadingimport timeclass thread1(threading.Thread):count200=0count502=0count504=0count500=0countelse=0def __init__(self, threadID, name):threading.Thread.__init__(self)self.threadID = threadID = namedef run(self):time.sleep(15)a = requests.get(TEST_URL)code = a.status_codeelse:passif int(code)==200:thread1.count200+=1elif int(code)==502:thread1.count502+=1elif int(code)==504:thread1.count504+=1elif int(code)==500:thread1.count500+=1else:print(code)thread1.countelse+=1if __name__=="__main__":Truethreads=[]for i in range(2000):thread=thread1(i, "Thread-{}".format(i))threads.append(thread)a=time.time()for i in threads:i.start()time.sleep(0.005)time.sleep(50)print(thread1.count200,thread1.count502,thread1.count504,thread1.count500,thread1.countelse)测试结果测试1阶段成功次数成功率去年18618.6%alpha1000100%beta99899.8%我们认为有两次请求未成功可能是误差,alpha与beta阶段在主页代码与缓存逻辑上未做⼤量修改。
压力测试总结(合集5篇)

压力测试总结第1篇直接上公式不太好理解,我们先看案例案例1:秒杀型算法案例的业务量要求某业务,类似秒杀型,用户估算有2W左右,每个用户平均请求2次接口(查询用户信息接口、查询业务接口),这些用户大概率会在2分钟内会访问我们的系统,业务要保证用户2s能打开页面TPS的分析TPS是系统每秒钟处理的任务数量,给定二业务场景,我们就需要先计算出来每秒需要系统处理多少任务,从而反推在压力测试的时候,需要给多大的TPS了。
首先,整个系统的总请求数=用户(2W)* 每个用户请求数(2次)= 40000次其次,每秒要求处理的请求数=总请求数/时间(切换到秒)即约350(333向上取个整吧)。
最后,TPS并发数量与每个请求所消耗的时间,可实际计算出每秒实际能够处理的请求数。
即每秒实际处理请求数量=tps数量 *1000【1秒,需要切换为毫秒】/单组tps处理时间【这里是按200ms返回】因此,我们只要保证每秒实际处理请求数>每秒要求处理的请求数就可以了。
最终结果就是: TPS数量 > 每秒要求处理的请求数 *tps返回时间【按200ms计算】/1000ms 带入数据计算 tps>(350 *200)/1000,具体tps>70。
因此可让压力测试人员按照tps100来压接口,返回在200ms以内就满足性能要求。
当然如果实际tps50的返回时间为100ms,则按照这个粗略的公式来推算,也是能够支撑的(350 * 100/1000=35,也就是说tps高于35,返回100ms以内也是可以的)案例2:一个日常服务的算法如:一个100w访问的服务,每天访问集中白天8小时,每个用户大约会请求3个接口,每天早上9点是峰值。
首先计算日均请求数(每秒);按8小时 100w访问量、平均3个接口请求计算;每秒日均请求数=100w(访问量)*3(每个访问量平均请求接口数)/8(小时)/3600(切换成秒),结果就是每秒请求10 0次。
网站压力测试报告怎么写范文

网站压力测试报告怎么写范文随着互联网的快速发展,网站已经成为现代社会的重要组成部分。
然而,随着用户数量的增加和访问流量的不断增长,网站的性能和稳定性问题也逐渐浮出水面。
为了保证网站的正常运行,确保用户的良好体验,压力测试成为了不可或缺的一环。
本文旨在介绍网站压力测试报告的写作方法和要点。
一、报告的基本结构一个完整的网站压力测试报告应包括以下几个部分:1. 测试目的和背景:简单介绍进行压力测试的原因和目的,明确测试的范围和对象。
2. 测试环境和工具:详细描述进行压力测试时使用的硬件环境、软件环境和测试工具。
这些信息有助于读者了解测试的可靠性和客观性。
3. 测试准备:介绍测试前的准备工作,包括测试用例的设计、数据准备、网络配置等。
4. 测试执行:具体描述测试过程中采取的步骤和操作,以及记录的测试结果和数据。
5. 结果分析和评估:对测试结果进行详细分析,包括性能指标、响应时间、负载能力等方面的评估。
6. 问题发现和解决:列出测试过程中发现的问题和异常,并给出相应的解决方案和优化建议。
7. 结论和建议:总结测试的目标是否达到,并给出进一步改进网站性能的建议。
二、报告的写作要点在撰写网站压力测试报告时,需要注意以下几个关键要点:1. 简洁明了:报告内容应简洁明了,避免过多的技术术语和复杂的数据分析。
尽量使用清晰简练的语言,使读者能够迅速理解并得出结论。
2. 数据详实:测试数据是报告的重要组成部分,应尽量详细准确地记录。
包括测试时间、测试结果、负载情况等信息,便于结果的分析和后续的优化工作。
3. 结果分析重点突出:过多的数据和信息会让读者感到混乱,因此在结果分析中应注重突出重点。
选择一些关键指标进行分析和解读,使读者能够直观地了解网站的性能表现。
4. 问题解决方法:发现问题是测试的重要目的之一,因此在报告中应详细列出测试过程中的问题和异常。
同时,给出相应的解决方案和优化建议,便于网站管理员进行问题的修复和性能的提升。
XXXXXX网站平台压力测试报告-NEW.doc资料

XXXXXX网站平台压力测试报告XXXXXX科技有限公司2013-11-251.测试项目1.1功能描述:XXXXXXXX网站平台压力测试是XXXXXX科技有限公司对XXXXXXXX网站平台服务器进行性能测试手段,通过模拟大批量用户的并发访问操作,从而可以预测系统在大量用户并发发访问操作的情况下,系统可以响应的时间及服务器资源占用等性能情况。
本文主要描述了对服务器进行性能压力测试的过程及结果。
本次测试主要关心的指标:●平均响应时间●总用时●服务器CPU利用率●内存占用等。
1.2系统压力强度估算系统响应时间判断原则如下:➢系统业务响应时间小于2-5秒,判为优秀,用户对系统感觉很好;➢系统业务响应时间在5-10秒之间,判为良好,用户对系统感觉一般;➢系统业务响应时间超过15秒,判断为一般,用户体验不佳。
2.测试环境:2.1 服务器端测试环境描述:硬件配置:(例如HP LXr 8500 Server双PIIIXeon/900 (2MB Cache)、4GB内存、2个36GB硬盘、磁带机、双网卡)软件配置:(例如Windows 2003 Server、Oracle10g、IIS5.1、.NET FRAMEWORK2.0等)2.2 客户端测试环境描述:DELL A840商务笔记本CPU:T1400 频率1.73GHz双核处理器内存:2G硬盘:120G计算机版本:WindowsXP SP32.3 网络测试环境描述:服务器和客户端用的是10M网络带宽。
3.测试工具微软Microsoft Web Application Stress Tool 1.1(W AS)主要思想是使用虚拟用户(Virtual users)来模拟实际用户对系统施加压力。
模拟图如下:Stress Level(threads)线程数:100Stress multiplier(sockets per)每个线程可以产生多少个请求:10 注:线程数乘以请求数等于并发数测试时间(Test Run Time):1分钟停止响应时间(Requst Delay):最小20 最大404.测试案例的测试结果:5000用户并发访问网站,正常。
Web压力实验报告

一、实验目的。
1、了解WAS(Microsoft的Web Application Stress Tool)服务器负载测试软件。
2、理解web压力测试概念。
3、熟练运用WAS软件进行web压力测试。
二、实验内容。
1、通过WAS软件使200个用户对一个网站或网页进行压力测试。
三、实验过程。
1、建立新脚本。
启动WAS软件后点击[new script]按钮。
2、编辑脚本内容。
1、在选择脚本名称的右侧会出现相应的设置[server]中输入要进行测试的服务器IP地址或计算机名称;[verb]中选择脚本运行方式 get、post、head;[path]中输入向服务器提交的文件或字符串。
2、在settings的功能设置中,需要设置多少轰炸的线程数,本次实验需要对200个用户进行压力测试,故而在“Stress Level”中填写100,在Stress Multiplier中填写2,基本公式为:用户数(线程数)= Stress Level * Stress Multiplier。
Stress Level 和Stress multiplier这二个项决定了访问服务器的并发连接的数量。
Microsoft建议不要选择超过100的Stress Level值。
如果要模拟的并发连接数量超过100个,可以调整Stress multiplier或使用多个客户机。
在负载测试期间WAS将通过DCOM与其他客户机协调。
3、在“Test Run Time”中来指定一次压力测试需要持续的时间,分为天、小时、分、秒几个单位级别。
4、创建新用户。
1.在左边窗口展开脚本的信息 2.点Users 节点在右边窗口打开相应的视图 3.双击Default 用户组打开用户视图。
注意默认已经创建了200个用户。
你可以简单地修改用户名和密码就行了。
5、检查一下报表的Result Codes部分。
这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。
压力测试分析报告范文

压力测试分析报告范文一、引言压力测试是一种常用的软件测试方法,它通过模拟多种负载条件,来评估系统在实际使用中的性能表现。
本报告主要对某在线购物网站进行了压力测试,并对测试结果进行了分析和总结,以便提供决策参考。
本报告包括测试目的、测试环境、测试方案、测试过程、测试结果和结论等内容。
二、测试目的通过压力测试,我们的目的是评估该在线购物网站在高负载条件下的性能表现,包括服务器响应时间、并发用户数、系统稳定性等指标。
同时,我们希望发现系统的瓶颈,以便对系统进行优化和改进。
三、测试环境本次压力测试使用以下环境:1. 测试工具:使用Apache JMeter作为压力测试工具,模拟大量并发用户访问系统。
2. 测试服务器:使用一台高性能服务器作为被测系统的服务器,配置为8核、16GB内存。
3. 网络环境:使用100Mbps的局域网环境。
四、测试方案本次压力测试的测试方案如下:1. 测试场景:选择了系统中的核心功能,如用户登录、商品搜索、下单支付等,以模拟用户在真实场景下的操作行为。
2. 测试用例设计:根据用户的实际使用情况,设计了多个场景,包括正常情况下的用户操作、高峰期的用户访问、异常情况下的操作等。
3. 性能指标定义:对于每个测试用例,我们定义了一些性能指标,如服务器响应时间、并发用户数、系统吞吐量等。
4. 负载配置:根据实际情况,设置了不同的并发用户数,并逐步增加负载,直到达到系统的极限。
五、测试过程根据测试方案,我们进行了以下几个阶段的测试:1. 单用户性能测试:首先,我们模拟了单个用户对系统进行操作,记录了响应时间、系统资源占用情况等数据。
2. 并发用户测试:逐渐增加并发用户数,观察系统在不同负载下的表现。
记录了响应时间、错误率、并发用户数等指标。
3. 峰值测试:将并发用户数逐步增加到系统能够承受的极限,观察系统的表现,以及各项指标的变化情况。
六、测试结果分析根据测试过程中收集的数据,我们对测试结果进行了分析,主要包括以下几个方面:1. 响应时间分析:我们发现,在并发用户数较少的情况下,系统的响应时间较短,用户体验较好。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
xxxxxxx网站压力测试报告
文档修订记录
目录
一、测试内容 (4)
二、测试方法 (4)
三、测试目标 (4)
四、测试环境 (4)
1、系统环境配置 (4)
1.1 1cpu 4GB内存: (5)
1.2 4cpu 4GB内存: (5)
2、测试客户端配置 (5)
3、网络环境 (5)
4、测试时间 (5)
五、系统部署 (6)
六、测试说明 (6)
七、测试统计及分析 (6)
1. 1cpu 4GB内存压测统计 (6)
2. 4cpu 4GB内存压测统计 (10)
八、结果: (14)
1. 1cpu 4GB内存压测: (14)
2. 4cpu 4GB内存: (15)
九、结论及建议: (15)
1.结论: (15)
1.1 1cpu 4GB内存压测: (15)
1.2 4cpu 4GB内存压测: (15)
2. 建议: (16)
一、测试内容
本次测试是针对《xxxxx》网站进行的压力测试,本次压测主要提取用户最常浏览的页面进行压测:访问首页+新闻动态的场景进行压测。
二、测试方法
1.本次采用apache的开源测试工具jmeter,采用badboy录制脚本生成http请求脚本,并通过http协议get方式发送访问请求,收集服务器响应速度,服务器资源耗用情况。
2、安装启动JMeter,分别对以上页面进行压力测试分别测试10、50、100、500个线程,即模拟这些数目的用户并发; Ramp-up period(inseconds)的值设为1(即1s启动10、50、100、500并发访问),并发持续运行为10分钟;。
三、测试目标
CPU增加到4核,是否可以达到预期并发数500个。
四、测试环境
1、系统环境配置
测试分为2轮进行压测,服务器配置有2种:
1.1 1cpu 4GB内存:
1.2 4cpu 4GB内存:
2、测试客户端配置
3、网络环境
本次测试是在局域网中进行的测试,暂不会对压测造成瓶颈,该方面影响可以忽略。
4、测试时间
五、系统部署
系统已经经过开发人员部署在xxx这台机子上,无需另外再次进行系统部署。
访问网址:xxx
六、测试说明
名词定义(时间的单位均为ms):
Samples -- 本次场景中一共完成了多少个线程
Average -- 平均响应时间
Median -- 统计意义上面的响应时间的中值
90% Line -- 所有线程中90%的线程的响应时间都小于xx
Min -- 最小响应时间
Max -- 最大响应时间
Error -- 出错率
Troughput -- 吞吐量
七、测试统计及分析
压测场景:
1.输入网址:xxx(打开首页);
2.点击新闻动态“xxx成立!”(打开新闻动态);
1. 1cpu 4GB内存压测统计
1)10个线程组并发
●聚合报告
并发10个用户,持续运行10分钟,完成9920次访问请求,最小响应速度为0.097秒,最大为0.914秒,平均响应速度为0.168秒,与预期的3秒还快,访问成功率100%,符合预期的需求。
●系统资源耗用
从10:01开始压测,cpu(%Processor Time)使用率急剧上升到了100%,然后持续运行10分钟10:11结束,cpu使用率一直几乎都在100%,与预期的小于75%不相符;可用物理内存(Available MBytes)一直维持在2900MB左右,内存使用率29%左右,与预期小于70%,总体不符合预期需求。
2)50个线程组并发
●聚合报告
并发50个用户,持续运行10分钟,完成10108次访问请求,平均响应速度为0.714秒,与预期的3秒还快,访问成功率100%,符合预期的需求。
●系统资源耗用
从10:37开始压测,cpu(%Processor Time)使用率急剧上升到了100%,然后持续运行10分钟10:47结束,cpu使用率一直几乎都在100%,与预期的小于75%不相符;可用物理内存(Available MBytes)一直维持在2900MB左右,内存使用率29%左右,与预期小于70%,总体不符合预期需求。
3)100个线程组并发
●聚合报告
并发100个用户,持续运行10分钟,完成10130次访问请求,平均响应速度为1.799秒,与预期的3秒还快,访问成功率100%,符合预期的需求。
●系统资源耗用
从10:50开始压测,cpu(%Processor Time)使用率急剧上升到了100%,然后持续运行10分钟11:00结束,cpu使用率一直几乎都在100%,与预期的小于75%不相符;可用物理内存(Available MBytes)一直维持在2900MB左右,内存使用率29%左右,与预期小于70%,总体不符合预期需求。
4)500个线程组并发
●聚合报告
并发500个用户,持续运行10分钟,完成10512次访问请求,平均响应速度为8.06秒,与预期的3秒慢很多,访问成功率100%,总体不符合预期的需求。
●系统资源耗用
从11:01开始压测,cpu(%Processor Time)使用率急剧上升到了100%,然后持续运行10分钟11:11结束,cpu使用率一直几乎都在100%,与预期的小于75%不相符;可用物理内存(Available MBytes)一直维持在2900MB左右,内存使用率29%左右,与预期小于70%,总体不符合预期需求。
2. 4cpu 4GB内存压测统计
1)10个线程组并发
●聚合报告
并发10个用户,持续运行10分钟,访问新闻完成2201次访问请求,最小响应速度为0.018秒,最大为0.102秒,平均响应速度为0.026秒,与预期的5秒还快,访问成功率100%,符合预期的需求。
●系统资源耗用
从11:39开始压测,持续运行10分钟11:49结束,cpu(%Processor Time)使用率维持在30%以下,小于预期75%使用率;可用物理内存(Available MBytes)一直维持在2400MB左右,内存使用率42%左右,与预期小于70%,总体符合预期需求。
2)50个线程组并发
●聚合报告
并发50个用户,持续运行10分钟,访问新闻完成9750次访问请求,最小响应速度为0.019秒,最大为0.373秒,平均响应速度为0.028秒,与预期的5秒还快,访问成功率100%,符合预期的需求。
●系统资源耗用
从12:27开始压测,持续运行10分钟12:37结束,cpu(%Processor Time)使用率维持在60%以下,小于预期75%使用率;可用物理内存(Available MBytes)一直维持在2400MB左右,内存使用率42%左右,与预期小于70%,总体符合预期需求。
3)100个线程组并发
●聚合报告
并发100个用户,持续运行10分钟,访问新闻完成18738次访问请求,最小响应速度为0.018秒,最大为0.42秒,平均响应速度为0.033秒,与预期的5秒还快,访问成功率100%,符合预期的需求。
●系统资源耗用
从13:32开始压测,持续运行10分钟13:42结束,cpu(%Processor Time)使用率主要维持在60%-80%之间,与预期小于75%使用率对比略显偏高;可用物理内存(Available MBytes)一直维持在2400MB左右,内存使用率42%左右,与预期小于70%,总体CPU略显不足。
4)500个线程组并发
●聚合报告
并发100个用户,持续运行10分钟,访问新闻完成18738次访问请求,最小响应速度为0.018秒,最大为0.42秒,平均响应速度为0.033秒,与预期的5秒还快,访问成功率100%,符合预期的需求。
●系统资源耗用
从13:46开始压测,持续运行10分钟13:562结束,cpu(%Processor Time)使用率主要在90%以上,与预期<75%使用率对比,cpu存在不足;可用物理内存(Available MBytes)一直维持在2400MB左右,内存使用率42%左右,与预期小于70%,总体上CPU明显存在瓶颈。
针对访问新闻动态统计(4cpu 4GB内存)
八、结果:
1. 1cpu 4GB内存压测:
2. 4cpu 4GB内存:
九、结论及建议:
1.结论:
1.1 1cpu 4GB内存压测:
当压测开始发现硬件CPU存在严重的不足,并发数增加到了500个,服务器的平均响应速度变得很慢8.06秒,达不到预期的目标小于5秒;cpu是个瓶颈。
1.2 4cpu 4GB内存压测:
500个并发时,发现硬件CPU还是存在不足,当并发数增加到了500个,服务器的平均相应
速度1.105秒,符合预期的目标值小于5秒,但是CPU使用率高于90%,如果要想维持相对稳定的系统,CPU是个瓶颈;本次压测并未发现内存存在瓶颈。
2. 建议:
要达到500的并发,建议将CPU数量增加到16核,方可维持网站服务器的相对稳定,目前硬件配置为 4CPU,4GB内存。