使用Laravel做開發(fā)是高效而愉悅的體驗。
通常，當你準備部署應用的時候，你可能會意識到應用也許會在真實環(huán)境下表現(xiàn)不佳。

需要明白的是，沒有銀彈。通過努力去對應用的每個細節(jié)完成所有的優(yōu)化，速度可能會變慢，但使用下面這些技巧會讓你感到恰到好處。

緩存配置文件

laravel 的配置項分布在數(shù)十個配置文件中，在每次的請求中都將每個文件 including 進來很消耗性能。為了將所有的配置文件都合并為一個，可以使用：

php artisan config:cache

記住修改了配置文件后不會影響已有的配置文件緩存。為了刷新緩存，可以再次上述的命令。如果你想完全清除緩存，執(zhí)行：

php artisan config:clear

路由緩存

在laravel中，路由也需要昂貴的開銷。用以下命令緩存 routes.php 文件:

php artisan route:cache

請注意，它不適用于閉包。 如果你正在使用閉包，這是一個很好的機會將它們移動到控制器中，因為 artisan 命令在嘗試編譯綁定到閉包的路徑而不是正確的控制器方法時會拋出異常。
與配置緩存相同，對 routes.php 的任何更改都不會有任何影響。 要刷新緩存，請在每次更改路徑文件時運行上面的命令。 要完全清理干凈路由緩存，請運行以下命令:

php artisan route:clear

類映射加載優(yōu)化

在一個中型項目中，存在數(shù)百個 PHP 源文件是很正常的事情，由于良好的編程習慣，我們會把代碼做一些分離，每一個 php 文件都有自己的職責。當然，這并非沒有缺點，Laravel 必須為每一次請求都加載這數(shù)百個文件，這是一件很消耗性能的事情。

因此，一個比較好的辦法是聲明哪些文件是用戶每一次請求（如：服務提供者，中間件等）都需要載入的 ，然后將這些需要每次加載的文件寫入同一個文件中，減少 include 文件的數(shù)量。

這類似于 javascript 將文件合并為一個沒有區(qū)別 （webpack, gulp），會減少游覽器會服務器的請求。

如果需要添加其他的源文件，可以在 config / compile.php 的files key中聲明。

當你把需要為每個請求都加載的文件設置好之后，它們就會寫入同一個文件中，減少加載文件的性能消耗

php artisan optimize --force

優(yōu)化 composer 的自動加載

這不僅適用于 laravel，而且適用于任何使用 composer 的應用程序。

我將首先解釋 PSR-4 自動加載器的工作原理，然后向您展示應該運行什么命令來優(yōu)化它。如果您對了解 composer 如何工作不感興趣，我建議您直接跳到關于控制臺命令的段落處。

當您向 compsoser 請求 App\Controllers\AuthController 類時，它首先在類映射中搜索直接關聯(lián)。classmap 是一個由類和文件組成的 1 到 1 關聯(lián)的數(shù)組。當然，由于您沒有手動將 Login 類及其相關文件添加到類映射中，composer 將繼續(xù)在命名空間中搜索。

因為 App 是一個 PSR-4 命名空間，默認情況下是與 Laravel 一起提供的，并且與 app/ 文件夾相關聯(lián)，所以 composer 將嘗試使用基本的字符串操作過程將 PSR-4 類名轉換為文件名。最后，它猜測 App\Controllers\AuthController 必須位于 AuthController.php 文件中，它位于 Controllers/ 文件夾中，恰巧的是，該文件夾正好位于名稱空間文件夾中，即 app/。

所有這些艱苦的工作只是為了得到 App\Controllers\AuthController 類存在于 app/Controllers/AuthController.php 文件中。為了讓 composer 掃描整個應用程序并創(chuàng)建類和文件的直接 1 對 1 關聯(lián)，運行以下命令:

composer dumpautoload -o

請記住，如果您已經運行了 php artisan optimize --force，那么您就不必再運行這個函數(shù)了。因為優(yōu)化命令已經告訴 composer 創(chuàng)建一個優(yōu)化的自動加載器。

JIT 編譯器（即時編譯器）

PHP 并不是天然就被計算機理解的。你不能把它編譯為字節(jié)碼然后讓計算機運行。PHP 必須要經過一個中介，像是 Zend 引擎，它會解釋 PHP 文件并執(zhí)行相應的 C 例程。如你所想，它的速度很慢。每次你的服務器執(zhí)行一個 PHP 文件，都必須把它轉換成 tokens —— 這個過程由 AST 解析器完成并解釋。不幸的是，解析器必須每次都編譯 PHP 文件，即使它每次都得到相同的結果。

為了讓你的應用速度更快，你需要一個 編譯一次，終生運行 的方法，而這就是一個 JIT 編譯器所做的事情。

對于 Laravel 所推薦使用的 JIT 編譯器是 HHVM，由 Facebook 創(chuàng)立并廣泛使用。Wikipedia、Etsy 和其他上千項目也在使用它。

使用更快的緩存和會話驅動

將 session 保存在文件中是種足夠快速而又優(yōu)雅的方法，自 PHP 開始的時代就在這樣做了。但是如果你追求性能，那么文件系統(tǒng)就是你需要注意的一件事，因為它很慢。一種更好的做法是將 cache 和 session 存儲在內存中，因為它提供了一種高效讀寫數(shù)據的方式。幸運的是，laravel 支持一些基于內存的 cache 和 session 驅動。

我的建議是使用 memcached 作為 cache 和 session 的驅動，但你可以選擇任何你喜歡的，只要它是基于內存工作的。

要更改 session 驅動，需要檢查以下文件中「driver」項：

app/config/session.php

要更改 cache 驅動，需要檢查以下文件中「driver」項：

app/config/cache.php

不要低估通過優(yōu)化查詢語句帶來的查詢速度的提升
就像你看到的，大部分優(yōu)化都是在不同的層面使用緩存。但當面臨數(shù)據庫優(yōu)化時，你不應該依賴緩存。緩存應是優(yōu)化查詢的最后手段。

緩存查詢結果

MySQL 不會替你做這件事，也不如你自己做的好。當然了你肯定不會把應用中每個查詢的結果都做緩存，看看數(shù)據統(tǒng)計，在應用程序中那些高頻率的查詢語句，它們真的有必要被頻繁地執(zhí)行？每 15 分鐘運行一次然后把相同的結果提供給用戶不是更好嗎？

在查詢構造器中移除了 removing方法是件好事（它曾經是個很好的功能，但不夠好 - 人們似乎高估了它的作用）。然后你可以更多地使用 Cache::remember 方法，就像這樣：

$posts = Cache::remember('index.posts', 30, function()

{

return Post::with('comments', 'tags', 'author', 'seo')->whereHidden(0)->get();

});

最新評論