存档

‘Swoole扩展’ 分类的存档

PHP+Swoole的闭包写法

2016年10月25日 评论已被关闭

JS程序员总是嘲笑PHP没有闭包,今天抽空写一篇文章来专门介绍一下PHP的闭包。从5.3版本开始PHP就增加了匿名函数支持,经过数个版本迭代到现在的PHP5.6、PHP7,PHP语言的闭包已经非常完善了。再结合Swoole提供的事件驱动支持,PHP的闭包功能非常强大而且很优雅。

匿名函数

匿名函数是闭包的核心,匿名函数在PHP里实际上是一个Closure类的对象(请注意是对象)。与普通的面向对象编程方式不同,匿名函数的代码是直接写在调用处的,不需要额外写一个类,编写方法的代码。这样的好处就是更直接。下面的示例是设置一个定时器,每2秒输出hello world。

传统写法

function timer () {
    echo "hello world";
}
Swoole\Timer::tick(2000, 'timer');

闭包写法

Swoole\Timer::tick(2000, function () {
    echo "hello world";
});

非闭包的传统写法,先要声明一个函数,再转入函数名称字符串。两段代码是分离的,不够直观。而闭包的写法把定时器的声明和定时器要执行的代码写在了一起,逻辑非常清晰直观。使用闭包语法可以很方便编写回调函数。在事件驱动编程、排序、array_walk等需要用户传入一段执行代码的场景中,闭包的写法非常优雅。

闭包更强大的地方在于它可以直接在调用处引入外部变量。PHP中实现的方法就是use关键词。

Use语法

如果刚才的定时器需要传入一个变量,传统的写法只能通过全局变量来实现。与JS不同,PHP的变量引入是显式的,如果要引用外部变量必须使用use来声明。而JS是隐式的,匿名函数内部可以随意操作外部变量,无需声明。这样好处是少写了一点代码,缺点是存在风险和混乱。

传统写法

$str = "hello world";
function timer () {
    global $str;
    echo $str;
}
Swoole\Timer::tick(2000, 'timer');

闭包写法

$str = "hello world";
Swoole\Timer::tick(2000, function () use ($str) {
    echo $str;
});

闭包写法使用use直接引入了当前的$str变量,而不需要使用global全局变量。另外如果是在swoole的事件驱动编程模式,使用global就无法实现异步并发了,因为global全局变量只有1个,如果同时有多个客户端请求,每个请求要查询数据库,输出不同的内容,传统的编程方法就不太容易实现,需要使用全局变量数组,以客户端的ID为KEY保存各自的数据。

传统写法

$requestArray = array();
$dbResultArray = array();

function my_request($request, $response) {
    global $dbResultArray, $requestArray;
    $queryId = $db->query($sql, 'get_result');
    $requestArray[$request->fd] = array($request, $response);
    $dbResultArray[$queryId] = $request->fd;
}

function get_result($queryId, $queryResult) {
    global $dbResultArray, $requestArray;
    list($request, $response) = $requestArray[$dbResultArray[$queryId]];
    $response->end($queryResult);
}

$server->on('request', 'my_request');

闭包写法

$server->on('request', function ($request, $response) {
    $queryId = $db->query($sql, function ($queryId, $queryResult) use ($request, $response) {
        $response->end($queryResult);
    });
});

传统的写法非常复杂,需要反复多次从全局数组保存/提取数据。而闭包的写法非常简洁优雅,只用了几行代码就实现了同样的功能。闭包写法非常适合用来编写异步非阻塞回调模式的服务器程序。目前热门的编程语言中只有PHP和JS具备这种能力。

闭包更多特性

在类的方法中使用匿名函数,5.4以上的版本无需使用use引入$this,直接可以在匿名函数中使用$this来调用当前对象的方法。在swoole编程中,可以利用此特性减少$serv对象的use引入传递。

