webman可以兼容已有的composer生态(swoole不能),而且可以常驻内存高性能,那是不是可以丢掉swoole而完全投入到workerman和webman的怀抱呢?
workerman 其实也兼容swoole,看这个帖子,https://www.workerman.net/q/3529
好的
其实我是想得到一些关于workerman和swoole的更多使用场景的对比,比如webman的阻塞io为什么性能高,然后webman为什么没有数据库连接池等等这些底层原理的知识。
再有就是webman可以兼容全部composer生态的话,是否真的可以吊打swoole相关框架了。
吊打夸张了,各有优势吧。webman易上手兼顾高性能,虽然压测极限性能高于swoole扩展,但那个只是极限性能,需要数据库足够快。swoole的优势是自带协程,有更好的弹性,缺点就是学习成本有点高。
各有各的优势!适合自己的才是最重要的
二者兼得!
回调异步模型≈无栈协程异步模型>有栈协程异步模型。swoole显然是有栈协程异步模型,编写上非常方便,可惜有栈协程是非常浪费内存的。workerman是属于回调异步模型。单个线程/进程即可处理大量连接, 但是因为并不符合大家认为的C比PHP快的期望才会让人感觉意外 说白了,都是在做IO,不是在做密集计算,语言影响力当然没那么大 Workerman/Webman兼容现有的生态是一个很大的优势,源代码也有,有一定能力可自行扩展/除虫,Swoole的话,有问题只能去看C的源码,不然只能等官方修复
回调异步模型≈无栈协程异步模型>有栈协程异步模型 这能不能详细说一下
要哪个方面?
就上面三个
好的,不好意思这两日有点忙,我周末填个坑
感谢哈!
workerman 其实也兼容swoole,看这个帖子,https://www.workerman.net/q/3529
好的
其实我是想得到一些关于workerman和swoole的更多使用场景的对比,比如webman的阻塞io为什么性能高,然后webman为什么没有数据库连接池等等这些底层原理的知识。
再有就是webman可以兼容全部composer生态的话,是否真的可以吊打swoole相关框架了。
吊打夸张了,各有优势吧。webman易上手兼顾高性能,虽然压测极限性能高于swoole扩展,但那个只是极限性能,需要数据库足够快。swoole的优势是自带协程,有更好的弹性,缺点就是学习成本有点高。
各有各的优势!适合自己的才是最重要的
回调异步模型≈无栈协程异步模型>有栈协程异步模型。swoole显然是有栈协程异步模型,编写上非常方便,可惜有栈协程是非常浪费内存的。workerman是属于回调异步模型。单个线程/进程即可处理大量连接, 但是因为并不符合大家认为的C比PHP快的期望才会让人感觉意外
说白了,都是在做IO,不是在做密集计算,语言影响力当然没那么大
Workerman/Webman兼容现有的生态是一个很大的优势,源代码也有,有一定能力可自行扩展/除虫,Swoole的话,有问题只能去看C的源码,不然只能等官方修复
要哪个方面?
就上面三个
好的,不好意思这两日有点忙,我周末填个坑
感谢哈!