4.13 實現原理 · swoole文檔

# 實現原理 `Swoole-2.0`基于`setjmp`、`longjmp`實現，在進行協程切換時會自動保存`Zend VM`的內存狀態（主要是`EG`全局內存和`vm stack`）。 * `setjmp`和`longjmp`主要是用于從`ZendVM`的`C`堆棧跳回`Swoole`的`C`回調函數 * 協程的創建、切換、掛起、銷毀全部為內存操作，消耗是非常低的 `Swoole-4.0`重構了協程內核，實現了`C`棧和`PHP`棧同時保存和切換，支持所有`PHP`語法。示例代碼 ---- ```php $server = new Swoole\Http\Server('127.0.0.1', 9501, SWOOLE_BASE); #1 $server->on('Request', function($request, $response) { $mysql = new Swoole\Coroutine\MySQL(); #2 $res = $mysql->connect([ 'host' => '127.0.0.1', 'user' => 'root', 'password' => 'root', 'database' => 'test', ]); #3 if ($res == false) { $response->end("MySQL connect fail!"); return; } $ret = $mysql->query('show tables', 2); $response->end("swoole response is ok, result=".var_export($ret, true)); }); $server->start(); ``` * 此程序僅啟動了一個1個進程，就可以并發處理大量請求。 * 程序的性能基本上與異步回調方式相同，但是代碼完全是同步編寫的運行過程 ---- * 調用`onRequest`事件回調函數時，底層會調用C函數`coro_create`創建一個協程（#1位置），同時保存這個時間點的CPU寄存器狀態和ZendVM stack信息。 * 調用`mysql->connect`時發生IO操作，底層會調用C函數`coro_save`保存當前協程的狀態，包括Zend VM上下文以及協程描述信息，并調用`coro_yield`讓出程序控制權，當前的請求會掛起（#2位置） * 協程讓出程序控制權后，會繼續進入EventLoop處理其他事件，這時Swoole會繼續去處理其他客戶端發來的Request * IO事件完成后，MySQL連接成功或失敗，底層調用C函數`coro_resume`恢復對應的協程，恢復ZendVM上下文，繼續向下執行PHP代碼（#3位置） * `mysql->query`的執行過程與`mysql->connect`一致，也會進行一次協程切換調度 * 所有操作完成后，調用`end`方法返回結果，并銷毀此協程協程開銷 ---- 相比普通的異步回調程序，協程多增加額外的內存占用。 * Swoole2.0協程需要為每個并發保存zend stack棧內存并維護對應的虛擬機狀態。如果程序并發很大可能會占用大量內存，取決于C函數、ZendVM 調用棧深度 * 協程調度會增加額外的一些CPU開銷壓力測試 ---- * 環境：`Ubuntu16.04 + Core I5 4核 + 8G內存 PHP7.0.10` * 腳本：`ab -c 100 -n 10000 http://127.0.0.1:9501/` 測試結果： ```shell Server Software: swoole-http-server Server Hostname: 127.0.0.1 Server Port: 9501 Document Path: / Document Length: 348 bytes Concurrency Level: 100 Time taken for tests: 0.883 seconds Complete requests: 10000 Failed requests: 168 (Connect: 0, Receive: 0, Length: 168, Exceptions: 0) Total transferred: 4914560 bytes HTML transferred: 3424728 bytes Requests per second: 11323.69 [#/sec] (mean) Time per request: 8.831 [ms] (mean) Time per request: 0.088 [ms] (mean, across all concurrent requests) Transfer rate: 5434.67 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 2 Processing: 0 9 9.6 6 96 Waiting: 0 9 9.6 6 96 Total: 0 9 9.6 6 96 Percentage of the requests served within a certain time (ms) 50% 6 66% 9 75% 11 80% 12 90% 19 95% 27 98% 43 99% 51 100% 96 (longest request) ```