class Server extends Swoole\Server {
    function onReceive($serv, $fd, $reactorId, $data) {
        $db->query($sql, function ($queryId, $queryResult) use ($fd) {
            $this->send($fd, $queryResult);
        }
    }
}

另外如果希望在闭包函数中修改外部变量,可以在use时为变量增加&引用符号即可。注意对象类型不需要加&,因为在PHP中对象默认就是传引用而非传值。

分类: Node.js, PHP, Swoole扩展 标签:

基于swoole的task功能实现程序内的map-reduce

2016年3月31日 评论已被关闭

Swoole扩展自带的Task进程功能非常强大,可以用来实现各种复杂的业务逻辑。本文主要介绍使用task/finish功能实现程序内的Map-Reduce并发任务处理。一个聊天服务经常会有群聊需求,我的群组和群组内成员,另外群组内成员需要按照积分排序,类似与这样的功能就可以使用Swoole简单实现。

传统多线程方案

创建2个全局变量Map,group_map以group_id为Key,存储成员set。user_map以uid为Key存储当前用户加入的所有group。

多线程环境下实际上不能直接操作这2个Map,必须要加锁。当添加用户到一个组或者用户退出一个组时需要操作这2个map,必须要加锁。如果操作很频繁,实际上锁的碰撞是很严重的,这部分操作就会变成串行的。同时只有一个线程可以对map进行操作。锁的争抢也会带来大量线程切换浪费很多CPU资源。

lock.lock();
group_map[group_id].append([uid, score]);
user_map[uid].append(group_id);
group_map.sortByScore();
lock.unlock();

基于Swoole的Task功能

基于Swoole的Task功能,可以将任务切片,然后hash投递到不同的Task进程,完成任务。排序功能可以直接使用PHP提供的SplHeap实现,时间复杂度为O(logn),如果要实现查询功能,如根据UID查询用户加入的所有群组,根据GroupId查询有哪些成员。可以先计算Hash找到对应Task进程,然后通过task/taskwait发送指令,直接读取进程的变量查找到信息。

$serv->set(array("task_worker_num" => 24));

$serv->task(array("cmd" => "user", "uid" => $uid, "gid" => $gid, "score" => $score), $gid % $task_worker_num);
$serv->task(array("cmd" => "group", "uid" => $uid, "gid" => $gid), $uid % $task_worker_num);

class MyMaxHeap extends SplHeap
{
    public function compare($value1, $value2)
    {
        return ($value1['score'] - $value2['score']);
    }
}

function onTask($serv, $taskId, $srcWorkerId, $data) {
    static $userMap = array();
    static $groupMap = array();
    
    if ($data['cmd'] == 'group')
    {
        if (!isset($groupMap[$data['gid']]))
        {
            $groupMap[$data['gid']] = new MyMaxHeap();
        }
        $heap = $groupMap[$data['gid']];
        $heap->insert(array("uid" => $data['uid'], "score" => $data['score']));
    }
    elseif ($data['cmd'] == 'user')
    {
        $userMap[$data['uid']][] = $data['gid'];
    }
}

由于Task进程只有数组操作,所以是非阻塞的,只需要开启与CPU核数相同的进程数量即可。进程间无任何加锁争抢,性能非常好。Swoole的Task进程通信使用UnixSocket,是内核提供的全内存通信方式无任何IO,一写一读单进程可达100万/秒。虽然没有直接读变量的速度快,但性能也足够了。

————–伟大的分割线—————
PHP饭米粒(phpfamily) 由一群靠谱的人建立,愿为PHPer带来一些值得细细品味的精神食粮!
本文由 rango 独家授权 php饭米粒发布,转载请注明本来源信息和以下的二维码(长按可识别二维码关注):

分类: PHP, Swoole扩展 标签:

Swoole-1.8.0的开发计划

2015年12月3日 评论已被关闭

12月1日发布了swoole-1.7.21版本,修复了很多BUG。这是swoole-1.7最后一个版本了,以后不再更新。我们启动了雄心勃勃的swoole-1.8开发计划。在介绍1.8的计划前,先讲一段小插曲。

性能测试游戏

昨天在1.7.21发布后,正好赶上PHP7也发布,忍不住想要做下性能测试。安装了一下HHVM,准备对比PHP5.6、PHP7、HHVM3.9的性能。对WordPress程序的测试中,PHP7确实已经与HHVM很接近了。不过这不是重点,接下来我又测试了一下新写的PHP版本WebSocket客户端。这一测问题就来了。我发现PHP在这个场景下性能非常差。当时的数据是:

5.6.9 cost 23792.750835419ms
5.6.99-hhvm cost 1930.1018714905ms
7.0.0RC7 cost 12121.658086777ms

压测10万次WebSocket协议打包,竟然消耗了23秒,PHP7比PHP5.6提升了1倍性能,但和HHVM还是有较大的差距。这个结果倒是在预料之中,毕竟Zend PHP没有JIT,这样纯密集计算的场景下性能不会太好。我顺手加了一个C版本的websocket_pack。再次压测,结果震惊了。

5.6.9 cost 23792.750835419ms
5.6.99-hhvm cost 1930.1018714905ms
7.0.0RC7 cost 12121.658086777ms
C-websocket_pack cost 57.986974716187ms

C语言版本只用了57ms就完成了10万次的打包。比PHP版本性能高出300多倍。即使是有JIT的HHVM也无法和C语言版本的websocket_pack相提并论。好了接下来就聊聊swoole-1.8的开发计划。

Swoole-1.8的开发计划

异步模式下reload/max_request的支持

swoole-1.7下如果Server是纯异步非阻塞的模式,使用reload/max_request可能会导致某些事件丢失。所以WIKI中明确写了异步模式不应该设置max_request,reload会出现一些错误。1.8会解决此问题,对异步模式下Worker进程退出逻辑将发生一些修改。底层会确保Worker进程中的事件全部处理完后才会退出。

网络协议部分的调整

swoole-1.8将增加Http异步客户端(同步阻塞模式直接用CURL就可以了)、WebSocket同步/异步客户端。1.8还将增加http2.0、mqtt协议的支持。

另外一个重要调整就是,1.8将支持Server多协议。目前1.7版本一个swoole_server只能使用一种网络协议,比如swoole_http_server就只能处理HTTP协议,无法再支持固定包头+包体、EOF协议。有一些场景下一个Server需要做多件事情。新的版本会支持混合多协议。

正是因为上面的性能测试,让我下定决定在swoole内逐步开始支持绝大部分通用的网络协议。C语言实现的客户端在性能上远远超过其他语言。Swoole要让PHP在网络通信方面超过其他语言,比如Java、Node.js、Golang、Erlang等,只有C语言实现一条路可选。

扩展内RPC的支持

RPC作为服务器端程序中很重要的一项功能,Swoole没有理由不去支持它。1.8版本将会内置RPC的基础模块,包括Server端和Client端,Client端会同时支持异步和同步,并且支持php-fpm下调用。

配套工具的支持

经常有PHPer向我反馈想要有一套命令行工具可以简单地实现Server程序的start、stop、reload、status,以及通过inotify监控实现自动reload,新的swoole-1.8开发计划中将包含这些工具,我们会提供一些通用的、非侵入式的工具。

Swoole-1.8什么时候发布

我们已经启动了开发,新特性会逐个在子版本上线,预计2016年7月份会上齐所有特性。

 

分类: Swoole扩展 标签:

关于C++、PHP和Swoole

2015年8月25日 评论已被关闭

昨天和一个前同事聊天,各种吐槽PHP,吐槽Swoole,他认为PHP到处是坑,PHP局限很大。PHP+Swoole不适合做高并发服务器,C+Swoole才是最好的方案。C++有各种数据结构,C++可以开线程,C++可以共享对象。看来有必要好好得说明一下了。

PHP比C/C++或Java少了什么?多线程,多线程,多线程……

是的。PHP比C/C++、Java少了多线程。PHP只有多进程的方案,所以PHP里的全局变量和对象不是共享的、数据结构也不能跨进程操作、Socket文件描述符不能共享等等。所以PHP有局限?

多线程看似比多进程要强大很多,实际上我可以负责任的告诉你,多线程带来的坑更多

