如何優化PHP和Laravel以提高Web應用的性能

這篇文章主要講解了“如何優化PHP和Laravel以提高Web應用的性能”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何優化PHP和Laravel以提高Web應用的性能”吧！

四種類型的優化

在我看來，優化可以在四個不同的層面上進行（當涉及到PHP應用時，就是）：

• 語言層面：這意味著你使用更快的語言版本，并避免語言中特定的功能/編碼風格，使你的代碼速度變慢。

• 框架層面：這些是我們在本文中要涉及的內容。

• 基礎設施層面：調整你的 PHP 進程管理器、Web 服務器、數據庫等。

• 硬件層面：轉向更好、更快、更強大的硬件主機提供商。

所有這些類型的優化都有其存在的意義（例如，php-fpm 的優化是非常關鍵和強大的）。但本文的重點是純粹的第 2 類優化：那些與框架相關的優化。

要注意 n+1 數據庫查詢

n+1 查詢問題是使用 ORM 時常見的問題。Laravel 有其強大的 ORM，叫 Eloquent，它是如此的漂亮，如此的方便，以至于我們常常忘記了看是怎么回事。

考慮一個非常常見的場景：顯示指定客戶列表下的所有訂單。這在電子商務系統和任何需要顯示與某些實體相關的所有實體的列表中非常常見，

我們可以想象有這樣一個控制器：

class OrdersController extends Controller
{
    // ...

    public function getAllByCustomers(Request $request, array $ids) {
        $customers = Customer::findMany($ids);
        $orders = collect(); // new collection

        foreach ($customers as $customer) {
            $orders = $orders->merge($customer->orders);
        }

        return view('admin.reports.orders', ['orders' => $orders]);
    }
}

太好了！更重要的是，優雅，美麗。??

不幸的是，用 Laravel 編寫這樣的代碼是一種災難性的方法。

原因如下。

當我們使用 ORM 查找給定的客戶實體時，會生成這樣一個SQL查詢語句：

SELECT * FROM customers WHERE id IN (22, 45, 34, . . .);

這與預期的完全一致。結果，所有返回的行都被存儲在控制器函數中的集合 $customers 中。

現在我們逐一循環處理每個客戶，并獲取他們的訂單。這將執行下面的查詢……

SELECT * FROM orders WHERE customer_id = 22;

……有多少客戶就有多少次。

換句話說，如果我們需要獲取 1000 個客戶的訂單數據，那么執行的數據庫查詢總數將是1（用于獲取所有客戶的數據）+1000（用于獲取每個客戶的訂單數據）=1001。這就是 n+1 這個名字的由來。

我們可以做得更好嗎? 當然可以！ 通過使用預加載，我們可以強制 ORM 執行 JOIN，并在一次查詢中返回所有需要的數據！ 就像這樣：

$orders = Customer::findMany($ids)->with('orders')->get();

由此產生的數據結構是一個嵌套結構，當然，但訂單數據可以很容易地提取出來。在這種情況下，產生的單個查詢是這樣的。

SELECT * FROM customers INNER JOIN orders ON customers.id = orders.customer_id WHERE customers.id IN (22, 45, ...);

當然，一次查詢比多查詢一千次要好。想象一下，如果有一萬個客戶要處理，會發生什么情況！或者說，如果我們還想顯示每個訂單中包含的項目，那簡直就是天方夜譚！記住，這個技術的名字叫預加載，它幾乎在任何時候都能派上用場。

緩存配置！

Laravel 的靈活性的原因之一是它有大量的配置文件， 這些文件是框架的一部分。想要改變圖片的存儲方式/位置？

好吧，只要修改 config/filesystems.php 文件就可以了（至少寫到這里）。想要使用多個隊列驅動？可以在 config/queue.php 中隨意描述。我剛剛統計了一下，發現針對框架的不同方面有 13 個配置文件，保證你無論想改什么都不會失望。鑒于 PHP 的特性，每當一個新的 Web 請求進來，Laravel 就會被喚醒， 啟動所有的東西， 并解析所有的配置文件來找出這次該如何做不同的事情。 如果這幾天什么都沒變，那就太傻了！每次請求都要重建配置文件是一種浪費，這是可以 (實際上，必須) 避免的，解決的辦法是 Laravel 提供的一個簡單的命令：

