Swoole Coroutine协程支持

方法列表

getDefer()

bool getDefer();

• 返回值：返回当前设置的defer

setDefer()

bool setDefer([bool $is_defer = true]);

• $is_defer：bool值，为true时，表明该Client要延迟收包，为false时，表明该Client非延迟收包，默认值为true
• 返回值：设置成功返回true，否则返回false。只有一种情况会返回false，当设置defer(true)并发包后，尚未recv()收包，就设置defer(false)，此时返回false。
• 如果需要进行延迟收包，需要在发包之前调用

recv()

mixed recv();

• 返回值：获取延迟收包的结果，当没有进行延迟收包或者收包超时，返回false。

并发调用

Client并发请求

在协程版本的Client中，实现了多个客户端并发的发包功能。

通常，如果一个业务请求中需要做一次redis请求和一次mysql请求，那么网络IO会是这样子：

redis发包->redis收包->mysql发包->mysql收包

以上流程网络IO的时间就等于 redis网络IO时间 + mysql网络IO时间。

而对于协程版本的Client，网络IO可以是这样子：

redis发包->mysql发包->redis收包->mysql收包

以上流程网络IO的时间就接近于 MAX(redis网络IO时间, mysql网络IO时间)。

现在支持并发请求的Client有：

• Swoole\Coroutine\Client
• Swoole\Coroutine\Redis
• Swoole\Coroutine\MySQL
• Swoole\Coroutine\Http\Client

除了Swoole\Coroutine\Client，其他Client都实现了defer特性，用于声明延迟收包。

因为Swoole\Coroutine\Client的发包和收包方法是分开的，所以就不需要实现defer特性了，而其他Client的发包和收包都是在一个方法中，所以需要一个setDefer()方法声明延迟收包，然后通过recv()方法收包。

协程版本Client并发请求示例代码：

<?php
$server = new Swoole\Http\Server("127.0.0.1", 9502, SWOOLE_BASE);

$server->set([
    'worker_num' => 1,
]);

$server->on('Request', function ($request, $response) {

    $tcpclient = new Swoole\Coroutine\Client(SWOOLE_SOCK_TCP);
    $tcpclient->connect('127.0.0.1', 9501，0.5)
    $tcpclient->send("hello world\n");

    $redis = new Swoole\Coroutine\Redis();
    $redis->connect('127.0.0.1', 6379);
    $redis->setDefer();
    $redis->get('key');

    $mysql = new Swoole\Coroutine\MySQL();
    $mysql->connect([
        'host' => '127.0.0.1',
        'user' => 'user',
        'password' => 'pass',
        'database' => 'test',
    ]);
    $mysql->setDefer();
    $mysql->query('select sleep(1)');

    $httpclient = new Swoole\Coroutine\Http\Client('0.0.0.0', 9599);
    $httpclient->setHeaders(['Host' => "api.mp.qq.com"]);
    $httpclient->set([ 'timeout' => 1]);
    $httpclient->setDefer();
    $httpclient->get('/');

    $tcp_res  = $tcpclient->recv();
    $redis_res = $redis->recv();
    $mysql_res = $mysql->recv();
    $http_res  = $httpclient->recv();

    $response->end('Test End');
});
$server->start();

实现原理

Swoole2.0基于setjmp、longjmp实现，在进行协程切换时会自动保存Zend VM的内存状态（主要是EG全局内存和vm stack）。

示例代码

$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函数core_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/

测试结果：

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)