調整框架本身的配置

• 編輯.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

• 以上單位全部為RPS
• Stone相對於原始的Laravel有相當可觀的提升
• 即使和一個簡單的echo相比， Stone效能損失僅10%左右

swoole+laravel 說幹就幹！

PS：如果親還是用的php5 我就不帶你玩了哈

找個本地已有專案ab試水，附上現有結果

Requests per second: 31.91 [#/sec]

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對比如下：

From swoole 官網 去看看