Workerman改进建议

0

Gavin 发了几个workerman改进意见,这里记录下


发几个关于workerman的意见


一 没有主进程启动与结束回调
这两个回调的一个用途是用于与外部工具协作,例如服务发现。主要是方便在
在runAll前执行启动是不可取的,因为此时workerman的资源尚未载入,一些可能需要获取的信息尚未生成。
在register_shutdown_function或者在onWorkerStop进行结束回调也是不可取的,workerman并未提供方法判断当前进程是主进程还是worker进程。


二 注册回调函数的方式并不好
这个属于见仁见智,但主流做法是使用on($event, callable $callback)进行注册,我也更倾向于这个做法,包装起来更方便。另一个原因是,call_user_func本身有性能损失,因为相当于多了一级函数调用,回调注册的方式可以直接$callback($args);callable本身会进行类型检查;总之是好处多多。
即使是为了兼容性,也可以使用__set魔术方法把对这几个回调的注册转换为on()的形式。


三 Worker类的可见性与初始化配置
Worker有大量的属性,public和protected都有。但是,php并不能简单设置readonly或者writeonly属性,以至于有些应该只读的属性,如$id,也是可写的;有些应该只写的属性,如onXxxxx,也是可读的。当然,一个正确的基于workerman的程序不应该非法读写这些属性;只是,如果可以用较低的成本(事实上,对于程序性能毫无成本)提高这方面的可靠性,应该是值得一做的。


四 与composer的协作
如果我的观察没错的话,workerman是依赖于自带的Autoloader.php的,同时也在composer.json里面定义了psr自动加载。
当然,因为作为一个常驻型的程序,autoload带来的性能损失可以忽略不计;但是,对于使用composer管理包的开发者来说,似乎并无此必要。


以上意见,有的可能属于鸡蛋里挑骨头,请酌情考虑。

已邀请:

walkor

赞同来自: 254135495 北行

一 没有主进程启动与结束回调
这个建议很好,当时开发也考虑过,但是最后还是决定不给用户在主进程上编程的入口
原因是
1、主进程要保持稳定性,加入业务代码很有可能导致不稳定
2、子进程会自动继承主进程的这部分业务代码,导致子进程行为也不可控(大多数phper不会理解或者考虑到这个问题)。比如在主进程Start时数据库数据库连接/redis/memcache在子进程是不可用的,主进程start的定时器在子进程也会运行,导致和预期不一致


全局的onStart 和 onStop可以有很多种方法,比如
1、在worker->id为0的进程的onWorkerStart/onWorkerStop中做
2、单独启动一个worker进程在onWorkerStart/onWorkerStop去做
3、写个shell启动脚本,在start或者stop执行一段自己想要的业务逻辑


总之在主进程编码很危险,无法保证每个phper都有多进程编程经验,所以workerman不打算提供这种机制,避免因为代码质量问题造成不稳定和不必要的问题投诉。目前来看有主进程start/stop回调的需求用户很少的。


二 注册回调函数的方式并不好
恩像Gavin所说,见仁见智,各有优势吧,目前这种设置回调属性的方法避免了一次函数调用,性能高一些。
另外就是能够自动提示,少敲了很多代码。这些是小问题,不爽可以直接继承worker加个on('message',func)方法也没问题。
另外$callback($args);这种如果$callback是类方法,会直接报错(这个之前有测试过,当时php版本是5.3,不知道高php版本是否ok)。所以workerman使用了call_user_func方法


三 Worker类的可见性与初始化配置
这个建议不错,但是感觉严格限制缺少了灵活性。
有些属性确实是建议只读的,比如说worker->id,但是覆盖了也没有问题,默认值可以看做是建议值吧。
onXXX不仅是可写的,也应该是可读的,方便用户判断当前设置的是什么回调


四 与composer的协作
如果国内每个用workerman的phper都会用composer,并且每个项目都用自觉使用composer,并且composer官网国内访问非常通畅,那么就可以把autoloader.php去掉,但是貌似上面任何一个条件都不能保证,所以还得给个默认的autoloader.php


非常感谢Gavin的建议

要回复问题请先登录注册