上線清單 —— 20 個 Laravel 應用性能優化項

文章轉發自專業的Laravel開發者社區，原始連接： https://learnku.com/laravel/t...

讓咱們開始吧！倘若你的 laravel 應用已經投入生產環境中。

從第一個用戶，到第十，第一百，直到成千上萬的用戶！慢慢地，隨着用戶越多，你的網站會愈來愈慢

那咱們應該如何作？細節決定成敗

通過一番搜索，我決定寫下這20個使你網站提高速度的小提示

我將從基礎開始，大部分都是能夠瞬間完成的操做。而後，我將逐步提升難度。最後，就是更高級的內容了。若是你跟着個人步驟一步一步來，我相信你的網站會獲得質的提高。

享受你的學習之旅！若是你有什麼建議，能夠在下方留言！我很高興跟你們共同探討。

基礎的優化項

讓咱們看看咱們可以在短短几秒鐘內作些什麼。

1. 路由緩存

每次服務器執行請求時，都會註冊全部的路由，這會花費一些時間。可是，你能夠選擇緩存路由列表來跳過這個步驟。

緩存路由列表是很是簡單的。你須要作的是在部署應用程序後，執行下面的這個命令：

php artisan route:cache

可是，若是你添加或修改了任意一個路由信息，請不要忘記清除以前的緩存以及從新執行緩存命令。

php artisan route:clear

# 而後，再次執行
php artisan route:cache

注意，這隻對控制器類路由有效。

2. 緩存配置

就如路由同樣，你一樣能夠在應用中緩存配置文件。

設想一下這種場景：每次你發送一個請求到 App 中，Laravel 都須要去加載不一樣的配置文件，而且要去打開.env 文件讀取其中的內容。這種方式性能低下，是不？

不過不用擔憂，這裏有個 Artisan 命令專治這個。

php artisan config:cache

你在部署以後可使用它。和路由差很少，別忘了編輯東西的時候清理一下緩存。

php artisan config:clear

# 而後，再來一次...
php artisan config:cache

3. 優化 Composer 自動加載

一般，Composer 生成自動加載文件很是快。可是，在生產環境中，若是設置了PSR-4 和 PSR-0 自動加載規則，這可能會變慢。

您能夠經過將下面命令添加到部署腳原本優化自動加載器文件建立過程。

$  composer dump-autoload  -o

不要忘記它。

4. 謠言：「不要大量使用 Blade 視圖」

這個謠言我都聽到頭大了。

"千萬不要大量使用 Blade 視圖，由於它會使得應用性能下降！"

徹頭徹尾的大謊話！認真臉！

銘記這個：Laravel 編譯 Blade 視圖。編譯就是說，在流程結束時，你將擁有一個已編譯的完整文件，而非使用多個文件。

因此，絲絕不須要擔憂。

• • • • *

中級乾貨

5. 換個其餘/更好的 Cache/Session 驅動

默認的，當你新建一個 Laravel 項目的時候Cache 和 Sessions 的驅動默認爲 「文件」。在本地開發環境和小項目中它沒啥問題，可是項目增加時事情就大條了。

因此，考慮下換個更好的驅動例如 Redis。 Laravel 有內置支持它的方式，而你要作的就是 安裝 Predis。

更多細節在 這裏和 此處。

6. 儘快升級 Laravel 版本

當新版本發佈時，請記得儘快升級 Laravel。這不只關乎新功能：在可能的狀況下，全部貢獻者都花時間修復代碼庫周邊的性能問題。

因此，要持續關注並保持代碼更新。

7. 刪除未使用的服務

這是不少人常常忘記的小技巧，要向本身提問：

"我須要它嗎？*

咱們知道 Laravel 自帶了不少服務，畢竟，這是一個全棧框架，每個服務都有其用武之地。

因此，請花一些時間檢查 config/app.php  文件，看看你是否能找到一個你不須要的服務。若是一切正常，請嘗試將其刪除並測試您的應用程序。

它應該有所幫助（一點點）！

8. 使用預加載進行查詢

若是你知道 Laravel 是什麼，你可能也知道預加載是什麼。 若是您信息不夠及時，預加載是一種經過使用特定語法來減小發送到數據庫的查詢數量來提升 Eloquent 性能的方法。