  • 数据同步问题会让你崩溃的。要么就牺牲性能到处加锁,要么就用地狱难度的无锁并发编程,据我所知目前国内能掌握此项技能的人凤毛麟角。
  • 不要以为加锁就万事大吉了,你会在死锁问题上栽个大跟头。当你的程序逻辑复杂后,锁越来越难控制了,一旦死锁你的程序基本上就完了。
  • 某个线程挂了那所有线程都会退出
反而在看多进程,其实就简单的多了。
  • 配合进程间通信,基本上你可以实现任意的数据共享。比如利用一个进程专门存数据结构和对象,其他进程的数据操作全部投递到此进程来
  • 多进程不需要锁
  • 多进程可以使用共享内存的数据结构实现一些多线程的功能。如Swoole提供的Table、Atomic可以实现数据共享,但成本很低。未来还会加入共享内存队列

所谓PHP限制了Swoole,这完全是无稽之谈。合理利用Swoole提供的Table、Atomic、SendMessage/PipeMessage、Task完全可以实现异步非阻塞的代码逻辑。

C++写出来的程序性能更好?

这完全是盲目的迷信,密集计算的程序C++确实是有优势的。而并发服务器核心是IO,并非大规模密集运算。C++从语言层面来看并没有什么优势。另外C++中的大部分数据结构在PHP中都有对应的实现,实在不行自己写个专门的扩展也能解决之。

高并发的服务器单机能维持10W连接、每秒可处理3-5W笔消息收发。这种性能水准已经可以应用在BAT的核心系统上了。

开发效率快的意义是什么?

这位同事还说PHP开发Server虽然比C++快了,但是追求性能的极致还是要用C++。我要告诉你效率高了究竟意义何在。开发一套好程序不是一件容易的事情,需要程序员投入大量时间和精力。开发效率提升的意义并不是简单的我可以更少时间完工,而是剩下的时间你可以增加单元测试、修复BUG、提升用户体验、完善细节、提供配套工具、优化性能、增加关键日志、增加监控报警、增加容灾方案。

 

分类: C/C++, PHP, Swoole扩展 标签:

关于TCP网络通信

2015年8月10日 评论已被关闭

TCP协议在底层机制上解决了UDP协议的顺序和丢包重传问题。但相比UDP又带来了新的问题,TCP协议是流式的,数据包没有边界。应用程序使用TCP通信就会面临这些难题。一些程序在本机测试是正确的,上线后就出现各种奇怪的BUG。如下面的伪代码,客户端向服务器端发送一个json字符串,服务器端接收此字符串。在慢速网络中Server无法正确接收完整的JSON字符串。


$client->send(json_encode('a' => $data_10k, 'b' => $data_5k));
$pkg = $server->recv(); //Server收到的数据只有一小部分

$client->send("hello1");
$client->send("hello2");
$client->send("hello3");
$pkg = $server->recv(); //Server会一次性收到3个数据包

因为TCP通信是流式的,在接收1个大数据包时,可能会被拆分成多个数据包发送。多次Send底层也可能会合并成一次进行发送。这里就需要2个操作来解决:

