测试系统：公司网站的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等等，仅仅看返回结果是不准确的，要把这些因素综合考虑，并且当并发和请求数太多客户机的性能也要考虑进去