摘要：此問題稱為查詢問題。您將只執(zhí)行兩個查詢而不是這是巨大的性能提升。這項工作是通過從數(shù)據(jù)庫中執(zhí)行查詢完成的查詢可能涉及到表以及其他的一些表。比如查詢，視圖，時間等等另一個非?？岬墓ぞ呤?，對應(yīng)用，有優(yōu)雅的調(diào)試助手的美稱。

讓我們開始吧！假若你的 laravel 應(yīng)用已經(jīng)投入生產(chǎn)環(huán)境中。

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

那我們應(yīng)該如何做？細節(jié)決定成敗

經(jīng)過一番搜索，我決定寫下這20個使你網(wǎng)站提升速度的小提示

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

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

讓我們看看我們能夠在短短幾秒鐘內(nèi)做些什么。

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

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

php artisan route:cache

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

php artisan route:clear

# 然后，再次執(zhí)行
php artisan route:cache

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

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

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

不過不用擔(dān)心，這里有個 Artisan 命令專治這個。

php artisan config:cache

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

php artisan config:clear

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

通常，Composer 生成自動加載文件非?？?。但是，在生產(chǎn)環(huán)境中，如果設(shè)置了PSR-4 和 PSR-0 自動加載規(guī)則，這可能會變慢。

您可以通過將下面命令添加到部署腳本來優(yōu)化自動加載器文件創(chuàng)建過程。

$  composer dump-autoload  -o

不要忘記它。

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

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

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

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

所以，絲毫不需要擔(dān)心。

*

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

所以，考慮下?lián)Q個更好的驅(qū)動例如 Redis。 Laravel 有內(nèi)置支持它的方式，而你要做的就是?安裝 Predis。

更多細節(jié)在?這里和?此處。

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

所以，要持續(xù)關(guān)注并保持代碼更新。

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

"我需要它嗎？*

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

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

它應(yīng)該有所幫助（一點點）！

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

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

$books  =  AppBook::all();

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

想象一下，您的數(shù)據(jù)庫中有1000本書。 現(xiàn)在，此代碼將執(zhí)行 1001 次查詢以檢索這1000本書的作者姓名。

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

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

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

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

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

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

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

如果這個排行榜數(shù)據(jù)的查詢次數(shù)是 1000次每小時，那么一天下來執(zhí)行的查詢次數(shù)就是24000次。
現(xiàn)在，讓我們假設(shè)這個排行榜是每小時更新一次 。那么，將每次的查詢結(jié)果緩存一小時如何 ？

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

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

查詢次數(shù) 從 24000 到 24 次/天 。

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

實現(xiàn)起來很簡單，您可以創(chuàng)建一個新的數(shù)據(jù)庫遷移并使用里面的方法來添加索引.

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

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

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

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

有些時候，Laravel 比預(yù)期慢，這時你可以考慮異步執(zhí)行任務(wù)。

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

用戶填寫我們的表單；

將他/她的詳細信息寫入數(shù)據(jù)庫；

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

并展示感謝頁面；

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

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

*

上面我寫了一些跟隊列有關(guān)的內(nèi)容。有時，你也可以使用隊列來改善面向用戶的任務(wù)。

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

另一個經(jīng)常使用的示例是向用戶發(fā)送消息不需要刷新頁面。

考慮一下吧！

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

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

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

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

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

Laravel Telescope ： 另一個非?？岬墓ぞ呤?Laravel Telescope ，對 Laravel 應(yīng)用，有“優(yōu)雅的調(diào)試助手”的美稱。如果你感興趣， 我已經(jīng)在這里寫了一篇關(guān)于它的文章 ；

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

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

如果你的應(yīng)用程序數(shù)據(jù)量增長很大，你可以考慮為你的系統(tǒng)做服務(wù)拆分了。不過，這并沒有一個明確的方法指南來引導(dǎo)你完成它：拆分標(biāo)準(zhǔn)的高與低取決于來自應(yīng)用程序的領(lǐng)域到拆分所有必需的內(nèi)容所需的工作中的許多因素。

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

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

我非?？隙阌泻芏嗲岸说馁Y源，比如 CSS 文件和 JS 腳本。

你可以通過多種方式來減少發(fā)送給用戶的數(shù)據(jù)量：

壓縮靜態(tài)資源;

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

開啟 gzip 壓縮;

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

Akamai（阿卡邁）;

Max CDN;

Cloudflare;

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

譯者注：國內(nèi)可以使用又拍云和七牛云

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

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

New Relic;

AppOptics;

Datadog;

Sentry;

以上列表的應(yīng)用程序不做同樣的事情：他們被設(shè)計用于不同目的?；ㄐr間去學(xué)習(xí)他們以理解他們?nèi)绾翁峁椭?/p> 19. 垂直擴展

你已經(jīng)對代碼的細枝末節(jié)都進行了徹底優(yōu)化，但是你的應(yīng)用體量在不斷增長。遲早你都要進行垂直擴展。

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

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

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

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

并非所有的應(yīng)用都可以在短時間內(nèi)擴展完畢，有時候你需要重構(gòu)隔離一些代碼；有時候你需要把應(yīng)用拆分為不同規(guī)模的小型服務(wù)。

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

今天有足夠的內(nèi)容了！我通過合并我的個人經(jīng)驗和以前做過的一些研究創(chuàng)建了在這個列表。

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

轉(zhuǎn)自 https://learnku.com/laravel/t...