此問題稱爲N + 1查詢問題。 讓咱們舉個例子。 你有兩個模型：Book 和 Author。 每本 book 都有它的 author。

$books  =  App\Book::all();

foreach  ($books  as  $book)  {
    echo  $book->author->name;
}

想象一下，您的數據庫中有1000本書。 如今，此代碼將執行 1001 次查詢以檢索這1000本書的做者姓名。

1（查詢以獲取1000本書的數據）+ 1000（查詢以獲取每本書的做者數據）= 1001。

可是，若是你編寫這樣的代碼

$books  =  App\Book::with('author')->get();

foreach  ($books  as  $book)  {
    echo  $book->author->name;
}

更改基礎查詢以免此性能問題。 您將只執行兩個查詢而不是1001！ 這是巨大的性能提高。

9. 緩存查詢結果

有時候， 緩存一個具體的查詢結果多是一個好主意。

想象這樣一個場景：你準備在你的應用主頁上展現 「十大專輯」 排行榜。 這項工做是經過從數據庫中執行查詢完成的（查詢可能涉及到artists表以及其餘的一些表）。 你的主頁訪問量是 1000 次/小時 。

若是這個排行榜數據的查詢次數是 1000次每小時，那麼一天下來執行的查詢次數就是24000次。
如今，讓咱們假設這個排行榜是每小時更新一次 。那麼，將每次的查詢結果緩存一小時如何 ？

$value  =  Cache::remember('top_10_albums',  60,  function  ()  {
    return  Album::with('artist',  'producer')->getTopTen();
});

這個緩存組件的  remember 方法在未找到緩存的狀況下將會先從數據庫中獲取數據，並緩存60分鐘。到期後，將會再次從數據庫中獲取最新的數據，更新緩存。

查詢次數 從 24000 到 24 次/天 。

10. 爲你的數據表創建索引

記住，必要的時候請爲您的數據表創建索引。 這看起來像是個沒什麼卵用的提示，但實際上這頗有必要。 由於我見過很是多的應用，它們的數據表沒有索引。

實現起來很簡單，您能夠建立一個新的數據庫遷移並使用裏面的方法來添加索引.

Schema::table('my_table_name',  function(Blueprint  $table){
    $table->index('field_to_be_indexed');
});

固然，索引不是您喜歡在哪建就直接建立一個就是了。您必須研究您的業務、代碼和查詢，去分析哪裏纔是最須要索引的地方，而後再創建索引。

11. 中間件太多？

Laravel 會對你註冊的中間件進行大量的（前/後）調用。因此，請你仔細檢查它們，而且去掉那些你不須要的中間件。

一般中間件列表在 Kernel.php 。

12. 是時候使用隊列了！

有些時候，Laravel 比預期慢，這時你能夠考慮異步執行任務。

最多見的狀況就是發送一封歡迎郵件，讓咱們一塊兒看看任務流程。

1. 用戶填寫咱們的表單；
2. 將他/她的詳細信息寫入數據庫；
3. 發送一封寫有歡迎語和確認連接的郵件給他/她;
4. 並展現感謝頁面；

不少時候，這些任務徹底是在控制器中而且按照順序執行。

個人建議是學會如何使用事件和隊列，能夠將發送郵件任務交給專門的流程，以至於改善用戶使用體驗。

• • • • *

高級乾貨

13. 使用 Pusher 改進異步隊列

上面我寫了一些跟隊列有關的內容。有時，你也可使用隊列來改善面向用戶的任務。

想象一下，你正在建立一個繁重的（在計算方面）進程，而且但願給用戶顯示這個任務的進度條。你能夠輕鬆地使用隊列的異步任務並集成 Pusher 來向前端發送消息以達到目的，即便這個任務沒有完成。

另外一個常用的示例是向用戶發送消息不須要刷新頁面。

考慮一下吧！

14. 使用 Logs / Debugbars / Laravel Telescope 測量調試工具

在提高本身方面，有一句我本身很是喜歡的引用。是從個人 CEO （感謝 Massimo ！）引用 Peter Drucker 的話那聽來的。

若是你沒法衡量它，你就沒法改進它。

