一、前言
这段时间一直在对项目接口进行压测，过程很扎心，测到最后决定更换Swoole类框架。
我选择的接口框架是TP5.1，这个选择不是从技术上考虑，仅仅是希望公司同事更容易上手。
接口花了一个多月开发完成，部署服务器Lnmp环境，项目上线，测试接口功能，没大问题，然后把存在高并发的接口挑出来进行压测，结果……泪奔！
公司业务是在欧美，所以我们是买的亚马逊aws服务器，虽然公司网络用的是香港那边的VPN，但 ping 服务器地址时，时间花得比较长，230ms左右（国内服务器只要10ms左右），所以不敢在线下测试了，打击人，换到线上测试。
说明：和框架有关，但不是想说框架的锅，每个框架都有自己的特点，不同的业务场景，需求不同，框架本身没毛病。
二、具体测试流程
1. 准备工作
（1）查看服务器配置：2核4G；
（2）关闭TP框架的调试，开启配置、路由缓存，生成类库映射文件，生成数据表字段缓存文件；
（3）开启PHP的Opcache扩展。
2. 测试工具：ab
3. 测试目标：100000连接，1000并发，rps可以达到2000以上。
4. 调整php-fpm配置，尝试动态和静态，依照夹逼准则，最后配置如下：
pm = static
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 105. 测试结果：此时测试的结果很不满意，并发超过500时，直接报错：Connection timed out；测100的并发，rps最多不到800。这个结果简直让人郁闷，到底是什么问题呢？
三、寻找问题的过程
因为以前做的项目都比较小，对于高并发的需求很少，所以此时我没有优化的头绪，和同事沟通交流，上网查资料，差不多花了一天时间，最后在本地虚拟主机上搭建项目进行问题排查，具体流程如下：
1. 查看本地虚拟主机的配置：lnamp环境，1核2G；
2. 完成第二步的所有优化；
3. 开始对照实验，在相同配置下，按照10000的连接，1000的并发进行压测，对照组如下：
（1） nginx下的静态文件；
（2）单独的php文件；
（3）TP5.1框架欢迎页。
4. 具体测试结果如下：
（1）直接测试nginx下的静态文件，测试结果如下：
（2）测试单独的php文件，测试结果如下：
（3） 测试TP5.1框架欢迎页，测试结果如下：
5. 结果说明
测试结果很辣眼睛。
nginx下访问静态文件，RPS是790，cpu消耗50%；
nginx+php-fpm下压测phpinfo.php，RPS是190，因为单文件，cpu释放较快，cpu消耗弹性很大，从百分几到百分百；
nginx+php-fpm下压测Tp5的初始欢迎页，RPS有245，但cpu消耗一直持续100%，1分钟的cpu负载也达到90，超负荷运转。
6. 测试思考
这个测试结果让我开始关注框架本身性能区别，于是搜索网上资料，根据知乎、各大博客的文章，筛选了以下几个框架再次进行对照试验，对照组如下：
（1）Tp5.1；
（2）lumen；
（3）yii；
（4）mixphp。
（1）lumen
（2）yii
（3）mixphp
7. 第二轮对照测试结果说明
这轮框架对照测试真的让我惊讶了。
lumen的欢迎页压测下，rps达到了314，但cpu消耗一直都是100%，且1分钟负荷也达到了54；
yii和想象中差别有点大，rps才133，cpu消耗也一直是100%，1分钟的负荷也达到了67；
mixphp框架，rps达到789，cpu消耗30%左右。
四、总结说明
最后找到这个以swoole为基础的mixphp框架性能真的让我很惊喜，这个框架以服务的形态运行，可以用nginx代理，代理后的效率也差不多，所以看到这个性能优势后，果断决定改用mixphp框架。
最后这个总结看上去还是在比较框架的优劣，其实不然，因为我比较熟悉的就是TP和Laravel框架，说实话我很喜欢用Laravel，框架设计确实很优雅，有强迫症的人用起来真的很舒服；TP也确实非常简单，很容易上手；yii我不太熟，但看那么多大公司使用yii，肯定也有他们自己的道理，纯c写的PHP框架，按道理来说性能应该不会太差，我这次测试不知道科不科学，但仅仅从本次测试目的角度来看，框架性能方面，mixphp确实更优一筹，这也是国内PHP大牛写的，跟着学习，也借着这个框架进入swoole的世界，也蛮不错的。