上線清單 —— 20 個 Laravel 應用效能優化項
讓我們開始吧！假若你的 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($booksas$book){
echo$book->author->name;
}
想象一下，您的資料庫中有1000本書。 現在，此程式碼將執行1001 次查詢以檢索這1000本書的作者姓名。
1（查詢以獲取1000本書的資料）+ 1000（查詢以獲取每本書的作者資料）= 1001。
但是，如果你編寫這樣的程式碼
$books=App\Book::with('author')->get();
foreach($booksas$book){
echo$book->author->name;
}
更改基礎查詢以避免此效能問題。 您將只執行兩個查詢而不是1001！ 這是巨大的效能提升。
9. 快取查詢結果
有時候， 快取一個具體的查詢結果可能是一個好主意。
想象這樣一個場景：你準備在你的應用主頁上展示 “十大專輯” 排行榜。 這項工作是通過從資料庫中執行查詢完成的（查詢可能涉及到artists表以及其他的一些表）。 你的主頁訪問量是 1000 次/小時 。
如果這個排行榜資料的查詢次數是 1000次每小時，那麼一天下來執行的查詢次數就是24000次。 現在，讓我們假設這個排行榜是每小時更新一次 。那麼，將每次的查詢結果快取一小時如何 ？
$value=Cache::remember('top_10_albums',60,function(){
returnAlbum::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 比預期慢，這時你可以考慮非同步執行任務。
最常見的情況就是傳送一封歡迎郵件，讓我們一起看看任務流程。
- 使用者填寫我們的表單；
- 將他/她的詳細資訊寫入資料庫；
- 傳送一封寫有歡迎語和確認連結的郵件給他/她;
- 並展示感謝頁面；
很多時候，這些任務完全是在控制器中並且按照順序執行。
我的建議是學會如何使用事件和佇列，可以將傳送郵件任務交給專門的流程，以致於改善使用者使用體驗。
高階乾貨
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/large -scale-laravel-application-9d52c3d38e51 開始。
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. 水平擴充套件
水平擴充套件是另一種擴充套件的方式，它不同於傳統的垂直擴充套件，主要有兩點：
- 取代在現有配置上增加硬體資源的方式，你可能將會新增更多的功能模組來處理日益增加的流量。 在垂直擴充套件的環境中，你只需要增加伺服器配置就行，但是水平擴充套件應用就意味著你的應用將會部署執行在不同的機器上，有可能是在一個負載均衡機器或者其他服務之後。這就意味著需要更多的設定和配置；此時事情就沒那麼簡單了；
- 並非所有的應用都可以在短時間內擴充套件完畢，有時候你需要重構隔離一些程式碼；有時候你需要把應用拆分為不同規模的小型服務。
水平擴充套件會有有很多事情要做，但是一旦你能對應用進行水平擴充套件時，好處也是超乎想象的。
結論
今天有足夠的內容了！我通過合併我的個人經驗和以前做過的一些研究建立了在這個列表。
如果你願意，請儘管提出一些新東西，我很樂意相應更新一下此文章。