首先，我認為通過返回最基本的Hello world!字串，是所有以Laravel為框架的專案中，最基本的一個請求過程。除此以外，專案中的任何http請求，都會帶有更多的業務邏輯和資料庫查詢等耗時操作，且這些邏輯的執行時間都是不可控和不可對比的。也就是說，其他任何請求都不會比返回一個Hello world!字串更短的時間了。所以，通過對比這個最基本的Hello world請求響應時間，我們可以看出，不同的優化對於Laravel框架從啟動到執行結束的影響。
| 引數 | 版本 |
|---|---|
| 伺服器 | 1c處理器，1G記憶體，1M頻寬 |
| PHP版本 | 8.0 |
| 程式管理 | PHP-FPM |
可以看出，在安裝PHP後，預設配置情況下，返回一個Hello world!平均需要140ms左右。接下來，我們開始搞事情了！
Laravel為我們提供了很方便的artisan命令來開啟快取功能，有效的減少了檔案讀取次數。其中php artisan optimize命令包括了php artisan config:cache和php artisan route:cache命令，但是會多出現一個Files快取。將下面的 5 個命令一次執行：
root@Aliyun-ECS / # php artisan optimize
root@Aliyun-ECS / # php artisan config:cache
root@Aliyun-ECS / # php artisan event:cache
root@Aliyun-ECS / # php artisan route:cache
root@Aliyun-ECS / # php artisan view:cache我們再看下響應時間：
可見Laravel的快取對於最基礎的請求，沒有明顯的影響。
這次，我決定使用提速效果最明顯的手段：開啟opcache擴充套件。由於本人是使用的 remi 源安裝的php8，所以我這裡安裝opcache擴充套件會比較容易，其他版本的安裝請自行 Google。
root@Aliyun-ECS / # yum install php80-php-opcache等待安裝結束後，我們重啟php，然後看下擴充套件是否已經安裝上：
root@Aliyun-ECS / # systemctl restart php80-php-fpm
root@Aliyun-ECS / # php -i|grep opcache.enable
opcache.enable => On => On
opcache.enable_cli => On => On
opcache.enable_file_override => Off => Offok，已經開啟opcache擴充套件了，我門再來看下Hello world!的響應時間：
OHHHHHH！效果太明顯了，一下子降到 30ms 以內，提升足足有將近 5 倍 的響應時間。注意一下，在第一次請求時，會比較慢，是因為opcache在寫快取導致的，訪問過一次以後，速度就飛起了。到這裡你就滿足了嗎？看看文章標題，我們要進一步加大力度！
swoole模組大家都懂，就是將應用程式提前載入到記憶體中，從而在處理請求時，減少檔案的讀取和載入過程，為PHP插上了翅膀。下面安裝swoole擴充套件，其他版本的請自行 Google。
root@Aliyun-ECS / # yum install php80-php-pecl-swoole老樣子，安裝完後檢查下是否安裝成功：
root@Aliyun-ECS / # systemctl restart php80-php-fpm
root@Aliyun-ECS / # php -i|grep swoole.enable
swoole.enable_coroutine => On => On
swoole.enable_library => On => On
swoole.enable_preemptive_scheduler => Off => Off再看下請求的響應時間：
好傢伙！直接幹到15ms以內。這裡第一次時間較長，是因為開了opcache的原因，會寫入快取。但這裡的opcache寫快取，要比Round 2那個只開啟opache擴充套件要快很多，這都是swoole的功勞。
我又測試了一下，單獨只啟用swoole擴充套件，不啟用opcache，發現響應時間和兩個擴充套件都開啟的響應時間一樣。也就是說，有了swoole後，opcache就沒用了？這個還得請各位大佬指點了。這裡簡單的做個對比：
通過實踐對比，發現同時開啟opcache和swoole擴充套件，是響應時間最快的。
本作品採用《CC 協議》，轉載必須註明作者和本文連結