一次失败的PHP扩展开发之旅

WBOY

풀어 주다： 2016-06-06 20:01:41

원래의

848명이 탐색했습니다.

终于到了组装成型的时刻了，通过 telnet 玩了几把 EchoDemo ，看到一行一行的回显，不禁心情大好。 ?php class EchoDemo { public static function init($server, $conf) { log_debug($server, init in php.\n); return true; } public static function inpu

终于到了组装成型的时刻了，通过telnet玩了几把EchoDemo，看到一行一行的回显，不禁心情大好。

<?php class EchoDemo {
        public static function init($server, $conf) {
            log_debug($server, "init in php.\n");
            return true;
        }   

        public static function input($server, $req, $ext_info = array()) {
            log_debug($server, "input in php.\n");
            return strlen($req);
        }   

        public static function route($server, $req, $ext_info = array()) {
            log_debug($server, "route in php.\n");
            return 1;
        }   

        public static function process($server, $req, $ext_info = array()) {
            log_debug($server, "process in php.\n");
            $ret = sendrecv($req, strlen($req), $rsp, 65535, "127.0.0.1", 2345, 500);
            if ($ret != 0) {
                log_debug($server, "sendrecv fail. ret=$ret");
                return false;
            }   
            log_debug($server, "sendrecv finish. rsp=$rsp");
            return true;
        }   

        public static function fini($server) {
            log_debug($server, "fini in php.\n");
        }   
    }
?>

로그인 후 복사

这里最值得赞叹的就是process函数对于sendrecv扩展调用，这里背后通过协程其实已经实现了一次异步网络交互：既能像同步CGI般书写逻辑代码，又能无痛地享受异步的高并发。

愿望是美好的，现实是残酷的！

我这时突然心血来潮：来压测一把性能吧，看看相比于原生C++代码有多大的性能衰减。单次请求1KB，施以1w/s的压力，压了一会coredump了。

内存泄漏？协程栈溢出？...

期间各种折腾：GDB，修改协程栈大小，Google，咨询PHPer ...

很快到了晚上，该查的都查过了，该问的都问过了，实在没辙了，停下来喝杯茶：“call_user_function可重入么”？想到这一层，相信了解协程本质的兄弟又秒懂了：你妹的，人家实现Zend的时候怎么知道调用线程还会玩协程进行用户态调度啊，这个黑盒里面一切皆有可能啊！全局变量、静态变量 ...

好吧，去掉sendrecv这类基于协程的扩展，重新压测，单worker对于3w/s的echo还是轻松无压力的。