php artisan config:cache

這樣做的目的是把所有可用的配置文件合并成一個文件，并緩存在某個地方以便快速檢索。 下一次有 Web 請求的時候，Laravel 會簡單地讀取這個單一的文件并開始工作。

也就是說，配置緩存是一個極其微妙的操作，可能會在你的面前炸開。最大的陷阱是一旦你發出這個命令，除了配置文件之外，其他地方的 env() 函數調用都會返回 null！

仔細想想確實有道理。如果你使用配置緩存，你就是在告訴框架：「你知道嗎，我覺得我已經把東西設置得很好了，我 100% 確定我不希望它們改變。」 換句話說，你希望環境保持靜態，這就是 .env 文件的作用。

說到這里，這里有一些鐵定的、神圣的、不可違背的配置緩存規則：

• 只在生產系統上做。

• 只有在你非常非常確定要凍結配置的情況下才做。

• 萬一出了問題，用 php artisan cache:clear 撤銷設置。

• 祈禱對企業造成的損失不是很大！

減少自動加載的服務

為了幫助大家, Laravel在喚醒時加載了大量的服務, 這些服務在 config/app.php 文件中作為 'providers' 數組鍵的一部分。讓我們來看看我的情況：

/*
    |--------------------------------------------------------------------------
    | Autoloaded Service Providers
    |--------------------------------------------------------------------------
    |
    | The service providers listed here will be automatically loaded on the
    | request to your application. Feel free to add your own services to
    | this array to grant expanded functionality to your applications.
    |
    */

    'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        Illuminate\Auth\AuthServiceProvider::class,
        Illuminate\Broadcasting\BroadcastServiceProvider::class,
        Illuminate\Bus\BusServiceProvider::class,
        Illuminate\Cache\CacheServiceProvider::class,
        Illuminate\Foundation\Providers\ConsoleSupportServiceProvider::class,
        Illuminate\Cookie\CookieServiceProvider::class,
        Illuminate\Database\DatabaseServiceProvider::class,
        Illuminate\Encryption\EncryptionServiceProvider::class,
        Illuminate\Filesystem\FilesystemServiceProvider::class,
        Illuminate\Foundation\Providers\FoundationServiceProvider::class,
        Illuminate\Hashing\HashServiceProvider::class,
        Illuminate\Mail\MailServiceProvider::class,
        Illuminate\Notifications\NotificationServiceProvider::class,
        Illuminate\Pagination\PaginationServiceProvider::class,
        Illuminate\Pipeline\PipelineServiceProvider::class,
        Illuminate\Queue\QueueServiceProvider::class,
        Illuminate\Redis\RedisServiceProvider::class,
        Illuminate\Auth\Passwords\PasswordResetServiceProvider::class,
        Illuminate\Session\SessionServiceProvider::class,
        Illuminate\Translation\TranslationServiceProvider::class,
        Illuminate\Validation\ValidationServiceProvider::class,
        Illuminate\View\ViewServiceProvider::class,

        /*
         * Package Service Providers...
         */

        /*
         * Application Service Providers...
         */
        App\Providers\AppServiceProvider::class,
        App\Providers\AuthServiceProvider::class,
        // App\Providers\BroadcastServiceProvider::class,
        App\Providers\EventServiceProvider::class,
        App\Providers\RouteServiceProvider::class,

    ],

我再一次數了數，一共列出了 27 項服務！ 現在，你可能需要所有的服務，但不太可能。

例如，我現在正好在構建一個 REST API，這意味著我不需要 Session Service Provider、View Service Provider 等。而且由于我是按照自己的方式來做一些事情，而不是按照框架的默認值來做，所以我也可以禁用 Auth Service Provider、Pagination Service Provider、Translation Service Provider 等。總而言之，對于我的用例來說，這些幾乎有一半是不必要的。

仔細審視一下你的應用吧。它是否需要所有這些服務提供者？但是看在上帝的份上，請不要盲目地注釋掉這些服務，然后推送到生產中去！ 運行所有的測試，在開發機和暫存機上手動檢查，并且在扣動扳機之前要非常非常偏執。

明智地使用中間件堆棧。