  • 分包:Server收到了多个数据包,需要拆分数据包
  • 合包:Server收到的数据只是包的一部分,需要缓存数据,合并成完整的包

具体编码实现这里就不讲了,这是一个比较复杂的编程过程,稍有不慎就会出现严重的BUG

Swoole如何解决此问题

swoole提供了通用协议的支持,如Http和WebSocket。自定义协议可以使用Length/EOF 2种协议解析方式来完美解决此问题。从1.7.18版本开始,Swoole的Server/Client都支持了Length/EOF的协议处理方式,应用层代码只需要配置一下参数,就无需关注底层分包合包了。每次onReceive收到的数据包总是完整的。

Server/Client的配置是相同的

Http/WebSocket

swoole内置对http/websocket 2种协议的支持,如果要实现一个http服务或者websocket服务,直接用swoole_http_server和swoole_websocket_server即可。

EOF

$server->set(array('open_eof_split' => true, 'package_eof' => "\r\n"));

EOF协议处理的原理是每个数据包结尾加一串特殊字符表示包已结束。如memcache、ftp、stmp都使用\r\n作为结束符。发送数据时只需要在包末尾增加\r\n即可。使用EOF协议处理,一定要确保数据包中间不会出现EOF,否则会造成分包错误。

Length

$server->set(array(
'open_length_check' => true,
'package_max_length' => 81920,
'package_length_type' => 'n', //see php pack()
'package_length_offset' => 0,
'package_body_offset' => 2,
));

固定包头的协议非常通用,在BAT的服务器程序中经常能看到。这种协议的特点是一个数据包总是由包头+包体2部分组成。包头由一个字段指定了包体或整个包的长度,长度一般是使用2字节/4字节整数来表示。服务器收到包头后,可以根据长度值来精确控制需要再接收多少数据就时完整的数据包。Swoole的配置可以很好的支持这种协议,可以灵活地设置4项参数应对所有情况。

Swoole的Server和异步Client都是在onReceive回调函数中处理数据包,当设置了协议处理后,只有收到一个完整数据包时才会触发onReceive事件。同步客户端在设置了协议处理后,调用 $client->recv() 不再需要传入长度,recv函数在收到完整数据包或发生错误后返回。

 

分类: PHP, Swoole扩展 标签:

swoole新增的tick定时器

2015年3月24日 评论已被关闭

swoole-1.7.14增加了tick定时器,解决了addtimer存在的各种问题。


swoole_timer_tick(1000, function ($timer_id) {
    echo "tick-1000ms\n";
    swoole_timer_clear($timer_id);
})

swoole_timer_tick(2000, function () {
    echo "tick-2000ms\n";
})

swoole_timer_tick和swoole_timer_after原理是相同的,区别是after只执行一次就会销毁。tick定时器会持续执行,直到调用了swoole_timer_clear清除定时器。

与PHP代码中的pcntl_alarm不同,swoole的定时器是基于EventLoop实现的,不依赖系统信号和PHP的tick机制,所以效率非常高。即使添加大量定时器,CPU消耗也是很低的。PHP在过去没有像JavaScript这样方便的定时器功能,现在有swoole就可以很好地解决。

在网络游戏程序中经常要用定时器,PHP+swoole将会成为最佳的技术方案。

分类: Swoole扩展 标签:

PHP官方的pcntl_signal性能极差

2014年10月18日 没有评论

很多纯PHP开发的后端框架中都使用了pcntl扩展提供的信号处理函数pcntl_signal,实际上这个函数的性能是很差的。首先看一段示例代码:

declare(ticks = 1);
pcntl_signal(SIGINT, 'signalHandler');

这段代码在执行pcntl_signal前,先加入了declare(ticks = 1)。因为PHP的函数无法直接注册到操作系统信号设置中,所以pcntl信号需要依赖tick机制。通过查看pcntl.c的源码实现发现。pcntl_signal的实现原理是,触发信号后先将信号加入一个队列中。然后在PHP的ticks回调函数中不断检查是否有信号,如果有信号就执行PHP中指定的回调函数,如果没有则跳出函数。

PHP_MINIT_FUNCTION(pcntl)
{
	php_register_signal_constants(INIT_FUNC_ARGS_PASSTHRU);
	php_pcntl_register_errno_constants(INIT_FUNC_ARGS_PASSTHRU);
	php_add_tick_function(pcntl_signal_dispatch TSRMLS_CC);

	return SUCCESS;
}

pcntl_signal_dispatch 函数的实现:

void pcntl_signal_dispatch()
{
	//.... 这里略去一部分代码,queue即是信号队列
	while (queue) {
		if ((handle = zend_hash_index_find(&PCNTL_G(php_signal_table), queue->signo)) != NULL) {
			ZVAL_NULL(&retval);
			ZVAL_LONG(&param, queue->signo);

			/* Call php signal handler - Note that we do not report errors, and we ignore the return value */
			/* FIXME: this is probably broken when multiple signals are handled in this while loop (retval) */
			call_user_function(EG(function_table), NULL, handle, &retval, 1, &param TSRMLS_CC);
			zval_ptr_dtor(&param);
			zval_ptr_dtor(&retval);
		}
		next = queue->next;
		queue->next = PCNTL_G(spares);
		PCNTL_G(spares) = queue;
		queue = next;
	}
}

这样就存在一个比较严重的性能问题,大家都知道PHP的ticks=1表示每执行1行PHP代码就回调此函数。实际上大部分时间都没有信号产生,但ticks的函数一直会执行。如果一个服务器程序1秒中接收1000次请求,平均每个请求要执行1000行PHP代码。那么PHP的pcntl_signal,就带来了额外的 1000 * 1000,也就是100万次空的函数调用。这样会浪费大量的CPU资源。

比较好的做法是去掉ticks,转而使用pcntl_signal_dispatch,在代码循环中自行处理信号。而swoole中因为底层是C实现的,信号处理不受PHP的影响。swoole使用了目前Linux系统中最先进的signalfd来处理信号,几乎是没有任何额外消耗的。

swoole与phpdaemon/reactphp/workerman等纯PHP网络库的差异

2014年6月17日 1 条评论

从swoole项目开始到现在,一直有人在问这个问题。今天来抽空讲一下它。为什么swoole非要使用纯C来写而不是PHP代码来实现,核心的原因有2点:

1. PHP无法直接调用操作系统API

如sendfile、eventfd、timerfd、pthread等等,这里就不一一列举了,所以纯PHP实现的phpdaemon,reactphp,还有最近刚刚出来的workerman。这些框架都是基于PHP的sockets/pcntl/stream/libevent扩展实现,提供的功能很有限,很多功能都无法实现。如

