80

前言

Swoole内核团队开设的专栏,会逐渐投入精力写文章介绍Swoole的开发历程,实现原理,应用实践等,大家可以更好的交流,共同学习,建设PHP生态。

协程调度

去年Swoole推出了4.0版本后,完整的支持PHP协程,我们可以基于协程实现CSP编程,身边的开发者惊呼,原来PHP代码还可以这样写。Swoole的协程默认是基于IO调度,程序中有阻塞会自动让出当前协程,协程的各种优势我们不在这里展开讨论。如果是IO密集型的场景,可以表现得很不错。但是对于CPU密集型的场景,会导致一些协程因为得不到CPU时间片被饿死。

抢占式调度

我们在今年年初就计划实现Swoole的抢占式调度,以满足实现有些场景下的不均衡调度带来的问题。我们中间经历了几个版本,在这里和大家分享一下开发过程中的动机和解决办法。

图片描述

我们目的是为了均衡调度每个协程的CPU时间,比如协程3需要比较长的执行时间,我们必须把协程3的CPU时间主动中断,而不依赖IO事件,使得每个协程得到平均的执行时间。

起初,我们的想法是可以从PHP的循环中自动检测执行实践,若达到限制,可以自动让出当前协程。因为毕竟很少有人一马平川的写出占用很多CPU的代码,大都通过循环条件来控制。我们hook循环指令,每次执行循环指令的时候,都来检查协程的执行时间,我们很欣喜的得到了最初的版本。但是这样做比较hack,而且opcode经过opcache优化后,情况会变得有些复杂。

后来我们使用PHPticks机制,也就是在PHP代码编译期间,注入ticks指令,可以执行相应的函数,我们可以在这些函数中检测处理协程的时间,达到抢占式的效果,但是这里有一个问题,PHPdeclare(ticks=N)语法,只对当前脚本范围有效,也就是说项目稍微大点,require或者include进来的脚本,并不会自动注入ticks指令,这样Swoole开发者几乎是无法接受的。我们也试图给PHP官方提一个PR,可以在扩展层设置一个全局默认的ticks,但是官方不愿意采纳我们的提交,因为官方觉得这个功能对性能损耗比较大,而且有可能在PHP8移除这个功能。其实经过实测这个性能损耗并不大,而且我们已经在生产环境验证,并取得了显著的效果,即可以让出某些CPU密集的逻辑部分,使得服务整个相应时间更加均衡。
下图是我们生产环境一个RPC接口的调用端统计数据对比,客户端等待超时时间为2s,超时则统计为错误。
图片描述
左边一侧是没有抢占式调度,右侧是开了抢占式调度,可以发现,左侧总是会有偶尔超时情况,而经过优化之后,没有一个超时的请求,请求响应时间非常平滑,提升了服务的稳定性。
图片描述
可以从上图看出,由于抢占式调度的加入,去除了请求耗时高的毛刺,使得平均请求时间变得更加平滑,稳定。

想要做抢占式调度,对于PHP来说,有两个途径

  1. 单线程的PHP的执行流,通过执行指令做文章,可以在PHP执行流程中注入逻辑,以检查执行时间,再加上Swoole的协程能力,可以在不同的协程中切换,以达到抢占CPU的目的。
  2. 考虑开线程,负责检查当前执行协程执行时间。

经过以上办法的尝试,注入指令的路数基本是无法得到官方的支持,我们只能另谋出路,多开一个线程,只负责检查当前协程。具体的做法是,利用PHP-7.1.0引入的VM interrupt机制,默认每隔5ms检查一下当前协程是否达到最大执行时间,默认为10ms,如果超过,则让出当前协程,达到被其他协程抢占的目的。

示例代码

需要Swoole 4.4或更高版本
<?php
ini_set("swoole.enable_preemptive_scheduler","1");
$start = microtime(1);
echo "start\n";
$flag = 1;

go(function () use (&$flag) {
    echo "coro 1 start to loop\n";
    $i = 0;
    for (;;) {
        if (!$flag) {
            break;
        }
        $i++;
    }
    echo "coro 1 can exit\n";
});
    
$end = microtime(1);
$msec = ($end - $start) * 1000;
echo "use time $msec\n";
go(function () use (&$flag) {
    echo "coro 2 set flag = false\n";
    $flag = false;
});
echo "end\n";

执行结果

start
coro 1 start to loop
use time 11.121988296509
coro 2 set flag = false
end
coro 1 can exit

可以发现,代码逻辑可以从第一个协程的死循环中自动yield出来,执行第二个协程,如果没有这个特性,第二个协程永远不会被执行,导致被饿死。而这样做,第二个协程可以顺利被执行,最后执行结束后,第一个协程也会接着继续往下执行。达到我们的第二个协程主动抢占第一个协程CPU的效果。

这个特性在生产环境非常有用,尤其是对于实时系统或者响应时间比较敏感的场景。

最后

感谢大家对 Swoole 的长期支持和关注。


石光启
331 声望30 粉丝

16

引用和评论

16 条评论
头像
AShin

为什么我按照你的代码去实际测试,还是会一直停留在第一个协程

2019-05-22
石光启(作者)

@AShin pull Swoole master分支更新一下呢

2019-05-22
AShin

@AShin enable_preemptive_scheduler 这个参数我在文档里没有找到,这个是啥意思纳?还有就是分支更新下我swoole是下载最新的版本的

2019-05-22
石光启(作者)

@AShin 文档已经更新,意思是,打开协程抢占式调度开关。

2019-05-22
头像
jlzan1314

php 好起来了..一个死循环的协程,无法对其他的协程产生影响.

2019-05-22
头像
我不叫大脸猫

厉害了,swoole的协程越来越完善了

2019-05-22
头像
skylee

666

2019-05-22
头像
davidyanxw

有超时机制的协程。
功能很赞。
问下,轮循检查会带来性能损失嘛?大概有多少?

2019-05-22
石光启(作者)

@davidyanxw 基本没有损耗,是利用多线程和vm中断机制来中断php执行的,并不是轮循机制。

2019-05-23
头像
beleveme

这个用例跑的起来吗?
使用master代码编译了一个swoole
看了一下官方的一个开启的方式
Co::set(['enable_preemptive_scheduler' => 1]);
ini_set("swoole.enable_preemptive_scheduler","1");
SwooleCoroutine::enableScheduler();
都不能正常的运行!

2019-06-19
石光启(作者)

@beleveme ini_set("swoole.enable_preemptive_scheduler","1"); 打开开关,Swoole完整的有测试用例,可以查看 https://github.com/swoole/swo...
感谢支持Swoole~

2019-06-20
beleveme

@beleveme @石光启 非常感谢, 昨天同样的代码, 今天测试确实可以生效了! 好神奇!

2019-06-20
头像
hurryking

赞,能更新下文档吗,文档里的例子太旧了,还是基于declare tick (http://wiki.swoole.com/wiki/p...

2020-02-08
头像
nick

可以修改协程超时时间吗?

2020-02-28