摘要：此問題稱為查詢問題。您將只執行兩個查詢而不是這是巨大的性能提升。這項工作是通過從數據庫中執行查詢完成的查詢可能涉及到表以及其他的一些表。比如查詢，視圖，時間等等另一個非常酷的工具是，對應用，有優雅的調試助手的美稱。

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

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

那我們應該如何做？細節決定成敗

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

我將從基礎開始，大部分都是可以瞬間完成的操作。然后，我將逐步提高難度。最后，就是更高級的內容了。如果你跟著我的步驟一步一步來，我相信你的網站會得到質的提升。

享受你的學習之旅！如果你有什么建議，可以在下方留言！我很高興跟大家共同探討。

讓我們看看我們能夠在短短幾秒鐘內做些什么。

每次服務器執行請求時，都會注冊所有的路由，這會花費一些時間。但是，你可以選擇緩存路由列表來跳過這個步驟。

緩存路由列表是非常簡單的。你需要做的是在部署應用程序后，執行下面的這個命令：

php artisan route:cache

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

php artisan route:clear

# 然后，再次執行
php artisan route:cache

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

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

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

不過不用擔心，這里有個 Artisan 命令專治這個。

php artisan config:cache

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

php artisan config:clear

# 然后，再來一次...
php artisan config:cache

通常，Composer 生成自動加載文件非常快。但是，在生產環境中，如果設置了PSR-4 和 PSR-0 自動加載規則，這可能會變慢。

您可以通過將下面命令添加到部署腳本來優化自動加載器文件創建過程。

$  composer dump-autoload  -o

不要忘記它。

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

"千萬不要大量使用 Blade 視圖，因為它會使得應用性能降低！"

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

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

所以，絲毫不需要擔心。

*

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

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

更多細節在?這里和?此處。

當新版本發布時，請記得盡快升級 Laravel。這不僅關乎新功能：在可能的情況下，所有貢獻者都花時間修復代碼庫周邊的性能問題。

所以，要持續關注并保持代碼更新。

這是很多人經常忘記的小技巧，要向自己提問：

"我需要它嗎？*

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

所以，請花一些時間檢查 config/app.php? 文件，看看你是否能找到一個你不需要的服務。如果一切正常，請嘗試將其刪除并測試您的應用程序。

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

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

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

$books  =  AppBook::all();

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

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

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

但是，如果你編寫這樣的代碼

$books  =  AppBook::with("author")->get();

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

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

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

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

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

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

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

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

記住，必要的時候請為您的數據表建立索引。 這看起來像是個沒什么卵用的提示，但實際上這很有必要。 因為我見過非常多的應用，它們的數據表沒有索引。

實現起來很簡單，您可以創建一個新的數據庫遷移并使用里面的方法來添加索引.

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

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

Laravel 會對你注冊的中間件進行大量的（前/后）調用。所以，請你仔細檢查它們，并且去掉那些你不需要的中間件。

通常中間件列表在?Kernel.php?。

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

最常見的情況就是發送一封歡迎郵件，讓我們一起看看任務流程。

用戶填寫我們的表單；

將他/她的詳細信息寫入數據庫；

發送一封寫有歡迎語和確認鏈接的郵件給他/她;

并展示感謝頁面；

很多時候，這些任務完全是在控制器中并且按照順序執行。

我的建議是學會如何使用事件和隊列，可以將發送郵件任務交給專門的流程，以致于改善用戶使用體驗。

*

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

想象一下，你正在創建一個繁重的（在計算方面）進程，并且希望給用戶顯示這個任務的進度條。你可以輕松地使用隊列的異步任務并集成 Pusher 來向前端發送消息以達到目的，即使這個任務沒有完成。

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

考慮一下吧！

在提升自己方面，有一句我自己非常喜歡的引用。是從我的 CEO （感謝 Massimo ！）引用 Peter Drucker 的話那聽來的。

如果你無法衡量它，你就無法改進它。

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

慢日志： MYSQL ， MariaDB 和其他數據庫可以啟用慢日志來追蹤那些語句花了大量的時間。你可以使用這些數據來判定是否必須更改或優化特定的代碼（或查詢）；

Debugbar ： Laravel Debugbar 是一個很棒的擴展包。在很多應用程序方面，你可以使用它來收集數據。比如查詢，視圖，時間等等；

Laravel Telescope ： 另一個非常酷的工具是 Laravel Telescope ，對 Laravel 應用，有“優雅的調試助手”的美稱。如果你感興趣， 我已經在這里寫了一篇關于它的文章 ；

雖然這看起來很簡單，但是如果你的項目夠大的話，這執行起來會很麻煩，所以我覺得把這條加入高級技巧里面。

如果你的 PHP 版本在7.0以下，更新你的 PHP 和 laravel 版本。

如果你的應用程序數據量增長很大，你可以考慮為你的系統做服務拆分了。不過，這并沒有一個明確的方法指南來引導你完成它：拆分標準的高與低取決于來自應用程序的領域到拆分所有必需的內容所需的工作中的許多因素。

但是，一旦你拆分成功，你的項目將獲得新生。

如果你對這個主題感興趣的話，可以從 ?https://medium.com/@munza/lar... 開始。

我非常肯定你有很多前端的資源，比如 CSS 文件和 JS 腳本。

你可以通過多種方式來減少發送給用戶的數據量：

壓縮靜態資源;

捆綁靜態資源（將多個 CSS 文件或者 JS 腳本合并為一個，以減少請求次數）;

開啟 gzip 壓縮;

然而，如果你遇到大量的流量，則你可以將你的靜態資源托管到專用的 CDN 服務器上，比如：

Akamai（阿卡邁）;

Max CDN;

Cloudflare;

亞馬遜 AWS 服務 (S3 + CloudFront);

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

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

你需要選擇更高級的工具，如下：

New Relic;

AppOptics;

Datadog;

Sentry;

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

你已經對代碼的細枝末節都進行了徹底優化，但是你的應用體量在不斷增長。遲早你都要進行垂直擴展。

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

注意這個只是對許多沒有足夠時間來安排重構/優化的初創公司的通常做法。法子是不錯，所以你可以認為這是能讓你喘口氣的臨時解決方案。

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

取代在現有配置上增加硬件資源的方式，你可能將會添加更多的功能模塊來處理日益增加的流量。 在垂直擴展的環境中，你只需要增加服務器配置就行，但是水平擴展應用就意味著你的應用將會部署運行在不同的機器上，有可能是在一個負載均衡機器或者其他服務之后。這就意味著需要更多的設置和配置；此時事情就沒那么簡單了；

并非所有的應用都可以在短時間內擴展完畢，有時候你需要重構隔離一些代碼；有時候你需要把應用拆分為不同規模的小型服務。

水平擴展會有有很多事情要做，但是一旦你能對應用進行水平擴展時，好處也是超乎想象的。

今天有足夠的內容了！我通過合并我的個人經驗和以前做過的一些研究創建了在這個列表。

如果你愿意，請盡管提出一些新東西，我很樂意相應更新一下此文章。

轉自 https://learnku.com/laravel/t...