  • 多线程
  • 毫秒定时器(PHP中只有秒级的定时器)
  • 标准输入输出重定向
  • MySQL/CURL异步化
  • 守护进程化
  • sendfile
  • 其他更多

而C语言写的swoole可以直接调用操作系统底层API,没有局限,swoole可以实现任何功能特性。

2. PHP的内存管理粒度太粗

PHP中想要做内存管理太困难了,基本上只有Array可用。在高并发大负载的网络Server中,内存复制简直就是性能杀手。PHP中根本无法解决此问题。

举一个简单的例子,客户端向服务器发起一个800K的包,每次发送8K,共发送100次。Server也会分成100次收到数据。那么PHP中拼接此数据包的方法是 $package .= $recv_data 。共需要复制100次内存,第一次为 8K+ 8K,第二次是 16K + 8K,第三次24K + 8K,依次类推,仅仅一次请求就发生了大量的内存拷贝。如果每秒有10万次请求,这个Server的性能必然极差。

而纯C的代码可以做到0次内存拷贝,在请求到来申请一块800K的buffer内存,通过指针运算,直接将数据写入buffer。一气呵成,内存拷贝为0。

当然这里仅是其中一个小小的点,真正的代码中不止这些。通过压测也能发现,纯C的swoole写一个EchoServer,做-c 500 -n 100000的测试中,CPU始终在5%-10%之间。而PHP实现的PSF网络Server框架,CPU占用率高达70%-90%。

 

以上也就是swoole和其他网络框架的差异。除此之外swoole以扩展方式提供,免去了代码中include php文件的问题。不需要去包含一堆外部文件,更容易融合到现有代码中。使用者仅需掌握swoole扩展的API即可。reactphp提供了API封装,耦合程度较低。phpdaemon/workerman耦合太高,不是你的代码集成它们,而是它们的代码集成你的代码。而且还需要了解其内部结构和耦合关系。

再看swoole,它其实就像MySQL之类的扩展一样,仅仅是作为一层API存在,耦合度非常低。swoole一直坚持低耦合高内聚,API化。用户可以方便的将swoole的功能集成到自己的代码中。

 

分类: Swoole扩展 标签:

node.js与swoole相比优势与劣势分析

2014年5月7日 没有评论

这几天微博上好多网友在询问node.js和swoole对比的问题。这里做一个详细的解答。

多核并行

node.js的event loop是单进程单线程的,只有一个epoll/kqueue事件轮询被执行。所以无法利用到多核的计算优势。

swoole的event loop是多线程的,是基于epoll/kqueue的Multi-Reactor模型。这点与nginx/golang相同。另外swoole的多线程Reactor之间不存在锁,这点与nginx不同。它启用了专门的accept线程,类似与JAVA的netty。

所以在多核CPU的机器上,node.js对网络IO事件的处理能力绝对是要差swoole数倍的,在4核的机器上至少要查2-3倍。

虽然node.js也提供了多线程的扩展,但对于event_loop来说必须是内核提供,扩展不行的。

另外node.js未来是否会改造成为多线程Reactor,我估计不会,这不是技术上的难题。而是一旦改成多线程Reactor,node.js恐怕就不是node.js了。失去了原来单线程的各种优势后,反而会一无是处。当然可能node.js官方开发组会思考出解决问题的巧妙办法,一切都是后话了。

不只是event_loop,执行用户层代码是也是单线程的,不能利用多核计算优势。需要用户自己去fork多进程或者创建线程池。使用难度增加了很多。不像swoole,配置一下参数即可,是天然多进程。

异步网络IO

node.js和swoole都是基于epoll/kqueue实现的全异步非阻塞IO,所以这方面大同小异,没有差别。维持TCP长连接的能力是一样的。

node.js在这里有一个优势就是它支持windows的IOCP。swoole仅支持Linux/FreeBSD/MacOS的epoll/kqueue.

异步文件读写

node.js和swoole都提供了基于线程池的异步文件读写,DNS查询功能。node.js最早基于libeio实现,后来才自行实现线程池。swoole一开始就基于线程池设计的。

实际上这里都是通过多线程阻塞来模拟的,并非真正的异步读写文件。比如同时读写数百个文件时,性能远不如普通的多进程PHP程序。

swoole中还提供了Linux Native AIO的支持,是真正的内核层异步并行文件读写,不过需要通过修改宏开关,重新编译才可以使用。

最后结论

node.js和swoole比没有明显优势,仅在Windows支持方面比swoole要好。node.js中有的特性swoole中都有。个人认为Node.js最大的优势在于:

