l**h
发帖数: 893 | 1 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
response。
没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
服务器开的线程要轻量级很多？ |
h**********c
发帖数: 4120 | 2 等高手点解之后，再来跟进，没玩过nodes,
不过c++ 的话，很多参数可调,没玩过 |
p*****2
发帖数: 21240 | 3 async是os level的吧
【在 l**h 的大作中提到】
: 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
: request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
: call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
: 行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
: 比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
: async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
: invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
: response。
: 没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
: 服务器开的线程要轻量级很多？
|
i**i
发帖数: 1500 | 4 两个银行为客户服务的策略：
1. 开10个窗口。客户选一个最短的窗口排队，中间不换窗口。业务员可能做一些长时
间的操作。
2. 开10个窗口。用户先排成一列队。哪个窗口空闲了叫号下一个。如果操作需要等待
就让客户先坐下，服务下一个，完成了叫号。
哪个效率更高？直觉是2，理论计算只算“一列队”一项2就会领先.
2就是异步操作的模型。 |
h**********c
发帖数: 4120 | 5 以前这个版好象讨论过，异步就是select, 挂起来等signal，yield
同步就是你发我的东西没完我就不yield，就耗着
不确定，欢迎指正
非同步适合对话低带宽，个人感觉。stream还是同步好，有天才要开两个sockets;一个
对话，一个stream |
d******k
发帖数: 28 | 6 把这个比喻再改进一下：
多线程：
假设银行只有一个业务员(1个cpu core), 多线程就是开多个窗口，比如10个，然后业
务员在窗口之间跑来跑去(context switch), 每个窗口服务固定的时间(cpu time
slice),尽管有的客户的业务需要等待外部操作完成(Disk/Network IO)，比如要等运钞
车运来现金，业务员也得在那个窗口干等.
单线程Event IO:
只有一个窗口，客户排一个队。 遇到外部IO,比如等运钞车，就请客户出列，另外坐着
等，但是给一个呼叫器(call back), 运钞车来了，就call用户来继续处理。
可以看出单线程Event IO性能上的优点：
1. Non-blocking
2. 没有context switch.
【在 i**i 的大作中提到】
: 两个银行为客户服务的策略：
: 1. 开10个窗口。客户选一个最短的窗口排队，中间不换窗口。业务员可能做一些长时
: 间的操作。
: 2. 开10个窗口。用户先排成一列队。哪个窗口空闲了叫号下一个。如果操作需要等待
: 就让客户先坐下，服务下一个，完成了叫号。
: 哪个效率更高？直觉是2，理论计算只算“一列队”一项2就会领先.
: 2就是异步操作的模型。
|
n****1
发帖数: 1136 | 7 楼主半路出家？ IO密集型任务忙碌的是磁盘网卡之类的，如果你用sync，内核会把CPU
交给其他线程，如果用async，是在用户态把CPU利用到其他任务上。 说穿了，node就
是为了避免内核线程切换开销 |
l**h
发帖数: 893 | 8 这个比喻还是有问题，单线程Event IO，你是假设了I/O任务都不需要消耗CPU,所以主
JS程序可以一直占用cpu. 实际上，比如I/O你从磁盘读取数据，一样需要消耗少量CPU,
如果有一些并发的I/O,你的cpu,也需要不断做Context switch (对应你的例子，相当于有
不同的业务员)。
【在 d******k 的大作中提到】
: 把这个比喻再改进一下：
: 多线程：
: 假设银行只有一个业务员(1个cpu core), 多线程就是开多个窗口，比如10个，然后业
: 务员在窗口之间跑来跑去(context switch), 每个窗口服务固定的时间(cpu time
: slice),尽管有的客户的业务需要等待外部操作完成(Disk/Network IO)，比如要等运钞
: 车运来现金，业务员也得在那个窗口干等.
: 单线程Event IO:
: 只有一个窗口，客户排一个队。 遇到外部IO,比如等运钞车，就请客户出列，另外坐着
: 等，但是给一个呼叫器(call back), 运钞车来了，就call用户来继续处理。
: 可以看出单线程Event IO性能上的优点：
|
l**h
发帖数: 893 | 9 那你给讲得仔细一点吧。
你的意思是说，async call返回之后，就不在需要任何CPU资源？比如说在node里从磁
盘读一个文件到内存，async的load_file()被call然后很快返回等待，这个期间，读磁
盘这个工作是怎么完成的，不需要另外一个线程来处理吗？如果需要另外一个线程，不
也需要线程切换吗？
CPU
【在 n****1 的大作中提到】
: 楼主半路出家？ IO密集型任务忙碌的是磁盘网卡之类的，如果你用sync，内核会把CPU
: 交给其他线程，如果用async，是在用户态把CPU利用到其他任务上。 说穿了，node就
: 是为了避免内核线程切换开销
|
m********2
发帖数: 89 | 10 main event loop 直接 system call 把 io 任务交给 kernel, 不需要什么后台进程。
【在 l**h 的大作中提到】
: 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
: request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
: call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
: 行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
: 比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
: async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
: invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
: response。
: 没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
: 服务器开的线程要轻量级很多？
|
|
|
n******t
发帖数: 4406 | 11 这年头，tmd这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
【在 l**h 的大作中提到】
: 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
: request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
: call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
: 行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
: 比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
: async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
: invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
: response。
: 没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
: 服务器开的线程要轻量级很多？
|
d******k
发帖数: 28 | 12 运钞车是由专职司机(IO controller) 控制，是自己的processor. 可以直接访问内存
， IO过程中不需要CPU. IO完成了需要CPU的时候，会拍拍业务员的肩膀(硬件中断)来
得到CPU的响应。
CPU,
于有
【在 l**h 的大作中提到】
: 这个比喻还是有问题，单线程Event IO，你是假设了I/O任务都不需要消耗CPU,所以主
: JS程序可以一直占用cpu. 实际上，比如I/O你从磁盘读取数据，一样需要消耗少量CPU,
: 如果有一些并发的I/O,你的cpu,也需要不断做Context switch (对应你的例子，相当于有
: 不同的业务员)。
|
l**h
发帖数: 893 | 13 总算找到个还算满意的答案，就是利用系统的异步非阻塞I/O。
在LINUX下面，用的是libeio library，libeio是采用线程池与阻塞I/O模拟出来的异步
I/O。
在windows下面，用的是IOCP，IOCP内部依旧是通过线程实现，不同在于这些线程由系
统内核接手管理。
所以实质上，以前是由多个用户线程来完成任务,在NODE里面，变成了单个用户线程，
但是I/O利用了系统内核管理的多线程(windows下),或者是libeio内部的多线程(Linux
下)。
http://www.infoq.com/cn/articles/nodejs-asynchronous-io
【在 m********2 的大作中提到】
: main event loop 直接 system call 把 io 任务交给 kernel, 不需要什么后台进程。
|
l**h
发帖数: 893 | 14 恩，DMA (Direct memory access)
【在 d******k 的大作中提到】
: 运钞车是由专职司机(IO controller) 控制，是自己的processor. 可以直接访问内存
: ， IO过程中不需要CPU. IO完成了需要CPU的时候，会拍拍业务员的肩膀(硬件中断)来
: 得到CPU的响应。
:
: CPU,
: 于有
|
c*******9
发帖数: 9032 | 15 公司老板喜欢。程序员应当成立工会联合抵制。
【在 n******t 的大作中提到】
: 这年头，tmd这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
|
m********2
发帖数: 89 | 16 你不是问异步 sever比同步sever快在哪吗？显然不是快在所谓的“模拟异步”啊，你
自己不是一开始就说了。
Linux
【在 l**h 的大作中提到】
: 总算找到个还算满意的答案，就是利用系统的异步非阻塞I/O。
: 在LINUX下面，用的是libeio library，libeio是采用线程池与阻塞I/O模拟出来的异步
: I/O。
: 在windows下面，用的是IOCP，IOCP内部依旧是通过线程实现，不同在于这些线程由系
: 统内核接手管理。
: 所以实质上，以前是由多个用户线程来完成任务,在NODE里面，变成了单个用户线程，
: 但是I/O利用了系统内核管理的多线程(windows下),或者是libeio内部的多线程(Linux
: 下)。
: http://www.infoq.com/cn/articles/nodejs-asynchronous-io
|
i**i
发帖数: 1500 | 17 楼主比较搞笑。一开始楼主说在系统的负载比较大时, 采用异步一样会造成阻塞。然后
问为什么异步效率高。比较莫名其妙吧。
然后找了一个异步的实现，就说找到了满意的答案。 莫名其妙。
Linux
【在 l**h 的大作中提到】
: 总算找到个还算满意的答案，就是利用系统的异步非阻塞I/O。
: 在LINUX下面，用的是libeio library，libeio是采用线程池与阻塞I/O模拟出来的异步
: I/O。
: 在windows下面，用的是IOCP，IOCP内部依旧是通过线程实现，不同在于这些线程由系
: 统内核接手管理。
: 所以实质上，以前是由多个用户线程来完成任务,在NODE里面，变成了单个用户线程，
: 但是I/O利用了系统内核管理的多线程(windows下),或者是libeio内部的多线程(Linux
: 下)。
: http://www.infoq.com/cn/articles/nodejs-asynchronous-io
|
a9
发帖数: 21638 | 18 等于一个函数，还是会被同时在多个线程（进程）执行的是吗？
【在 i**i 的大作中提到】
: 两个银行为客户服务的策略：
: 1. 开10个窗口。客户选一个最短的窗口排队，中间不换窗口。业务员可能做一些长时
: 间的操作。
: 2. 开10个窗口。用户先排成一列队。哪个窗口空闲了叫号下一个。如果操作需要等待
: 就让客户先坐下，服务下一个，完成了叫号。
: 哪个效率更高？直觉是2，理论计算只算“一列队”一项2就会领先.
: 2就是异步操作的模型。
|
d****i
发帖数: 4809 | 19 Node.js的底层实现应该是OS的async IO吧，不同的OS有不同的实现, 比如
Linux:
http://man7.org/linux/man-pages/man7/aio.7.html
Solaris:
http://docs.oracle.com/cd/E19120-01/open.solaris/817-4415/chap7
AIX:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp
不过Linux的实现好像还有问题，所以node在Linux上还是用libevent的原因。
【在 l**h 的大作中提到】
: 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
: request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
: call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
: 行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
: 比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
: async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
: invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
: response。
: 没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
: 服务器开的线程要轻量级很多？
|
i**i
发帖数: 1500 | 20 可以这么说．比如磁盘读写，网络读写，都是在同时服务不同的请求.
对于CPU intensive的请求（函数），如果没有特殊处理，所有的请求都会受影响．这
种请求可以发给其他的线程，异步地得到结果．
在browser里，类似地可以通过"webworker"实现．http://www.html5rocks.com/en/tutorials/workers/basics/
【在 a9 的大作中提到】
: 等于一个函数，还是会被同时在多个线程（进程）执行的是吗？
|
|
|
s********k
发帖数: 6180 | 21 IO很多任务还真不需要CPU，都用DMA
CPU,
于有
【在 l**h 的大作中提到】
: 这个比喻还是有问题，单线程Event IO，你是假设了I/O任务都不需要消耗CPU,所以主
: JS程序可以一直占用cpu. 实际上，比如I/O你从磁盘读取数据，一样需要消耗少量CPU,
: 如果有一些并发的I/O,你的cpu,也需要不断做Context switch (对应你的例子，相当于有
: 不同的业务员)。
|
h**********c
发帖数: 4120 | 22 DMA to system buffer I guess. So from system buffer, it still needs read it
to application space. DMA to application space, it is a big security whole.
From system buffer (I think it is socket buffer) to application space, there
needs cpu overhead.
Is select(),test socket buffer or test NIC event?
【在 s********k 的大作中提到】
: IO很多任务还真不需要CPU，都用DMA
:
: CPU,
: 于有
|
s********k
发帖数: 6180 | 23 问题是从IO到systembuffer这段是最耗时间的，IO太慢了，所以这段耗时间的时候不用
CPU参与已经节约了很多
it
there
【在 h**********c 的大作中提到】
: DMA to system buffer I guess. So from system buffer, it still needs read it
: to application space. DMA to application space, it is a big security whole.
: From system buffer (I think it is socket buffer) to application space, there
: needs cpu overhead.
: Is select(),test socket buffer or test NIC event?
|
x****d
发帖数: 1766 | 24 楼主可能混淆了两种情况
只讲单纯http request，不说websocket xmlhttp/ajax，
1，request进来如果不做什么复杂的事情马上就回去了
2，request进来等比如数据库返回结果，假设等一分钟，
第二种情况不管你用node还是用tomcat/java都不关web server的事，
node只是一个web server，
weblogic/websphere 对第二种情况有专利的处理办法
如果自己做可以用jms连两个servlet，
处理request的servlet
把进来的request排队，
有结果了第二个response servlet按顺序返回结果回去
这个跟node没关系，和通常说的web server没关系
用node也可以这样处理长时间等数据库的请求
第一种情况，理论上请求多了也回堵车，
但实际上是不可能的，sync还是async其实都很快，
如果request多到要堵车，现实中这样的应用，
前面会有loadbalancer，
有reverse proxy，根本不用web server操心，
前面路由器都先死掉了，不会堵在node或者tomcat上
如果用ajax基本上差不多，
但是ajax来的请求其实是你自己给自己的请求
你不会把自己搞死吧？
websocket就是node比较牛逼了，
async的好处就体现了，
java处理的话，搞起来对程序猿要求高
主要是处理线程不好写，
和ajax一样，这些请求是你自己写的程序给自己的请求
不存在第一种情况。
ajax和websocket处理第二种情况，
也和http request一个道理，
要等的你可以排队，跟web server aync与否没关系，
返回不返回你都是在等别人。
只是async好做一点而已，但node也有他的问题
不深入讨论了
现实情况这些技术都是混用的，
你做个方案把他们搞在一起
楼主说的request进来要等，单纯讲是不存在的情况，
等你要看等什么，request你也要看什么request。 |
c*********e
发帖数: 16335 | 25 好多搞design的转node.js成了后台程序员。
【在 n******t 的大作中提到】
: 这年头，tmd这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
|
c*********e
发帖数: 16335 | 26 node.js用的一个线程。
【在 l**h 的大作中提到】
: 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
: request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
: call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
: 行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
: 比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
: async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
: invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
: response。
: 没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
: 服务器开的线程要轻量级很多？
|
b***e
发帖数: 1419 | 27 把node换成ruby还差不多。
【在 c*********e 的大作中提到】
: 好多搞design的转node.js成了后台程序员。
|
l**********n
发帖数: 8443 | 28 单线程有单线程的好处，多线程有多线程的好处。这就好像讨论西餐和中餐哪个好。有
意义吗 |
L***s
发帖数: 1148 | 29 先不谈不同OS层面的机制，IOCP／select／epoll神马的
在nodejs层面，简单地说就是一个大的event loop，单线程
每个async subroutine都注册到这个event loop上，逐个轮询
某个subroutine一旦io阻塞，就把CPU控制权yield回event loop
event loop再把CPU控制权交给下一个subroutine |
b***e
发帖数: 1419 | 30 我来改进一下这个银行的例子：
同步多线程：有50个一模一样的银行一字排开，每个银行里有分别有填表，A，B，C四
个不同的职能窗口。进入一个银行的顾客必须按照以下流程办事：
1. 填A表，
2. 在A窗口办理A表，等
3. 填B表，
4. 在B窗口办理B表，等
5. 填C表，
6. 在C窗口办理C表，等
7. 退出。
新顾客来了，挑一家无顾客的银行进入办事。如果所有的银行都满了，在外面排一队等
着。
异步单线程：有一个银行，里面有一个填表的窗口，50个A窗口，50个B窗口，50个C窗
口。每个顾客按以下流程办事。
1. 填A表，如果填表窗口有人，排填表队。
2. 填完A表，到一个A窗口办理A。如果所有的A窗口有人，排A队。
3. 填B表，如果填表窗口有人，排填表队。
4. 填完B表，到一个B窗口办理B。如果所有的B窗口有人，排B队。
5. 填C表，如果填表窗口有人，排填表队。
6. 填完C表，到一个C窗口办理C。如果所有的C窗口有人，排C队。
7. C办完了，退出。
可以看出，在同步多线程的模型里，在C窗口办理的时候，A窗口和B窗口是闲置的。而
在异步单线程里，A窗口是fully throttled，没有闲置的时候。所以异步单线程的模型
提高的流水线(pipeline)的效率。
但是，因为单线程只有一个CPU(填表窗口)，如果有一个傻逼填表巨慢，那就完蛋了，
谁也别想动。所以用node做online的时候不能搞复杂的计算，比如说排序很长的array
。但是一般的假设是填表是非常小的job，与窗口办理相比几乎不花时间。也就是说
node作为online server，只适用于IO bound application，不适用于CPU bound
application。
CPU,
于有
【在 l**h 的大作中提到】
: 这个比喻还是有问题，单线程Event IO，你是假设了I/O任务都不需要消耗CPU,所以主
: JS程序可以一直占用cpu. 实际上，比如I/O你从磁盘读取数据，一样需要消耗少量CPU,
: 如果有一些并发的I/O,你的cpu,也需要不断做Context switch (对应你的例子，相当于有
: 不同的业务员)。
|
|
|
n******n
发帖数: 12088 | 31 你这个比喻里，IO的角色是啥？填表和办理表分别对应什么？
【在 b***e 的大作中提到】
: 我来改进一下这个银行的例子：
: 同步多线程：有50个一模一样的银行一字排开，每个银行里有分别有填表，A，B，C四
: 个不同的职能窗口。进入一个银行的顾客必须按照以下流程办事：
: 1. 填A表，
: 2. 在A窗口办理A表，等
: 3. 填B表，
: 4. 在B窗口办理B表，等
: 5. 填C表，
: 6. 在C窗口办理C表，等
: 7. 退出。
|
e*******o
发帖数: 4654 | 32 you are right.
I write js everyday without understand it. Just to make it work.
The problem is I can not find a good book to explain it clearly.
【在 n******t 的大作中提到】
: 这年头，tmd这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
|
p*****2
发帖数: 21240 | 33 cpu bound 多线程也没戏
【在 b***e 的大作中提到】
: 我来改进一下这个银行的例子：
: 同步多线程：有50个一模一样的银行一字排开，每个银行里有分别有填表，A，B，C四
: 个不同的职能窗口。进入一个银行的顾客必须按照以下流程办事：
: 1. 填A表，
: 2. 在A窗口办理A表，等
: 3. 填B表，
: 4. 在B窗口办理B表，等
: 5. 填C表，
: 6. 在C窗口办理C表，等
: 7. 退出。
|
n******n
发帖数: 12088 | 34 Talk to your tech lead
【在 e*******o 的大作中提到】
: you are right.
: I write js everyday without understand it. Just to make it work.
: The problem is I can not find a good book to explain it clearly.
|
b***e
发帖数: 1419 | 35 填表是cpu bound, 窗口办理是io bound. 所以异步模式加强了流水线的throughput,
并不是latency.
Node, on the other hand, also improves latency via its lighter than feather
weight "context switch". For one request handling "thread" to switch to
another request handling, there is only a function closure application, as
simple as that. There's no full fledge thread state reviving as those can
be found in thread lib implementations.
【在 n******n 的大作中提到】
: 你这个比喻里，IO的角色是啥？填表和办理表分别对应什么？
|
b***e
发帖数: 1419 | 36 是。但是每个thread都会move forward。大象虽慢，不耽误老鼠从旁边快速通过。Node
里面一只大象会挡住所有的老鼠，谁也走不了。
【在 p*****2 的大作中提到】
: cpu bound 多线程也没戏
|
p*****2
发帖数: 21240 | 37 cluster
Node
【在 b***e 的大作中提到】
: 是。但是每个thread都会move forward。大象虽慢，不耽误老鼠从旁边快速通过。Node
: 里面一只大象会挡住所有的老鼠，谁也走不了。
|
l**********n
发帖数: 8443 | 38 node实际上是多线程
Node
【在 b***e 的大作中提到】
: 是。但是每个thread都会move forward。大象虽慢，不耽误老鼠从旁边快速通过。Node
: 里面一只大象会挡住所有的老鼠，谁也走不了。
|
b***e
发帖数: 1419 | 39 But you cannot start a process (in cluster) for each request handling, right
? if one request handling is hanging there...
【在 p*****2 的大作中提到】
: cluster
:
: Node
|
b***e
发帖数: 1419 | 40 不知所云。
【在 l**********n 的大作中提到】
: node实际上是多线程
:
: Node
|
|
|
p*****2
发帖数: 21240 | 41
right
multi thread一般也是用thread pool，不是一个request一个thread，那样其实也不好
。
【在 b***e 的大作中提到】
: But you cannot start a process (in cluster) for each request handling, right
: ? if one request handling is hanging there...
|
b***e
发帖数: 1419 | 42 Ok, let me try it from the flip side:
In Tomcat, one thread only handles one request. In express, one thread is
handling all the requests. So if you sort a huge array for 5 minutes in one
of the request handling, tomcat will become slower but still allow other
requests to be processed, but express will just hang and will not allow any
request to be processed.
【在 p*****2 的大作中提到】
:
: right
: multi thread一般也是用thread pool，不是一个request一个thread，那样其实也不好
: 。
|
l**********n
发帖数: 8443 | 43 why you want to sort a huge thread in the main thread? you should do it
through callback.
one
any
【在 b***e 的大作中提到】
: Ok, let me try it from the flip side:
: In Tomcat, one thread only handles one request. In express, one thread is
: handling all the requests. So if you sort a huge array for 5 minutes in one
: of the request handling, tomcat will become slower but still allow other
: requests to be processed, but express will just hang and will not allow any
: request to be processed.
|
g*****g
发帖数: 34805 | 44 There's only one thread in the node process, you can delegate the IO tasks
but not the calculation task, unless you spawn a child process.
【在 l**********n 的大作中提到】
: why you want to sort a huge thread in the main thread? you should do it
: through callback.
:
: one
: any
|
p*****2
发帖数: 21240 | 45
cluster是multi process的，没什么问题。
【在 g*****g 的大作中提到】
: There's only one thread in the node process, you can delegate the IO tasks
: but not the calculation task, unless you spawn a child process.
|
p*****2
发帖数: 21240 | 46
one
any
用cluster的话，其他process还是可以process其他request的。如果你真用一个thread
的话，你可以把这个work offload到其他process上的。
就是master process处理http request，其他process来做这个sorting的work。
【在 b***e 的大作中提到】
: Ok, let me try it from the flip side:
: In Tomcat, one thread only handles one request. In express, one thread is
: handling all the requests. So if you sort a huge array for 5 minutes in one
: of the request handling, tomcat will become slower but still allow other
: requests to be processed, but express will just hang and will not allow any
: request to be processed.
|
b***e
发帖数: 1419 | 47 Possible. But then you have to pass serialized data over to another process
, which may be inefficient, especially when the data is big. If it is
multithreaded, then you have shared memory across threads.
thread
【在 p*****2 的大作中提到】
:
: one
: any
: 用cluster的话，其他process还是可以process其他request的。如果你真用一个thread
: 的话，你可以把这个work offload到其他process上的。
: 就是master process处理http request，其他process来做这个sorting的work。
|
p*****2
发帖数: 21240 | 48 这个确实是。 所以我们在看go。不过这又是另一个话题了。
process
【在 b***e 的大作中提到】
: Possible. But then you have to pass serialized data over to another process
: , which may be inefficient, especially when the data is big. If it is
: multithreaded, then you have shared memory across threads.
:
: thread
|
w**z
发帖数: 8232 | 49 Tomcat has NIO connector also.
https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#NIO_specific_
configuration
http://www.tomcatexpert.com/blog/2011/06/17/nio-implementation-
one
any
【在 b***e 的大作中提到】
: Ok, let me try it from the flip side:
: In Tomcat, one thread only handles one request. In express, one thread is
: handling all the requests. So if you sort a huge array for 5 minutes in one
: of the request handling, tomcat will become slower but still allow other
: requests to be processed, but express will just hang and will not allow any
: request to be processed.
|
b***e
发帖数: 1419 | 50 I didn't connect the dots? What's the relation between NIO and the topic we
are talking about here? That seems to resolved another problem. In this
post, we are trading off the two models, multithreaded + sync vs. single-
threaded + async.
【在 w**z 的大作中提到】
: Tomcat has NIO connector also.
: https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#NIO_specific_
: configuration
: http://www.tomcatexpert.com/blog/2011/06/17/nio-implementation-
:
: one
: any
|
|
|
w**z
发帖数: 8232 | 51 NIO connector is Tomcat's way to increase throughput. Also Nginx is also
doing that. I feel it is very relevant to the topic. Async vs Sync.
we
【在 b***e 的大作中提到】
: I didn't connect the dots? What's the relation between NIO and the topic we
: are talking about here? That seems to resolved another problem. In this
: post, we are trading off the two models, multithreaded + sync vs. single-
: threaded + async.
|
d****r
发帖数: 300 | 52 本质上，single thread way 需把task分成简单的和复杂的，简单的立刻响应，复杂的
丢到job queue里让別的thread pool慢慢干，然后callback, 这样系统的总体响应就快
了，而且号称能
处理几百万concurrent requests。
【在 p*****2 的大作中提到】
: 这个确实是。 所以我们在看go。不过这又是另一个话题了。
:
: process
|
p*****2
发帖数: 21240 | 53 cpu bound 没啥区别 你接了request 还是不能respond
【在 d****r 的大作中提到】
: 本质上，single thread way 需把task分成简单的和复杂的，简单的立刻响应，复杂的
: 丢到job queue里让別的thread pool慢慢干，然后callback, 这样系统的总体响应就快
: 了，而且号称能
: 处理几百万concurrent requests。
|
d****r
发帖数: 300 | 54 是的，其实活还是那么多，CPU还是那么快，没有奇迹会发生。能做的只是选择，比如
少放几个thread去处理heavy duty 的task，这样能确保小task的处理速度。用什么模
式和进来request 的种类很有关系。比如都是transcoding的request，single thread
way就没意义了。
【在 p*****2 的大作中提到】
: cpu bound 没啥区别 你接了request 还是不能respond
|
j********x
发帖数: 2330 | 55 cpu bound的东西你用毛的async。。。
拿避孕套做热气球么。。。
行为艺术？
we
【在 b***e 的大作中提到】
: I didn't connect the dots? What's the relation between NIO and the topic we
: are talking about here? That seems to resolved another problem. In this
: post, we are trading off the two models, multithreaded + sync vs. single-
: threaded + async.
|
g*********e
发帖数: 14401 | 56 我也有同样的问题
【在 l**h 的大作中提到】
: 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
: request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
: call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
: 行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
: 比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
: async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
: invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
: response。
: 没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
: 服务器开的线程要轻量级很多？
|
g*********e
发帖数: 14401 | 57 你第一个例子里面 如果有disk io 之类 操作系统一样会切换线程的
【在 d******k 的大作中提到】
: 把这个比喻再改进一下：
: 多线程：
: 假设银行只有一个业务员(1个cpu core), 多线程就是开多个窗口，比如10个，然后业
: 务员在窗口之间跑来跑去(context switch), 每个窗口服务固定的时间(cpu time
: slice),尽管有的客户的业务需要等待外部操作完成(Disk/Network IO)，比如要等运钞
: 车运来现金，业务员也得在那个窗口干等.
: 单线程Event IO:
: 只有一个窗口，客户排一个队。 遇到外部IO,比如等运钞车，就请客户出列，另外坐着
: 等，但是给一个呼叫器(call back), 运钞车来了，就call用户来继续处理。
: 可以看出单线程Event IO性能上的优点：
|
h**********c
发帖数: 4120 | 58 我想node是是自己定义file descriptor吧，所以可以多开一些websocket,就象微软的
３２内寸扩展一样
file descriptor 多了，其实default就８万多，连接请求要进入异常处理，看起来快些
当年我门组chef world top AI，shiri他表叔直接挑kernel
大概就这么糊弄一下的吧 |
b***e
发帖数: 1419 | 59 Ok...read the url you gave again: the problem it solves is to reduce the
number of threads needed. The whole article does not mention improvement of
throughout. Maybe other articles mention it.
【在 w**z 的大作中提到】
: NIO connector is Tomcat's way to increase throughput. Also Nginx is also
: doing that. I feel it is very relevant to the topic. Async vs Sync.
:
: we
|
b***e
发帖数: 1419 | 60 我知道你丫当年为什么能从热气球里逃出来的么? 因为你丫有嘴剑.
【在 j********x 的大作中提到】
: cpu bound的东西你用毛的async。。。
: 拿避孕套做热气球么。。。
: 行为艺术？
:
: we
|
|
|
w**z
发帖数: 8232 | 61 NIO/Async 解决的问题就是增大throughput for IO bound cases. I thought that is
what we are talking about here.
of
【在 b***e 的大作中提到】
: Ok...read the url you gave again: the problem it solves is to reduce the
: number of threads needed. The whole article does not mention improvement of
: throughout. Maybe other articles mention it.
|
b***e
发帖数: 1419 | 62 Here's something I got from stackoverflow:
"NIO only helps to keep number of threads low (around the number of
available processors) and thus saves memory (each thread consume a lot of
memory) and allows enormous number of simultaneous connections, but usually
has worse performance than blocking IO."
Which is the same understanding as what I got. But I do find other texts
stating it facilitates throughput. My point was the essential mechanism of
NIO might not be the same as node.js single thread handling all requests
approach. But I do believe there could be implementations of NIO following
the same line of node.js design.
is
【在 w**z 的大作中提到】
: NIO/Async 解决的问题就是增大throughput for IO bound cases. I thought that is
: what we are talking about here.
:
: of
|
p*****2
发帖数: 21240 | 63 vertx
usually
of
following
【在 b***e 的大作中提到】
: Here's something I got from stackoverflow:
: "NIO only helps to keep number of threads low (around the number of
: available processors) and thus saves memory (each thread consume a lot of
: memory) and allows enormous number of simultaneous connections, but usually
: has worse performance than blocking IO."
: Which is the same understanding as what I got. But I do find other texts
: stating it facilitates throughput. My point was the essential mechanism of
: NIO might not be the same as node.js single thread handling all requests
: approach. But I do believe there could be implementations of NIO following
: the same line of node.js design.
|
b***e
发帖数: 1419 | 64 然. 但是这和NIO有乜关系?
我稍微研究了一下vert.x, 简直就是脱了裤子放屁. 基本就是用各种语言来模拟
Javascript. 整个就是另一个GWT. 这他妈的有意思吗? 京二你有啥大杀器的例子说
明vert.x有用吗?
【在 p*****2 的大作中提到】
: vertx
:
: usually
: of
: following
|
p*****2
发帖数: 21240 | 65 底层是nio
vertx现在还不成熟 但是简单易用 搞java的如获至宝
【在 b***e 的大作中提到】
: 然. 但是这和NIO有乜关系?
: 我稍微研究了一下vert.x, 简直就是脱了裤子放屁. 基本就是用各种语言来模拟
: Javascript. 整个就是另一个GWT. 这他妈的有意思吗? 京二你有啥大杀器的例子说
: 明vert.x有用吗?
|
z****e
发帖数: 54598 | 66 node吹嘘的性能提升，其实并没有得到真正的提升
这个你看各个web server的benchmark对比就知道
node从来也没有排在前面过，基本上都是中靠下的位置
https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=json
排在top几的基本上java居多，但是go也经常出现
其中go, netty, vert.x, undertow几个都曾出现在top5以内，甚至top3
当然这个ranking随时在变，因为各个web server也在不停滴更新和开发
其实node本身只是一个prototype
只是用来elaborate event是如何对比thread能有一定效率上的提升的
如何通过不block的方式，使得程序能够快速地执行
但是因为node本身的单线程的限制，使得node在event上获取的效率优势
很快又都赔掉了，综合看并不划算，但是这个node的榜样意义在于
你可以从node这种模式中学习如何制造一个异步的web server
然后获取效率上的提升
你看ranking中排第一个那个叫做undertow对吧？
那个东西就是经过red hat这种idea优化后的tomcat
哈哈哈，还有就是node其实带来了很多问题，比如callback hell
再比如多线程，因为单线程导致多个core无法有效滴利用起来，所以不得不跑多
process
怎么看，单线程都是很愚蠢的一种设计，当然对于写脚本的程序员来说
你要他们理解线程和进程，这个可能也有些勉为其难了吧
【在 l**h 的大作中提到】
: 相比传统的服务器多线程模型，Node的单线程的event driven模式，号称对I/O多的
: request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
: call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
: 行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
: 比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
: async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
: invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
: response。
: 没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
: 服务器开的线程要轻量级很多？
|
z****e
发帖数: 54598 | 67 event pool同样可以用多线程轮询
反正都是pool，互相不干扰就可以了
几个threads同时轮询，怎么看都比单个thread在那边苦跑要有效率
vert.x就是几个core爆几个threads
不像node，因为不支持thread，所以只能单个thread那边跑
这就是为什么node慢的主因
node就是慢，怎么看benchmark也都还是慢
慢得一塌糊涂，简直慢成了笑话
让我想起来推销各种优惠的阿三
我说，你这个打完折扣也还是比我现在用的贵啊，为什么要用你的折扣？
blablabla……最后就是告诉我，便宜啊便宜，你妹，这种便宜，快慢
都是文科生词汇，看了数值之后，自然会有判断，响应时间90是比100要低一点
但是90怎么看都比50要高一点，node的模型就是从100->90
那100可能是ruby或者python什么的脚本玩意，50是servlet
lol
【在 L***s 的大作中提到】
: 先不谈不同OS层面的机制，IOCP／select／epoll神马的
: 在nodejs层面，简单地说就是一个大的event loop，单线程
: 每个async subroutine都注册到这个event loop上，逐个轮询
: 某个subroutine一旦io阻塞，就把CPU控制权yield回event loop
: event loop再把CPU控制权交给下一个subroutine
|
p*****2
发帖数: 21240 | 68 多线程就会有race condition
单线程不用担心
【在 z****e 的大作中提到】
: event pool同样可以用多线程轮询
: 反正都是pool，互相不干扰就可以了
: 几个threads同时轮询，怎么看都比单个thread在那边苦跑要有效率
: vert.x就是几个core爆几个threads
: 不像node，因为不支持thread，所以只能单个thread那边跑
: 这就是为什么node慢的主因
: node就是慢，怎么看benchmark也都还是慢
: 慢得一塌糊涂，简直慢成了笑话
: 让我想起来推销各种优惠的阿三
: 我说，你这个打完折扣也还是比我现在用的贵啊，为什么要用你的折扣？
|
z****e
发帖数: 54598 | 69 本质上服务器就是多人一起访问的东西，当然会有race condition等并发问题
这就是服务器需要解决的问题，否则还要服务器干什么
【在 p*****2 的大作中提到】
: 多线程就会有race condition
: 单线程不用担心
|
p*****2
发帖数: 21240 | 70 可以在db层面解决
【在 z****e 的大作中提到】
: 本质上服务器就是多人一起访问的东西，当然会有race condition等并发问题
: 这就是服务器需要解决的问题，否则还要服务器干什么
|
|
|
z****e
发帖数: 54598 | 71 db - persistence/disk
app - service/memory
互不干扰
【在 p*****2 的大作中提到】
: 可以在db层面解决
|
p*****2
发帖数: 21240 | 72
in memory db
【在 z****e 的大作中提到】
: db - persistence/disk
: app - service/memory
: 互不干扰
|
z****e
发帖数: 54598 | 73 不适合建模，也不可能通过db来建模
【在 p*****2 的大作中提到】
:
: in memory db
|
