这是一个创建于 1612 天前的主题，其中的信息可能已经有所发展或是发生改变。
据说 swoole 性能挺好，大家有用在实际项目中吗？用在什么场景下呢？
 |
1
components 2020-08-01 17:49:41 +08:00
|
 |
2
jaynos 2020-08-01 18:11:00 +08:00  1
实际项目中在 websocket 上使用过 swoole，坑点还是有不少，选择的原因是着急上线+需要对接业务是 php 的。
碰到的坑点有 Table 需要传入 capacity，超出就删已有数据，可能还有实际容量达不到 capacity 指定的数量的问题。隐约记得还有内存可见性问题，通过 Timer 创建的任务不能访问到链接信息问题。最严重的还是一次莫名的线上事故，整个进程完全阻塞，呆呆的停在那里= =，coredump 之后紧急重启了，事后分析堵塞在 epoll_wait 上，具体就没细看了，加了个班直接迁移到 golang 上了= = |
 |
3
agdhole 2020-08-01 18:17:52 +08:00
安装麻烦，使用麻烦
有这功夫直接换语言 |
 |
4
z5864703 2020-08-01 18:24:24 +08:00
用 swoole 跑长链接数据转发业务，性能还行吧，4 核 8G 单机 40 万链接。但是坑比较多，只有趟过了才知道
|
 |
5
janxin 2020-08-01 18:32:05 +08:00
有折腾的时间，都换上 java 了…
|
 |
6
nguoidiqua 2020-08-01 18:51:10 +08:00
对其没啥兴趣
|
 |
7
C603H6r18Q1mSP9N 2020-08-01 19:15:22 +08:00
测试过，单跑代码比 java 都快
但是链接数据库、链接 redis，比 java 慢的多，慢 50%左右，我怀疑是底层原生扩展不行 但是比 pfm 方式有质的提升，而且不占用 tcp 链接了 |
 |
8
KasuganoSoras 2020-08-01 20:15:42 +08:00
挺好，之前用 Swoole 写了个数据库查询的接口，配合 Redis 缓存，有连接池。后来这接口给人 CC 攻击了，4 核 4G 内存的服务器，跑上了 26w QPS，宽带先打满了，机器却没死机，攻击一停秒恢复
|
 |
9
wspsxing 2020-08-01 20:21:27 +08:00 via Android 1
rustgo 笑而不语
|
 |
10
edwinlauff 2020-08-01 21:19:19 +08:00
用时候最好把主要代码理清，不过大多数还是用 Go
|
 |
11
richangfan 2020-08-01 21:30:16 +08:00
这个是推广贴，标题 Google 一下就知道了
|
 |
12
back0893 2020-08-01 21:50:00 +08:00
wokerman 用着不比 swoole 舒服.
反正用 swool 不如换语言 |
 |
13
shuimugan 2020-08-01 22:27:56 +08:00 1
选了错的路，越走越错。
已转 Node.js 。 |
 |
14
sagaxu 2020-08-01 22:52:16 +08:00
3 年多 Swoole 使用经验，心里依然没底，用 JVM 或者 Go 的时候，大部分疑问可以在 memory model 里找到答案，还有一些相关的书可以参考，但是 PHP+Swoole 的相关资料可没那么好找。
框架五花八门，现在官方最推荐的是 hyperf，注解和路由写起来很像 Spring，但 IDE 会提示删除未使用的 import，真要删了注解也就不工作了，这是个问题。第二个问题是启动慢，比 SpringBoot 还慢，似乎跟注解的工作方式有关。 @jaynos 如果不是历史遗留项目，还是 JVM 和 Go 靠谱的多，开发效率差不多，但生态和稳定性相差很大。 @back0893 wokerman 的回调，跟 Swoole 的协程比，体验还是差了写，写基础设施可能还行，写业务逻辑就累了。 |
 |
15
abcbuzhiming 2020-08-01 22:58:32 +08:00
这个所谓的性能特别好，其实也只是和传统 PHP 比而已，在 PHP 以外的世界，一般般，不算特别出彩。
Swoole 这个东西的最大问题在于马太效应，虽然我也认为它才是未来，CGI 已经落后了，驻留进程才是正确的做法。无奈在 PHP 的世界里，CGI 真的是历史（包袱）厚重，导致 Swoole 这个东西诞生了这么多年，还是非主流。开源社区里，你先进，你性能高，但是如果你非主流了，那一定前途堪忧，无数先烈证明了这点 |
 |
