FastAdmin EasySwoole速度测试对比。
接口调用：检查新消息
EasySwoole下的服务接口：http://192.168.0.128:8001/UserChat/msgCheck
EasySwoole下的登录接口：http://192.168.0.128:8002/Index/test_login
FastAdmin下的应用接口：http://192.168.0.128:9001/api/Legal/msgCheck
应用接口内部用Guuzle两次调用服务接口，一次调验证，一次调数据
服务器配置：1C2G，并发级别 100 请求3000
| 调用方式 | 接口 | 耗时(s) | 并发度 | 推荐度 |
|---|---|---|---|---|
| 直接 | 应用接口 | 93 | 33 | 3 |
| 原生Guzzle | 服务接口 | 15 | 200 | 1 |
| 直接 | 服务接口 | 2.5 | 1200 | 6 |
| EasySwoole下Guzzle | 服务接口 | 5.4 | 555 | 6 |
| EasySwoole下SwooleHttpClient | 服务接口 | 3.2 | 950 | 8 |
| EasySwoole下OauthClient | 登录接口 | 7.5 | 400 | 6 |
综合来看，EasySwoole下SwooleHttpClient去调EasySwoole下的接口是最快的。
下一步拆分计划
- 原EasySwoole服务依旧独立
- 另建EasySwoole服务用于应用层接口
- 定时任务等依旧用FastAdmin
测试分析
- EasySwoole采用协程非阻塞模型，且资源不重复加载消耗，理论上就比nginx+php-fpm快的多，由于目前采用的是1核2G的本地测试服，性能较弱，所以后者并发量上不去，用线上的同等配置速度能达测试服的3~6倍，速度已然完全可以接受。
- 调两次服务接口和调一次的时间基本无差别，加上对代码 的分析，瓶颈不在Guzzle，因为Guzzle本身的性能已然不错
- 纯Swoole自然最好，但是迁移成本太高，且有很多未知的坑。