l**********n
发帖数: 8443 | |
z****e
发帖数: 54598 | 2 说的是这个吧？
http://jxcore.com/nodejx-vs-vert-x-vs-node-js-cluster/
下面tim的解释很清晰了
它关于vert.x的setup一直没给出来
不知道有啥好隐瞒的，到底是怎么run verticle的cmd就是一行的事
不敢给，那这个结果就很值得商榷了
多半是自吹自擂的产物，一个比较科学的benchmark需要给出各种东东
然后你自己能够重现他做的过程和得到类似的结果才对，就像techempower那样
Tim Fox obastemur . • 2 years ago
Sounds like a setup issue. If you're publish your actual benchmark setup
somewhere (with exact instructions for replicating) then people could take a
look, maybe see where the issues are, and re-run it. Most credible
benchmarks will make everything public, so results can be reproduced. Also (
footnote) ab sucks as a benchmarking tool. wrk (what techempower) uses is
much better :) |
w*s
发帖数: 7227 | 3 老赵，帮我把这个解解吧
http://www.mitbbs.com/article_t/Programming/31436283.html
【在 z****e 的大作中提到】
: 说的是这个吧？
: http://jxcore.com/nodejx-vs-vert-x-vs-node-js-cluster/
: 下面tim的解释很清晰了
: 它关于vert.x的setup一直没给出来
: 不知道有啥好隐瞒的，到底是怎么run verticle的cmd就是一行的事
: 不敢给，那这个结果就很值得商榷了
: 多半是自吹自擂的产物，一个比较科学的benchmark需要给出各种东东
: 然后你自己能够重现他做的过程和得到类似的结果才对，就像techempower那样
: Tim Fox obastemur . • 2 years ago
: Sounds like a setup issue. If you're publish your actual benchmark setup
|
z****e
发帖数: 54598 | |
w*s
发帖数: 7227 | 5 你先忙去吧，不急。多听听几位高手的意见总是好的。
【在 z****e 的大作中提到】
:
: 老姜不给了解释了？
: 我这下要出门下，回来看
|
d*******r
发帖数: 3299 | 6 据我的理解
Node 那个 cluster 是本机多进程使用
Vert.x 那个是分布式的 over message bus
【在 l**********n 的大作中提到】
: heard of JXCore?
|
z****e
发帖数: 54598 | 7
就是process vs thread
【在 d*******r 的大作中提到】
: 据我的理解
: Node 那个 cluster 是本机多进程使用
: Vert.x 那个是分布式的 over message bus
|
d*******r
发帖数: 3299 | 8 不止吧，Vert.x 应该是可以跑多机的吧
【在 z****e 的大作中提到】
:
: 就是process vs thread
|
l**********n
发帖数: 8443 | 9 跑多机就不是thread了
【在 d*******r 的大作中提到】
: 不止吧，Vert.x 应该是可以跑多机的吧
|
p*****2
发帖数: 21240 | 10
其实也不止thread。
【在 d*******r 的大作中提到】
: 不止吧，Vert.x 应该是可以跑多机的吧
|
|
|
l**********n
发帖数: 8443 | 11 nodejs + message queue 就相当于vert.x了吧。
【在 p*****2 的大作中提到】
:
: 其实也不止thread。
|
z****e
发帖数: 54598 | 12
process和thread都不分了？
这个试试不就知道了
techempower都把代码贴出来了
找2013年那次那个代码，自己试试就有结果了
【在 l**********n 的大作中提到】
: nodejs + message queue 就相当于vert.x了吧。
|
z****e
发帖数: 54598 | 13
总比什么thread都不用了的强太多
至少我还没看到同一个node上有其他的process出现
【在 p*****2 的大作中提到】
:
: 其实也不止thread。
|
z****e
发帖数: 54598 | 14
关于performance的问题
vert.x的google group很活跃
我鼓励你直接去挑战他们
tim fox很吃这一套
当然要给出源代码和具体的setups
而不是嘴巴上说，别人无法重现过程和结果，这个毫无意义
【在 l**********n 的大作中提到】
: 跑多机就不是thread了
|
z****e
发帖数: 54598 | 15 jxcore那个测试明显有问题
把最开始的反应时间当作所有的benchmark
10runs算个p啊，应该10^3以上才make sense
还有就是很明显代码，setups什么都没给
鬼知道他怎么测的，当别人要求用multiple threading测试的时候
作者居然不知道有multiple threading的设置，那搞p啊
说明根本没用过，因为对于socket的控制，tcp允许多个socket同时listen同一个port
但是udp不允许你这么干，所以还是需要在socket的verticle上做点设置才行
而对于http来说，我相信这个设置很重要，所以tim fox解释说是setup的问题
但是原作者根本没看懂这里面会有什么问题，这个太不可信了
anyway，这个测试很容易做，你自己试试就知道了
只要源代码和具体的setup给出来，自己跑最有说服力
相比之下techempower的源代码，setups都放在github上
你自己随时可以重现他们的测试，这个非常的有说服力
期待vert.x回到techempower的比武中去 |
x***4
发帖数: 1815 | 16 今天早上看了一下vertx。根据zhaoce的思路讲讲：
by default, 每个vertx instance （注意不是verticle）是multithread的. thread的
数目等于core的数目。 每条thread运行一个独立的event loop。
verticle instance（类似actor）被建立之后，会被assigned到其中一个event loop（
也就是一条thread）。vertx保证这一个verticle instance的code都一定会在assigned
的event loop（thread）上运行（除非你自己在verticle里开新的thread）。所以就不
存在race condition；什么synchronized, volatile, AtomicInteger之类的都可以扔
掉了。
至于jxcore的benchmark，我感觉是他只deploy了一个verticle instance，所以vertx
的几条thread中只有一条在运行，其他的都没事干，实际上变成了单线程。
这个理解对不对？
port
【在 z****e 的大作中提到】
: jxcore那个测试明显有问题
: 把最开始的反应时间当作所有的benchmark
: 10runs算个p啊，应该10^3以上才make sense
: 还有就是很明显代码，setups什么都没给
: 鬼知道他怎么测的，当别人要求用multiple threading测试的时候
: 作者居然不知道有multiple threading的设置，那搞p啊
: 说明根本没用过，因为对于socket的控制，tcp允许多个socket同时listen同一个port
: 但是udp不允许你这么干，所以还是需要在socket的verticle上做点设置才行
: 而对于http来说，我相信这个设置很重要，所以tim fox解释说是setup的问题
: 但是原作者根本没看懂这里面会有什么问题，这个太不可信了
|
p*****2
发帖数: 21240 | 17 你前边理解对
不过verticle之间share data还得靠lock
这个就不如node了 node根本不需要lock
assigned
vertx
【在 x***4 的大作中提到】
: 今天早上看了一下vertx。根据zhaoce的思路讲讲：
: by default, 每个vertx instance （注意不是verticle）是multithread的. thread的
: 数目等于core的数目。 每条thread运行一个独立的event loop。
: verticle instance（类似actor）被建立之后，会被assigned到其中一个event loop（
: 也就是一条thread）。vertx保证这一个verticle instance的code都一定会在assigned
: 的event loop（thread）上运行（除非你自己在verticle里开新的thread）。所以就不
: 存在race condition；什么synchronized, volatile, AtomicInteger之类的都可以扔
: 掉了。
: 至于jxcore的benchmark，我感觉是他只deploy了一个verticle instance，所以vertx
: 的几条thread中只有一条在运行，其他的都没事干，实际上变成了单线程。
|
l**********n
发帖数: 8443 | 18 inter process message passing 或者 inter thread message passing 和 message
queue比究竟如何？ |
z****e
发帖数: 54598 | 19 你的理解错了
verticle之间share data通过msg也就是json来做
这个东西还有lock？
msg是immutable
不需要lock
这个做法跟fp是一样的
如果通过map等share object，则需要搞成immutable
node根本没有thread，怎么共享data？
node效率一塌糊涂，这个第三方效率报告早就给出来了
【在 p*****2 的大作中提到】
: 你前边理解对
: 不过verticle之间share data还得靠lock
: 这个就不如node了 node根本不需要lock
:
: assigned
: vertx
|
z****e
发帖数: 54598 | 20
不用考虑这个了
tim fox曾经回答过关于bus的效率问题
他说已经足够快了，他说了具体的数字我忘了
但是他的意思是，他很怀疑有没有人需要这么高速度的bus
【在 l**********n 的大作中提到】
: inter process message passing 或者 inter thread message passing 和 message
: queue比究竟如何？
|
|
|
z****e
发帖数: 54598 | 21
assigned
vertx
差不多是这样滴
by default，vert.x会启动多个threads，根据你具体的cores来建
但是，一个verticle，只能被一个thread执行，在同一个时间点
所以如果你只写了一个verticle，然后启动vert.x去用这个verticle去listen某一个
port
那么虽然vert.x启动了多个threads，但是这个verticle只能被一个thread所执行
所以瓶颈就发生在这里，因为一个thread独占了这个verticle，其他threads就只能干
瞪眼了
也做不了什么事，所以这个时候，需要直接scale out，根据core数量
部署相同数量的verticles，这样多个threads就可以同时listen同一个port了
这个在v3文档中有很清晰的描写
DeploymentOptions options = new DeploymentOptions().setInstances(16);
vertx.deployVerticle("com.mycompany.MyOrderProcessorVerticle", options);
This is useful for scaling easily across multiple cores. For example you
might have a web-server verticle to deploy and multiple cores on your
machine, so you want to deploy multiple instances to take utilise all the
cores.
但是这个在udp中是不能这么搞的，因为socket跟tcp socket不一样
这个又是另外一回事了，因为udp的socket会跟port绑定，tcp不会
至于instance，这个只要是一个机器，或者虚拟机什么的
vert.x一般只会启动一个instance/process，然后在这个process里面跑多个threads
【在 x***4 的大作中提到】
: 今天早上看了一下vertx。根据zhaoce的思路讲讲：
: by default, 每个vertx instance （注意不是verticle）是multithread的. thread的
: 数目等于core的数目。 每条thread运行一个独立的event loop。
: verticle instance（类似actor）被建立之后，会被assigned到其中一个event loop（
: 也就是一条thread）。vertx保证这一个verticle instance的code都一定会在assigned
: 的event loop（thread）上运行（除非你自己在verticle里开新的thread）。所以就不
: 存在race condition；什么synchronized, volatile, AtomicInteger之类的都可以扔
: 掉了。
: 至于jxcore的benchmark，我感觉是他只deploy了一个verticle instance，所以vertx
: 的几条thread中只有一条在运行，其他的都没事干，实际上变成了单线程。
|
z****e
发帖数: 54598 | 22 verticle之间一般不share data
如果需要share data，则需要通过msg bus来完成
先将需要share的data转换成json，然后发送给其他的verticle
因为json是所有语言都能接受的这么一个数据格式
那json自然就是immutable的，在发送和接收过程中是无法被更改的
好吧，至少msg bus不会尝试去更改msg，这样就不需要lock了
原理跟fp的多线程原理是一样的
但是vert.x很巧妙滴用这种方式，绕开了immutable这个概念
你不知不觉中就用了fp的多线程的那种方式，就是actor model
但是这种方式呢，有些人会说，太麻烦
ok，那就用map这些来分享data
那这个时候就需要做成immutable的object了
因为actor model之间的share datas必需是immutable的
否则会破坏single threadness
但是这个技能有些高级，一般人可以不用
如果需要用的话，这个就很容易理解
另外，vert.x的lock也有，是Cluster-wide locks
不是threads之间share data的lock，不是一般人需要的
这个lock的意思就是对于某些resources，你有意lock住，不让其他threads来用的时候
这个时候才是用lock的地方，不是为了分享而lock，而恰恰是反过来
为了不分享某些resource而lock，这个你可以琢磨琢磨
在x3的文档上都写得很清晰 |
p*****2
发帖数: 21240 | 23 这个我知道
【在 z****e 的大作中提到】
: 你的理解错了
: verticle之间share data通过msg也就是json来做
: 这个东西还有lock？
: msg是immutable
: 不需要lock
: 这个做法跟fp是一样的
: 如果通过map等share object，则需要搞成immutable
: node根本没有thread，怎么共享data？
: node效率一塌糊涂，这个第三方效率报告早就给出来了
|
z****e
发帖数: 54598 | 24
我不觉得你知道，你说过好几次vert.x，无一例外都是错的
【在 p*****2 的大作中提到】
: 这个我知道
|