當你需要對傳入的 Web 請求進行一些自定義處理時，創建一個新的中間件就是答案。現在，打開 app/Http/Kernel.php 并將中間件粘在 web 或 api 堆棧中是很有誘惑力的；這樣一來，它就會在整個應用程序中變得可用，而且如果它沒有做一些侵入性的事情（例如，像日志或通知）。

然而，隨著應用程序的增長，如果所有（或大多數）這些全局中間件都存在于每個請求中，那么這個全局中間件的集合可能會成為應用程序的一個無聲負擔，即使沒有業務原因。

換句話說，要小心你在哪里添加/應用新的中間件。在全局范圍內添加一些東西可能會更方便，但從長遠來看，性能懲罰是非常高的。我知道如果每次有新的變化都要有選擇地應用中間件，你要承受的痛苦，但這是我心甘情愿承受的痛苦，也是我所推薦的!

避免使用 ORM (有時)

雖然 Eloquent 讓 DB 交互的很多方面變得愉悅，但它是以速度為代價的。作為一個映射器，ORM 不僅要從數據庫中獲取記錄，還要實例化模型對象，并用列數據對其進行填充。

所以，如果你做一個簡單的 $users = User::all()，比如有10000個用戶，框架會從數據庫中獲取 10000 行記錄，并在內部做 10000 個 new User()，并用相關數據填充他們的屬性。這是大量的工作在幕后進行，如果數據庫是你的應用成為瓶頸的地方，繞過 ORM 有時是個好主意。

這對于復雜的 SQL 查詢來說尤其如此，在這種情況下，你必須跳很多的圈子，寫一個又一個的閉包，但最終還是能得到一個高效的查詢。在這種情況下，最好做一個 DB::raw()，然后手工寫查詢。

根據 這個 的性能研究, 即使是簡單的插入， Eloquent 也會隨著記錄數量的增加而變慢

盡量使用緩存

Web 應用優化中最保守的秘密之一就是緩存。

對于新手來說，緩存的意思是預先計算和存儲昂貴的結果(昂貴的 CPU 和內存使用量)，并在重復相同的查詢時簡單地返回。

例如，在一個電商商店里，可能會遇到，在 200 萬種產品中，大多數時候人們都會對那些新鮮出爐的、在一定價格范圍內的、針對特定年齡段的產品感興趣。在數據庫中查詢這些信息是很浪費的——因為查詢的內容不會經常變化，所以最好把這些結果存儲在我們可以快速訪問的地方。

Laravel 內置支持多種類型的緩存。除了使用緩存驅動和從底層構建緩存系統外，你可能還想使用一些Laravel 包，方便模型緩存、查詢緩存等。

但是請注意, 在一定的簡化用例之外, 預制的緩存包可能會帶來更多的問題, 而不是解決這些問題.

優先選擇內存緩存

當你在 Laravel 中緩存一些東西時， 你有幾個選項可以選擇將需要緩存的計算結果存儲在哪里。這些選項也被稱為 緩存驅動。所以， 雖然使用文件系統來存儲緩存結果是可能的，也是完全合理的，但這并不是緩存的真正目的。

理想情況下，你希望使用內存中（完全活在 RAM 中）的緩存，比如 Redis、Memcached、MongoDB 等，這樣在較高的負載下，緩存就能起到至關重要的作用，而不是自己成為瓶頸。

現在，你可能會認為擁有 SSD 磁盤和使用 RAM 棒幾乎是一樣的，但還差得遠。即使是非正式的 基準測試也顯示，在速度方面，RAM優于SSD的10-20倍。

在緩存方面，我最喜歡的系統是 Redis。它的速度 快得離譜(每秒 10 萬次讀取操作是很常見的)，對于非常大的緩存系統，可以很容易地演變成一個 集群。

緩存路由

就像應用程序的配置一樣，路由不會隨著時間的推移而改變，是緩存的理想選擇。如果你像我一樣無法忍受大文件，并且最終把你的 web.php和 api.php 分割成幾個文件的話，這一點尤其適用。 一個簡單的Laravel命令就可以把所有可用的路由打包并保存起來， 方便以后的訪問:

php artisan route:cache

而當你最終要增加或改變路由時，只需這樣做即可。

