qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

一次完整的性能测试

测试工具:http_load,tsar
  测试系统:公司网站的beta环境,本次测试数据有大约9万条数据。系统的架构为lamp+nginx,数据的流向,从mysql数据库 做一个dumper 每10分钟dump一次数据到系统的引擎。引擎是提供给用户垂直搜索的数据集合。
  测试数据来源:收集线上访问的日志,并做相关的参数化。
  测试步骤:
  1.准备相关测试工具,这里采用http_load ,测试命令sudo http_load -f 1000 -p 10  url.txt
  2.准备测数据,目前该工具只支持get的请求,收集引擎服务器上的访问log 作为url,注意收集的 url 非常重要 他关系这个本次测试是否有效 ,最好收集 线上服务器的一个小时内的访问log 做修改和参数化
  3.新旧版本对比测试,跑数据 -f 1000 -p 10 ; -f 2000 -p 20 ; -f 3000 -p 30; -f 5000 -p 50 ;-f 10000 -p 100 .每组数据跑三次 取平均的结果,当然跑多次取平均最好。
2000 fetches, 20 max parallel, 9.63347e+07 bytes, in 89.0738 seconds
48167.3 mean bytes/connection
22.4533 fetches/sec, 1.08152e+06 bytes/sec
msecs/connect: 0.250249 mean, 0.763 max, 0 min
msecs/first-response: 874.104 mean, 4883.77 max, 3.489 min
33 bad byte counts
HTTP response codes:
code 200 -- 1952
code 400 -- 1
code 500 -- 47
  4.结果分析:
  22.4533 fetches/sec  --这个是qps 业务处理能力
  HTTP response codes  --这个是记录访问成功和失败的url数据
  一般来说 同样的压力下 ,qps越高,代表业务处理能力越好性能越好,返回200 越多越好,如果qps相同 但是404,或者5000比较多,就要考虑是不是系统有性能瓶颈
  5.补充 :一般好要监控 服务的性能指标load数和cpu等等,仅仅看返回结果是不准确的,要把这些因素综合考虑,并且当并发和请求数太多客户机的性能也要考虑进去

posted on 2014-04-10 10:37 顺其自然EVO 阅读(778) 评论(0)  编辑  收藏 所属分类: 性能测试


只有注册用户登录后才能发表评论。


网站导航:
 
<2019年12月>
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