這個概念很是適合 Web 應用程序的上下文。要想改善 Web 應用的請求管理時間，須要測量不少東西。幸運地，咱們有許多很是優秀的工具來完成這件事。

• 慢日誌： MYSQL ， MariaDB 和其餘數據庫能夠啓用慢日誌來追蹤那些語句花了大量的時間。你可使用這些數據來斷定是否必須更改或優化特定的代碼（或查詢）；
• Debugbar ： Laravel Debugbar 是一個很棒的擴展包。在不少應用程序方面，你可使用它來收集數據。好比查詢，視圖，時間等等；
• Laravel Telescope ： 另外一個很是酷的工具是 Laravel Telescope ，對 Laravel 應用，有「優雅的調試助手」的美稱。若是你感興趣， 我已經在這裏寫了一篇關於它的文章 ；

15. 更新你的PHP版本

雖然這看起來很簡單，可是若是你的項目夠大的話，這執行起來會很麻煩，因此我以爲把這條加入高級技巧裏面。

若是你的 PHP 版本在7.0如下，更新你的 PHP 和 laravel 版本。

16. 在服務器上使用 Lumen

若是你的應用程序數據量增加很大，你能夠考慮爲你的系統作服務拆分了。不過，這並無一個明確的方法指南來引導你完成它：拆分標準的高與低取決於來自應用程序的領域到拆分全部必需的內容所需的工做中的許多因素。

可是，一旦你拆分紅功，你的項目將得到新生。

若是你對這個主題感興趣的話，能夠從  https://medium.com/@munza/lar... 開始。

17. 爲靜態資源提供 CDN 服務

我很是確定你有不少前端的資源，好比 CSS 文件和 JS 腳本。

你能夠經過多種方式來減小發送給用戶的數據量：

• 壓縮靜態資源;
• 捆綁靜態資源（將多個 CSS 文件或者 JS 腳本合併爲一個，以減小請求次數）;
• 開啓 gzip 壓縮;

然而，若是你遇到大量的流量，則你能夠將你的靜態資源託管到專用的 CDN 服務器上，好比：

• Akamai（阿卡邁）;
• Max CDN;
• Cloudflare;
• 亞馬遜 AWS 服務 (S3 + CloudFront);

譯者注：國內可使用又拍雲和七牛雲

18. 使用高級測量工具

安裝 Laravel Debugbar 或 Telescope 將是一個良好的開端，但對於更重大的項目，這還不夠。

你須要選擇更高級的工具，以下：

• New Relic;
• AppOptics;
• Datadog;
• Sentry;

以上列表的應用程序不作一樣的事情：他們被設計用於不一樣目的。花些時間去學習他們以理解他們如何提供幫助。

19. 垂直擴展

你已經對代碼的細枝末節都進行了完全優化，可是你的應用體量在不斷增加。早晚你都要進行垂直擴展。

有個簡單的說法就是：更多的 RAM，更多的空間，更多的帶寬就，以及更多的 CPU

注意這個只是對許多沒有足夠時間來安排重構/優化的初創公司的一般作法。法子是不錯，因此你能夠認爲這是能讓你喘口氣的臨時解決方案。

20. 水平擴展

水平擴展是另外一種擴展的方式，它不一樣於傳統的垂直擴展，主要有兩點：

• 取代在現有配置上增長硬件資源的方式，你可能將會添加更多的功能模塊來處理日益增長的流量。 在垂直擴展的環境中，你只須要增長服務器配置就行，可是水平擴展應用就意味着你的應用將會部署運行在不一樣的機器上，有多是在一個負載均衡機器或者其餘服務以後。這就意味着須要更多的設置和配置；此時事情就沒那麼簡單了；
• 並不是全部的應用均可以在短期內擴展完畢，有時候你須要重構隔離一些代碼；有時候你須要把應用拆分爲不一樣規模的小型服務。

水平擴展會有有不少事情要作，可是一旦你能對應用進行水平擴展時，好處也是超乎想象的。

結論

今天有足夠的內容了！我經過合併個人我的經驗和之前作過的一些研究建立了在這個列表。

若是你願意，請儘管提出一些新東西，我很樂意相應更新一下此文章。