Laravel框架高并发性能优化

调整框架本身的配置

 

 

• 编辑.env
  APP_ENV = production
  APP_DEBUG = false
• php artisan route:cache / php artisan config:cache
• composer dump-autoload --optimize
• php artisan optimize

其他可能

 

 

• 开启OPcache
• php-fpm 配置调优

参考文章

But.....压测很容易看出，这些很难看到提高十倍以上性能的效果

 

 

• 如果你正在考虑框架性能优化的问题， 你对PHP应该已经有足够的了解了。 如你所知， PHP每次的每次请求结束， 都会释放掉执行中建立的所有资源。这样有一个很大的好处：PHP程序员基本不用费力去考虑资源释放的问题，诸如内存，IO句柄，数据库连接等，请求结束时PHP将全部释放。PHP程序员几乎不用关心内存释放的问题，也很难写出内存泄露的程序。这让PHP变得更加简单容易上手， 直抒心意。但是也带来了一个坏处：PHP很难在请求间复用资源， 类似PHP框架这种耗时的工作， 每次请求都需要反复做——即使每次都在做同样的事情。也正因为如此，在PHP发展过程中，关于是否使用框架的争论也从未停止过。

• Laravel本身启动需要的文件就很多，外加其出了名的生态环境好，开发中我们会 很多很多现有的轮子，使得一次启动的磁盘IO特别高（就是要加载很多文件嘛），虽然官方的php artisan optimize方法优化了文件的加载，但并没有实际解决IO上的问题。
  知道了问题那就很容易解决了，只要不要每次启动都重新加载就好了，下面轮到Swoole上场啦。

• swoole框架相比apache/fpm，主要是节省PHP框架和全局对象每次请求创建销毁带来的性能损耗。如果你的PHP代码是裸echo的方式，swoole框架并没有性能优势。

• 同样，事情总是有好有坏。坏处是：PHP编程变得更难了， 你需要考虑内存的释放，需要关心PHP如何使用内存。甚至， 你需要了解使用的框架，以免『不小心』写出让人『惊喜』的效果。同时， PHP的调试变得更难， 因为每次修改程序后需要重启进程才能看到效果。好处是：程序的性能得到极大的提高。 当然， 客观上的一些利好因素是： PHP的内存回收已经相当稳定和高效， Swoole稳定性已经在相当多的项目中得到验证，Laravel代码质量相当高

画个饼

 

 

方案性能对比 使用的轮子:stone

应用类型	原始Laravel	Stone-Web	Stone-Server	原生php直接echo
laravel5 默认页面	150	3000	--	--
laravel5 简单接口	150	3000	8500	9500
laravel4 实际项目简单页面	70	1000	--	--
laravel4 简单接口	120	--	8200	9500
laravel4 实际项目首页	35	380	--	--

• 以上单位全部为RPS
• Stone相对于原始的Laravel有相当可观的提升
• 即使和一个简单的echo相比， Stone性能损失仅10%左右

swoole+laravel 说干就干！

 

 

PS：如果亲还是用的php5 我就不带你玩了哈

选个新点火点的轮子：laravel-s

找个本地已有项目ab试水，附上现有结果

Requests per second: 31.91 [#/sec]

先看laravel-s文档一阵配置....

Requests per second: 592.17 [#/sec] (mean)

都是压测的ab -n 200 -c 20 三次取的平均值 性能提升了20倍！！！

不必多说 花10分钟你也来试试 就知道其中的爽了

bingo,终于可以在golang的同事面前继续说php是世界上最美的语言了.......

最后再吹水一波swoole

 

 

使用apache bench工具对Nginx静态页、Golang Http程序、PHP7+Swoole Http程序进行压力测试。在同一台机器上，进行并发100共100万次Http请求的基准测试中，QPS对比如下：

软件	QPS	软件版本
Nginx	164489.92	nginx/1.4.6 (Ubuntu)
Golang	166838.68	go version go1.5.2 linux/amd64
PHP7+Swoole	287104.12	swoole-1.7.22-alpha
Nginx-1.9.9	245058.70	nginx/1.9.9

From swoole 官网 去看看