php artisan route:clear

圖像優化和 CDN

圖片是大多數網絡應用的核心和靈魂。巧合的是，它們也是最大的帶寬消耗者，也是導致應用程序/網站速度慢的最大原因之一。如果你只是簡單地將上傳的圖片天真地存儲在服務器上，然后以 HTTP 響應的方式發送回來，你就會讓一個巨大的優化機會溜走。

我的第一個建議是不要在本地存儲圖片——有數據丟失的問題要處理，而且取決于你的客戶在哪個地理區域，數據傳輸可能會非常緩慢。

相反，選擇像 Cloudinary 這樣的解決方案，它可以自動動態調整和優化圖像的大小。

如果這不可能，使用類似 Cloudflare 的東西來緩存和服務圖像，同時它們存儲在你的服務器上。

如果連這一點都做不到，調整一下你的網絡服務器軟件，壓縮資產并引導訪問者的瀏覽器去緩存東西，就會有很大的不同。下面是一個 Nginx 配置的片段。

server {

   # file truncated

    # gzip compression settings
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_proxied any;
    gzip_vary on;

   # browser cache control
   location ~* \.(ico|css|js|gif|jpeg|jpg|png|woff|ttf|otf|svg|woff2|eot)$ {
         expires 1d;
         access_log off;
         add_header Pragma public;
         add_header Cache-Control "public, max-age=86400";
    }
}

我知道圖片優化與 Laravel 無關， 但這是一個如此簡單而強大的技巧 (而且經常被忽視)， 所以我忍不住了。

自動加載器優化

自動加載是 PHP 中一個整潔的、并不古老的功能，它可以說是拯救了這門語言的末日。盡管如此，通過破譯給定的命名空間字符串來尋找和加載相關類的過程是需要時間的，在生產部署中，如果需要高性能，可以避免這個過程。 再一次，Laravel 有一個單一命令的解決方案來解決這個問題:

composer install --optimize-autoloader --no-dev

與隊列交朋友

隊列 是指當有很多事情時，你如何處理這些事情，而且每件事情都需要幾毫秒才能完成。一個很好的例子是發送電子郵件——在網絡應用中，一個廣泛的用例是當用戶執行一些操作時，發出幾封通知郵件。

例如，在一個新推出的產品中，你可能希望每當有人下單超過一定值時，公司領導層（大約6-7個電子郵件地址）就會收到通知。假設你的郵件網關能在500ms內響應你的SMTP請求，那么在訂單確認啟動之前，用戶需要等待3-4秒。一個非常糟糕的用戶體驗，我相信你會同意。

補救的辦法是在任務進來的時候就把它們存儲起來，告訴用戶一切都很順利，然后再處理它們（幾秒鐘）。如果出現錯誤，在宣布失敗之前，排隊的任務可以重試幾次。

雖然隊列系統使設置復雜化了一些 (并增加了一些監控開銷)， 但它在現代Web應用中是不可缺少的。

資源優化 (Laravel Mix)

對于你的 Laravel 應用中的任何前端資源，請確保有一個管道可以編譯和最小化所有的資源文件。 那些對 Webpack，Gulp，Parcel 等打包器系統很熟悉的人不需要費心，但如果你還沒有這樣做，Laravel Mix是一個可靠的推薦。

Mix 是一個輕量級的 (老實說,很討人喜歡！) 圍繞Webpack的打包器，它可以處理你所有的 CSS，SASS，JS 等文件。 一個典型的 .mix.js 文件可以像這樣小，但仍然可以發揮出巨大的作用。

const mix = require('laravel-mix').mix.js('resources/js/app.js', 'public/js');

mix.js('resources/js/app.js', 'public/js')
    .sass('resources/sass/app.scss', 'public/css');

當您準備部署生產環境并運行 npm run production 時，它將自動處理導入，最小化，優化以及整個工作流程。 Mix 不僅關心傳統的 JS和 CSS 文件，而且還關心您在應用程序工作流程中可能使用的 Vue 和 React 組件。

感謝各位的閱讀，以上就是“如何優化PHP和Laravel以提高Web應用的性能”的內容了，經過本文的學習后，相信大家對如何優化PHP和Laravel以提高Web應用的性能這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！