  • node.js使用JavaScript语言,与浏览器、HTML之间的融合度非常高,使用同一种语言既写前端又写后端
  • 支持Windows平台,利用node-webkit,可以开发PC客户端软件

node.js的定位应该是前端与后端结合非常紧密的应用场景。如websocket推送,JSON-RPC,轻量级HTTP接口。

而对于真正专业的后端领域,分布式系统,node.js不适合。

 

分类: Node.js, PHP, Swoole扩展 标签:

swoole的进程模型架构

2014年5月5日 没有评论

swoole的强大之处就在与其进程模型的设计,既解决了异步问题,又解决了并行。

主线程MainReactor

swoole启动后主线程会负责监听server socket,如果有新的连接accept,主线程会评估每个Reactor线程的连接数量。将此连接分配给连接数最少的reactor线程。这样的好处是

  1. 每个reactor线程持有的连接数是非常均衡的,没有单个线程负载过高的问题
  2. 解决了惊群问题,尤其是拥有多个listen socket时,节约了线程唤醒和切换的开销
主线程内还接管了所有信号signal的处理,使Reactor线程运行中可以不被信号打断。

管理进程Manager

swoole运行中会创建一个单独的管理进程,所有的worker进程和task进程都是从管理进程Fork出来的。管理进程会监视所有子进程的退出事件,当worker进程发生致命错误或者运行生命周期结束时,管理进程会回收此进程,并创建新的进程。

管理进程还可以平滑地重启所有worker进程,以实现程序代码的重新加载。

异步Reactor线程

swoole拥有多线程Reactor,所以可以充分利用多核,开启CPU亲和设置后,Reactor线程还可以绑定单独的核,节约CPU Cache开销。

swoole的Reactor线程是全异步非阻塞的,即使你的worker进程用了同步模式,依然不影响reactor线程的性能。在worker进程组很繁忙的状况下,reactor线程完全不受影响,依然可以收发处理数据。

TCP是流式的,没有边界,所以处理起来很麻烦。Reactor线程可以根据EOF或者包头长度,自动缓存数据,组装数据包。等一个请求完全收到后,再投递给Worker进程。

同步或异步Worker进程

与传统的半同步半异步服务器不同,Swoole的worker进程可以是同步的也可以异步的,这样带来了最大的灵活性。当你的Server需要很高性能,业务逻辑较为简单时你可以选择异步模式。当业务逻辑复杂多变,可以选择同步模式。

这里要比Node.js强大太多了。

TaskWorker进程池

swoole除了Reactor线程,Worker进程外还提供了TaskWorker进程池,目的是为了解决在业务代码中,有些逻辑部分不需要马上执行。利用task进程池,可以方便的投递一个异步任务去执行,在Worker进程空闲时再去捕获任务执行的结果。

 

分类: Swoole扩展, 进程间通信 标签: