一份cf的性能测试报告
本次测试包含: httpd接口请求测试、httpc请求测试、template模板渲染测试、DB查询测试.
为了减少大量无关数据造成阅读的影响, 整理数据为table格式方便查阅与阅读.
测试环境
数据名称 | 数据值 |
---|---|
测试人 | Candymi |
测试时间 | 2019/06/05 |
操作系统 | Mac OSX |
CPU | Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz |
内存 | 16 GB 1867 MHz DDR3 |
Lua | 5.3.5 |
编译器 | Apple LLVM version 10.0.1(clang-1001.0.46.4) |
对操作系统仅作如下设置:
- # 快速链接回收.
- [root@~]: sudo sysctl -a net.inet.tcp.msl=100;
- # 连接队列
- [root@~]: sudo sysctl -a kern.ipc.somaxconn=10240
- # 文件描述符限制.
- [root@~]: ulimit -n 10240;
测试数据结果
1. httpd库注册接口请求测试
测试目的: echo测试httpd框架性能
测试接口: /view(返回HTML语法字符串)
测试命令: ab -c 客户端数量 -n 请求次数 -k 开启keepalive http://localhost:8080/view
数据选取方式: 测试次数为5次、取最高值与最低值、忽略小数点位.
客户端数量(client) | 请求次数(times) | 延迟(time) | 并发量(concurrency) | 网卡包收发率(packet) | CPU占用(%) |
---|---|---|---|---|---|
100 | 100000 | 7~46 | >= 11000 | 32000~35000 | >=90 |
200 | 100000 | 16~70 | >= 11000 | 32000~35000 | >=90 |
500 | 100000 | 42~120 | >= 11000 | 32000~35000 | >=90 |
800 | 100000 | 70~140 | >= 11000 | 32000~35000 | >=90 |
1000 | 100000 | 86~270 | >= 11000 | 40000~45000 | >=90 |
2000 | 100000 | 165~470 | >= 11000 | 50000~53000 | >=90 |
5000 | 100000 | 408~550 | >= 11000 | 62000~64000 | >=90 |
2. 业务逻辑测试
2.1 admin登录页
测试接口: /admin
测试目的: 测试纯HTML静态页面使用template模板渲染在/开启/关闭Cache与keepalive之间性能差异.
测试方法: 固定500客户端, 10万请求次数.
cache与keepalive(off) | keepalive(only) | cache(only) | keepalive与cache(on) |
---|---|---|---|
1400~1700 | 2030~2230 | 4238~6000 | 7400~8500 |
2.2 admin仪表盘
测试接口: /admin/dashboard, DB库设置最大连接池数量, MySQL数据库设置(SET GLOBAL max_connections=2000
)
测试目的: admin库最为复杂的业务查询逻辑, 包含验权、跳转、业务实现、模板渲染等等.
测试方法: 不同数据库连接池数量对并发量造成的影响.
连接池数量 | 延迟分布(ms) | cache与keepalive(off) | keepalive(only) | keepalive与cache(on) |
---|---|---|---|---|
100 | 800~1313 | 300~500 | 400~500 | ~500 |
500 | 500~1100 | 400~500 | 400~500 | ~500 |
1000 | 211~620 | 400~500 | 400~500 | ~500 |
这里需要说明的是:
admin库没有特意针对高并发的场景做特殊优化, 但即是这样的情况也能满足需要性能支撑的场景。
admin库由于业务需要需要做多维度验权、数据查询等工作, 也间接导致做的优化工作不会有几个数量级的并发提升.
admin库更专注的是优化用户体验, 使用者合理设置连接池大小有助于降低请求延迟.
3. httpc库请求测试
测试准备: /api接口, 可参考script/test_httpc.lua
文件.
测试目的: 测试httpc库在不同请求状态下的延迟数据
测试方法: 启动3个定时器运行测试用例针对/api接口进行真实请求测试(普通httpc请求, 连接复用httpc请求, 同步非阻塞多接口请求)
普通请求耗时 | 连接复用请求耗时 | 多接口请求耗时 |
---|---|---|
1.2/Sec | 1.0/Sec | 0.2/Sec |
每种httpc都有不同的使用方式与使用场景:
普通httpc请求适用于每个连接只请求一次的场景或多个接口不同域名的负责使用场景.
httpc class适用于当前接口仅需要对一个第三方后端进行数据重复获取(减少建立TCP连接造成的消耗).
multi_request适用于多个接口(不限后端)无数据相关性, 一个获取所有接口返回数据的场景.
优点
cf框架提供了异步的stdout日志输出方案, 提供日志打印的同时平衡并发性能.
cf框架提供了诸如: 自动化调度协程、定时器等库, 异步事件处理更加简单高效.
cf框架提供了一套web开发框架, 仅单论其单核心的强劲并发性能就远远超过市场上大部分产品.
cf框架集成了丰富的第三方库并维护着一些常见的客户端协议(redis、mysql、smtp、mq)等等.