1、Swoole
Swoole號稱從新定義了PHP,它是一個PHP擴展,使得PHP可使用異步的方式執行,就像node同樣,並且還能使用socket,爲PHP提供了一系列異步IO、事件驅動、並行數據結構功能。
Swoole4支持完整的協程編程模式,可使用徹底同步的代碼實現異步程序。PHP代碼無需額外增長任何關鍵詞,底層自動進行協程調度,實現異步IO 。
nodejs能實現的swoole幾乎都能實現,並且性能比nodejs更高,畢竟nodejs是單線程的沒法充分發揮cpu性能,swoole是多線程的能夠充分發揮cpu的性能。
Swoole高效跟傳統的web開發有什麼區別,除了傳統的LAMP/LNMP同步開發模式,swoole的異步開發模式是怎樣的,如何保持高效?php
2、傳統web開發模式
PHP web開發採用的方式是LAMP/LNMP架構,即Linux、Nginx,Mysql和PHP。這裏以nginx來舉例,大體結構爲:
html
當請求進入時,web server將請求轉交給PHP-FPM,PHP-FPM是一個進程池架構的FastCGI服務,內置PHP解釋器。FPM負責解釋執行PHP文件生成響應,最終返回給web server,展示至前端。PHP文件中實現了許多業務邏輯,包括Mysql和Nosql的訪問,調用第三方應用等等。
這樣的結構php-fpm和nginx的配合已經運行得足夠好,可是因爲php-fpm自己是同步阻塞進程模型,在請求結束後釋放全部的資源(包括框架初始化建立的一系列對象),致使PHP進程「空轉」(建立<-->銷燬<-->建立)消耗大量的CPU資源,從而致使單機的吞吐能力有限。前端
每次請求處理的過程都意味着一次PHP文件解析,環境設置等沒必要要的耗時操做PHP進程處理完即銷燬,沒法在PHP程序中使用鏈接池等技術實現性能優化。node
3、Swoole運行模式
針對傳統架構的問題,swoole從PHP擴展出發,解決了上述問題,對於swoole的進程模型,咱們已經瞭解過了。nginx
相比於傳統架構,Swoole進程模型最大的特色在於其多線程Reactor模式處理網絡請求,使得其能輕鬆應對大量鏈接。laravel
除此以外的優勢還包括:web
全異步非阻塞,佔用資源開銷小,程序執行效率高sql
程序運行只解析加載一次PHP文件,避免每次請求的重複加載apache
進程常駐,使得鏈接池和請求之間信息傳遞等的實現成爲可能編程
4、爲何要在 Swoole 上運行 Laravel?
Laravel框架啓動的時候須要加載不少文件,再加上其出了名的生態環境好,因此在開發過程當中咱們就會發現有很是多的已經造好的輪子,這也就使得Laravel的一次啓動的磁盤IO特別高(就是要加載不少文件嘛)
laravel生命週期須要在每次請求的時候都執行一遍。由於單個請求建立的環境在請求執行結束後會當即銷燬。
換句話說, 在傳統的 PHP 生命週期中, 爲了腳本執行而浪費了大量的時間去建立和銷燬資源。想象一下像 Laravel 這樣的框架, 在每次請求中須要加載多少文件? 同時也浪費了大量的 I/O 操做。
所以若是咱們利用 Swoole 內置一個應用級別的 Server, 而且全部腳本文件在加載一次以後即可以保存在內存中呢? 這就是爲何咱們須要嘗試在 Swoole 上運行 Laravel。 Swoole 能夠提供強大性能而 Laravel 則能夠提供優雅代碼結構使用。這倆兒真是完美組合 !
5、使用Swoole提高Laravel的性能
在現有的輪子中,感受下面這兩個仍是很是不錯的,能夠自行選擇
本人選擇了第一個來測試
使用composer安裝:
composer require swooletw/laravel-swoole
若是你使用的是laravel,那麼在 config/app.php 的 providers 數組中加上
SwooleTW\Http\LaravelServiceProvider::class,
若是你使用的是lumen,那麼在 bootstrap/app.php 中加入以下代碼
$app->register(SwooleTW\Http\LumenServiceProvider::class);
將配置文件導出到 config 目錄下
php artisan vendor:publish --provider="SwooleTW\Http\HttpServiceProvider"
而後能夠去 config/swoole_http.php 中配置信息
'server' => [ 'host' => env('SWOOLE_HTTP_HOST', '0.0.0.0'),//監放任意ip 'port' => env('SWOOLE_HTTP_PORT', '1215'), 'options' => [ 'pid_file' => env('SWOOLE_HTTP_PID_FILE', base_path('storage/logs/swoole_http.pid')), 'log_file' => env('SWOOLE_HTTP_LOG_FILE', base_path('storage/logs/swoole_http.log')), 'daemonize' => env('SWOOLE_HTTP_DAEMONIZE', 1),//1-程序將轉入後臺做爲守護進程運行 ], ],
swoole_http.php 裏還提供配置 providers 數組,
'providers' => [ // App\Providers\AuthServiceProvider::class, ]
由於使用swoole做爲http後,這些providers會被存到內存中,因此這裏配置的是每次請求都想要從新註冊和從新啓動的providers。
如今,你能夠執行如下的命令來啓動 Swoole HTTP 服務。
$ php artisan swoole:http start
而後你能夠看到如下信息:
Starting swoole http server... Swoole http server started: <http://0.0.0.0:1215>
如今能夠經過訪問 http://127.0.0.1:1215 來進入 Laravel 應用。
注意:該拓展是不支持熱啓動的,因此每次有代碼更新都要重啓服務 php artisan swoole:http restart
6、性能測試
使用Apache的ab測試工具
ab -n 1000 -c 10 http://127.0.0.1:1215/
參數說明:-n 1000個請求 -c 10個併發數
圖一是使用swoole做爲應用服務器,圖二是apache服務器
測試環境在虛擬機中,電腦配置也較差,性能沒有徹底發揮出來,能夠看到apache只完成197次請求就扛不住壓力了,swoole HTTP服務 完成了壓測,性功徹底碾壓apache服務器。
7、使用Nginx代理
swoole在官網也提到過:swoole_http_server對Http協議的支持並不完整,建議僅做爲應用服務器。而且在前端增長Nginx做爲代理。
那麼,咱們就增長鬚要配置nginx.conf裏的server:
server { listen 80; server_name your.domain.com; root /path/to/laravel/public; index index.php; location = /index.php { # Ensure that there is no such file named "not_exists" # in your "public" directory. try_files /not_exists @swoole; } location / { try_files $uri $uri/ @swoole; } location @swoole { set $suffix ""; if ($uri = /index.php) { set $suffix "/"; } proxy_set_header Host $host; proxy_set_header SERVER_PORT $server_port; proxy_set_header REMOTE_ADDR $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # IF https # proxy_set_header HTTPS "on"; proxy_pass http://127.0.0.1:1215$suffix; } }
配置可參考swoole方文檔官 Nginx/Apache配置
至此,大功告成,你能夠像日常同樣訪問你的網站了。
8、使用swoole和傳統php開發的缺點
本文主要介紹了使用swoole做爲laravel的應服務器,最後說下使用swoole和傳統php開發的缺點。
一、更難上手。這要求開發人員對於多進程的運行模式有更清晰的認識
二、更容易內存泄露。在處理全局變量,靜態變量的時候必定要當心,這種不會被GC清理的變量會存在整個生命週期中,若是沒有正確的處理,很容易消耗完全部的內存。在php-fpm下,php代碼執行完內存就會被徹底釋放。
參考連接:在Laravel中使用swoole來取代nginx做爲http服務器,使用swoole加速你的laravel應用