首先composer一个干净的laravel5.8,改写一下welcome,输出当前的模式是php-fpm还是cli,
可以看到,当前是 php-fpm下的模式
使用 apache自带的ab压测工具,就测这个路由,
3000个请求,300个并发
服务器是 Ubuntu 1核1G的测试服务器,php-fpm 最大子进程数30个
压测过程,可以看到,服务器占用非常高,由于只有30个空闲进程,所以处理起来相当吃力了
测试结果以html的格式保存到 miss,html,结果如下,可以看到,失败率非常高,平均每秒接受了40多个请求,失败一半以上,相当于3000请求,300并发的条件下,每秒能处理完成的请求不到20个,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,分割一下,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
接下来修改一下 nginx的配置文件,把index,php请求转发到swoole,
这个框架我引入了作者hhxsv5 的胶水项目laravelS, 选择监听5200端口,并用 php bin/laravels start 启动了服务,监听5200端口,尝试请求一下,发现原先应该被转发到php-fpm 的127.0.0.1:9000端口监听的请求,成功被转发到了swoole监听的 5200请求上,并且处理请求的程序也变成了 cli模式,切换成功!
接下来,一摸一样的条件,控制变量发,发起3000个请求,300个并发,可以看到,cli模式下,由于swoole常驻内存,不需要重复开启进程,大大增强了处理能力,服务器轻松无压力
处理结果,对比nginx+php-fpm的模式,3000个请求全部成功,处理能力达每秒62个,这才消耗了服务器不到三分之一的性能
各位大佬对此怎么看
,,,*大对大佬先发表意见
可以看到,当前是 php-fpm下的模式
使用 apache自带的ab压测工具,就测这个路由,
3000个请求,300个并发
服务器是 Ubuntu 1核1G的测试服务器,php-fpm 最大子进程数30个
压测过程,可以看到,服务器占用非常高,由于只有30个空闲进程,所以处理起来相当吃力了
测试结果以html的格式保存到 miss,html,结果如下,可以看到,失败率非常高,平均每秒接受了40多个请求,失败一半以上,相当于3000请求,300并发的条件下,每秒能处理完成的请求不到20个,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,分割一下,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
接下来修改一下 nginx的配置文件,把index,php请求转发到swoole,
这个框架我引入了作者hhxsv5 的胶水项目laravelS, 选择监听5200端口,并用 php bin/laravels start 启动了服务,监听5200端口,尝试请求一下,发现原先应该被转发到php-fpm 的127.0.0.1:9000端口监听的请求,成功被转发到了swoole监听的 5200请求上,并且处理请求的程序也变成了 cli模式,切换成功!
接下来,一摸一样的条件,控制变量发,发起3000个请求,300个并发,可以看到,cli模式下,由于swoole常驻内存,不需要重复开启进程,大大增强了处理能力,服务器轻松无压力
处理结果,对比nginx+php-fpm的模式,3000个请求全部成功,处理能力达每秒62个,这才消耗了服务器不到三分之一的性能
各位大佬对此怎么看
,,,*大对大佬先发表意见
