关于swoole对laravel项目的提升，以及golang和前者的选择

自己是个菜鸟，因为自己这段时间学了一下golang，并且开始在使用Beego做web项目了，但是就是在过程中突然冒出一个想法：如果新开一个项目的话，我是应该选择gobee还是laravel+swoole呢？于是就想要比较这两者哪一个会好一些。

场景就是在单服务器的情况下选择了一个场景，相同条件的分页请求压力下，两者的哪一个可以承载更多的请求。

**php7.3+mysql5.7+swoole（hhxsv5/laravel-s）+laravel6.2
golang1.13+beego**

数据表9个字段，数量15w，每次查询10条随机数据

验证的问题如下:

1. 没有swoole加持的laravel以及加上了swoole的laravel存在着多大的性能差距。
2. 加上了swoole的laravel和beego存在的多大的差距

为了找到这两个问题的答案，于是就有了一下的实验以及结论，如果有那里存在问题的话，欢迎指出：
测试工具是：8G内存4核心5M的云服务器一台，apache-jMeter

接下来就是贴出我的实验数据

以下的执行结果，均是jmeter执行后的结果，执行5次，每次4000次请求，

单纯的laravel6.2应用，
4000次同时请求的情况下:
1: 耗时1min22s， 1145次成功，其余的502
2: 耗时1min20s， 1120次成功，其余的502
3: 耗时1min15s， 1159次成功，其余的502
4: 耗时1min21s， 1144次成功，其余的502
5: 耗时1min30s， 1319此成功，其余的502
==> 使用postman进行单次请求的话，平均时间在256ms-280ms之间徘徊

---

laravel6.2+swoole
4000次同时请求的情况下:
1: 耗时1min43s， 1268次成功，其余的502
2: 耗时1min10s， 1249次成功，其余的502
3: 耗时1min10s， 1263次成功，其余的502

4: 耗时1min08s， 104次成功，其余的504 (swoole的5200端口处于CLOSE_WAIT和FIN_WAIT2两种状态)
5: 耗时1min12s，519次成功，其余的504， 端口状态和第4次一样
==> 使用postman进行单次请求的话，平均时间在180-206ms之间徘徊

---

=============================================

其实之前刚刚接触swoole的时候，我一直觉得swoole对于laravel的提升特别显著，因为之前数据库并不大，也就几千条而已，但是数据量达到了10w级别的话，并没有感觉到提升特别显著，但是看上面的测试的话，似乎还不如不上swoole

---

接下来就是测试beego，同样场景下，表现如何，nginx已被关闭
4000次同时请求的情况下:
1: 耗时36s， 3986次成功，其余的是返回这个（Non HTTP response code）
2: 耗时26s， 3615次成功，其余的和上面一样
3: 耗时30s， 3979次成功，其余的同上
4: 耗时30s， 3657次成功，其余的同上
5: 耗时23s， 3565此成功，其余的同上
==> 使用postman进行单次请求的话，平均时间在180ms-201ms之间徘徊

这个是单纯的beego测试结果，到这边的时候就有点玩上瘾了，于是就尝试了另一个方式，用nginx做接收，并且转发给beego处理，能不能有所提升

nginx+beego

1: 耗时35s， 3989次成功，其余的是返回这个（Non HTTP response code）
2: 耗时26s， 3971次成功，其余的和上面一样
3: 耗时30s， 3979次成功，其余的同上
4: 耗时23s， 3989次成功，其余的同上
5: 耗时27s， 3626次成功，其余的同上(不知道为什么最后这一个会突然降下来这么多)
==> 使用postman进行单次请求的话，平均时间在190ms-221ms之间徘徊

---

根据这些实验数据的话，对我上面的两个问题提出解答：

1. swoole对于larvel的提升是有，但是在数据表数量级别超过十万级的话，提升的效果并不明显，而且操作不好可能会表现得比不加swoole的时候更差
2. 第二个问题，光看实验数据的话，差距还真的很大。。感觉是可以把自己的学习重心往golang这边转移了，也顺便给一些和我一样比较迷茫的人一些参考把