16
lsls931011 2020-08-02 10:18:31 +08:00
关键问题是 swoole 现在生态不完善，但是商业气息却非常浓厚，swoole 开源社区还互相吵，这还能起来嘛
|
 |
17
xooass 2020-08-02 11:38:37 +08:00
还用问大家怎么看？
不看，不用 |
 |
18
wangbenjun5 2020-08-02 11:57:47 +08:00
一句话，用 swoole 还不如用 go，无论是从开发效率、生态、可维护性上面比，别说 swoole 是 PHP，其实没多大关系
|
 |
19
CoolSpring 2020-08-02 19:40:58 +08:00
@richangfan 搜索结果除了 v2 上的这个帖之外，只有一个采集 v2 的站啊
|
 |
20
dvaknheo 2020-08-02 21:39:06 +08:00
swoole 把主战场放在 web 是搞错方向了。
hyperf ； swoole 节省下来的性能就浪费在这？ 如果用 只能用在 swoole 上的框架 来进行开发，开发效率会大大降低。 另一方面，swoole 平台的东西用 composer 的东西都得要去看是否兼容 swoole. |
 |
21
xingjue 2020-08-02 22:30:38 +08:00 1
一堆 吹 go 的 本人实测 go 做 web 很痛苦 17 年底开始用,swoole 如果稳定性在牛逼点，就类似于 java 的 netty，成为 php 工业级基础软件，总之前景还是不错的，没楼上的那些人说的那么糟糕（ PS:神烦一堆无脑 go 吹，就好像当年吹 python 做 web 的那波人一样）
|
 |
22
JaguarJack 2020-08-03 06:05:58 +08:00 via iPhone
@xingjue 你让她们说出个一二三出来，最后只会来一句原生自带协程。其他啥也反驳不了
|
 |
23
Austaras 2020-08-03 07:43:07 +08:00
艹 goroutine 起码支持多核不比 swoole 高级多了
|
|
24
sagaxu 2020-08-03 09:22:32 +08:00 via Android
@JaguarJack
一，静态类型，项目越大越需要类型约束。 二，协程生态，所有库支持协程，不用猜和试。 三，明确的 memory model，更少并发的坑。 四，零依赖部署更简单，开箱即用的交叉编译。 五，多线程利用多核，PHP 多线程能用？ 六，性能，框架可以拿 C 写，业务逻辑呢？ |
 |
25
lands 2020-08-03 11:17:27 +08:00
用的那时候 swoole 还是 1.x, 当时填了不少坑...现在版本都到 4.x 了...这一路过来, 相关的框架太多了, 五花八门
|
 |
26
Evilk 2020-08-03 15:47:51 +08:00
我们用 swoole 4.4+, swoft 2.0.x,虽然有问题,但没那么不堪吧
|
 |
28
ragnaroks 2020-08-03 18:16:26 +08:00
矮子里面拔高个
|
 |
29
CodeCodeStudy 2020-08-04 09:31:19 +08:00
可以辅助 PHP-FPM
|
 |
31
ben1024 2020-08-04 17:28:25 +08:00
能真正嵌入 PHP 本身才能更快速的发展，
以扩展形式存在且开发团队有限的情况下，发展速度还是有些慢 |
|
32
xingjue 2020-08-06 11:55:49 +08:00
@Austaras 一天多核多核，你懂个屁,swoole 可以开多进程或者利用 docker 使用多核性能，照你这么说,node 单线程的，性能不是掉渣，辣鸡半桶水
|
|
33
Austaras 2020-08-07 13:00:54 +08:00
@xingjue
node 确实也不能用多核, 所以我也不喜欢, 但是 v8 比 php 的任何实现都要高级得多, 不过与之相反, 像你这样冲进几天前的帖子里说一点谁都懂的东西的才是真半桶水吧 |
|
34
Austaras 2020-08-07 13:04:47 +08:00
而且 node 呢起码还有 worker thread 甚至一些东西还可以分享不用序列化反序列化是不是比只能无脑多进程的高级多了...而且你说多进程也就算了扯 docker 是为了看起来牛逼吗
|
|
36
Austaras 2020-08-08 21:29:51 +08:00
@xingjue 喜欢认爹就自己认, 别替别人认谢谢, 而且 v8 性能强只是在动态语言里强, 随便哪个脑子正常的静态语言用了正确的并发模型都可以吊打 node
|
 |
38
nash 2021-12-01 10:40:48 +08:00
没必要为这种问题恶语相向，市场证明一切，打开招聘网站看看就知道了
|
Select Language