请教一个Node.js的疑惑# Programming - 葵花宝典
d*z
1 楼
妈妈懂英文，自己填写I-539.还需填写interpreter statement吗？是不是person
preparing form 那一栏也空着？请指教.
preparing form 那一栏也空着？请指教.
b*a
2 楼
【 以下文字转载自 Family 讨论区 】
发信人: aptget (apt), 信区: Family
标 题: Body坑总结
发信站: BBS 未名空间站 (Sun Jun 3 17:46:08 2012, 美东)
Body自称北美top 5%高级电工，喜欢精彩人生，单身时买过跑车，身负高利贷巨款创业
亏损多年后开始盈利，打算加注。
xxk会计学位，喜欢传统男外女内，顾老顾小的简单生活，曾借娘家钱支持Body创业。
Body十年前搬运在国内应该有工作的xxk来美，办完身份，家中育有二子，分别为5岁和
2岁。xxk就一直在家带小孩。
Body理想生活是xxk工作带小孩他创业，xxk理想生活是Body赚大钱她在家一把手带孩子
成长，作为男人和女人，这都是积极正面的理想。
问题是这个能力他们都没有啊。Body创业成功率低，亏损严重，多年来xxk没有安全感
，xxk称Body无能并不负责满嘴跑火车（＝卢瑟）。xxk严重不满足于家庭条件，眼见家
庭健康不能保证（分娩麻醉药的保险金被用来投资），也没有自信去在新的国度尝试工
作，Body称xxk为孔子所说的女子，近则不逊，远则怨（＝泼妇）。
于是二人一度闹离婚。虽然他们的理想生活并不一致，但是十年来，事实上二人已（被
迫）接受现状，也许Body得到了自己想要的70%，xxk得到了自己想要的60%，都不是100
%。能力有限，没办法。有一点我比较看好，Body和xxk都有幽默感，Body厚颜无耻尊太
极式幽默，xxk倔强贫嘴尊挖苦式幽默。估计也是这个缘故，还撑了十年。我想，积极
的人总有好报，有些事情有了合理制度和权力分配、下放，尤其财政上，就可以各自作
取舍。艰难一时度过的话，能好好过下去也不是不可能的。
发信人: aptget (apt), 信区: Family
标 题: Body坑总结
发信站: BBS 未名空间站 (Sun Jun 3 17:46:08 2012, 美东)
Body自称北美top 5%高级电工，喜欢精彩人生，单身时买过跑车，身负高利贷巨款创业
亏损多年后开始盈利，打算加注。
xxk会计学位，喜欢传统男外女内，顾老顾小的简单生活，曾借娘家钱支持Body创业。
Body十年前搬运在国内应该有工作的xxk来美，办完身份，家中育有二子，分别为5岁和
2岁。xxk就一直在家带小孩。
Body理想生活是xxk工作带小孩他创业，xxk理想生活是Body赚大钱她在家一把手带孩子
成长，作为男人和女人，这都是积极正面的理想。
问题是这个能力他们都没有啊。Body创业成功率低，亏损严重，多年来xxk没有安全感
，xxk称Body无能并不负责满嘴跑火车（＝卢瑟）。xxk严重不满足于家庭条件，眼见家
庭健康不能保证（分娩麻醉药的保险金被用来投资），也没有自信去在新的国度尝试工
作，Body称xxk为孔子所说的女子，近则不逊，远则怨（＝泼妇）。
于是二人一度闹离婚。虽然他们的理想生活并不一致，但是十年来，事实上二人已（被
迫）接受现状，也许Body得到了自己想要的70%，xxk得到了自己想要的60%，都不是100
%。能力有限，没办法。有一点我比较看好，Body和xxk都有幽默感，Body厚颜无耻尊太
极式幽默，xxk倔强贫嘴尊挖苦式幽默。估计也是这个缘故，还撑了十年。我想，积极
的人总有好报，有些事情有了合理制度和权力分配、下放，尤其财政上，就可以各自作
取舍。艰难一时度过的话，能好好过下去也不是不可能的。
C*0
3 楼
RT，想要full cover的那种，就是手托那里也cover的，thx~~
l*h
4 楼
相比传统的服务器多线程模型，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后台的线程，比传统
服务器开的线程要轻量级很多？
request能够有更好的响应。但是我不理解的地方在于，request进来之后，async的
call一样需要开后台线程去运行啊(如果我没理解错，Node也maintain一个线程池去运
行这些async的call, 只是你的js主程序是单线程的，不会运行在多个线程).
比如，有很多request进来，很快发现Node后台的线程池满了，所以每个request虽然是
async的，但是一样要block在那里，直到有可用线程，来运行，完成之后，主程序再
invoke callback, 最后把结果返回给client端。request多的时候，客户端一样拿不到
response。
没理解为什么Node能够有效率提升。唯一能想到的就是，那些Node后台的线程，比传统
服务器开的线程要轻量级很多？
t*s
5 楼
当然没必要了
f*r
6 楼
哪个是你？
【在 b***a 的大作中提到】
: 【 以下文字转载自 Family 讨论区 】
: 发信人: aptget (apt), 信区: Family
: 标 题: Body坑总结
: 发信站: BBS 未名空间站 (Sun Jun 3 17:46:08 2012, 美东)
: Body自称北美top 5%高级电工，喜欢精彩人生，单身时买过跑车，身负高利贷巨款创业
: 亏损多年后开始盈利，打算加注。
: xxk会计学位，喜欢传统男外女内，顾老顾小的简单生活，曾借娘家钱支持Body创业。
: Body十年前搬运在国内应该有工作的xxk来美，办完身份，家中育有二子，分别为5岁和
: 2岁。xxk就一直在家带小孩。
: Body理想生活是xxk工作带小孩他创业，xxk理想生活是Body赚大钱她在家一把手带孩子
【在 b***a 的大作中提到】
: 【 以下文字转载自 Family 讨论区 】
: 发信人: aptget (apt), 信区: Family
: 标 题: Body坑总结
: 发信站: BBS 未名空间站 (Sun Jun 3 17:46:08 2012, 美东)
: Body自称北美top 5%高级电工，喜欢精彩人生，单身时买过跑车，身负高利贷巨款创业
: 亏损多年后开始盈利，打算加注。
: xxk会计学位，喜欢传统男外女内，顾老顾小的简单生活，曾借娘家钱支持Body创业。
: Body十年前搬运在国内应该有工作的xxk来美，办完身份，家中育有二子，分别为5岁和
: 2岁。xxk就一直在家带小孩。
: Body理想生活是xxk工作带小孩他创业，xxk理想生活是Body赚大钱她在家一把手带孩子
wy
7 楼
这个都要保护
【在 C***0 的大作中提到】
: RT，想要full cover的那种，就是手托那里也cover的，thx~~
【在 C***0 的大作中提到】
: RT，想要full cover的那种，就是手托那里也cover的，thx~~
h*c
8 楼
等高手点解之后，再来跟进，没玩过nodes,
不过c++ 的话，很多参数可调,没玩过
不过c++ 的话，很多参数可调,没玩过
b*a
9 楼
这好像是最近的饭米粒小坑。夏天到了，没大坑了。要等新生来了才会有
【在 f******r 的大作中提到】
: 哪个是你？
【在 f******r 的大作中提到】
: 哪个是你？
u*n
10 楼
官网上卖的没手托，我没管。不过我哥们直接在手托那贴了个apple的标志，拿来当手
托。
托。
p*2
11 楼
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后台的线程，比传统
: 服务器开的线程要轻量级很多？
【在 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后台的线程，比传统
: 服务器开的线程要轻量级很多？
f*r
12 楼
还以为你是男主呢
【在 b***a 的大作中提到】
: 这好像是最近的饭米粒小坑。夏天到了，没大坑了。要等新生来了才会有
【在 b***a 的大作中提到】
: 这好像是最近的饭米粒小坑。夏天到了，没大坑了。要等新生来了才会有
i*i
13 楼
两个银行为客户服务的策略：
1. 开10个窗口。客户选一个最短的窗口排队，中间不换窗口。业务员可能做一些长时
间的操作。
2. 开10个窗口。用户先排成一列队。哪个窗口空闲了叫号下一个。如果操作需要等待
就让客户先坐下，服务下一个，完成了叫号。
哪个效率更高？直觉是2，理论计算只算“一列队”一项2就会领先.
2就是异步操作的模型。
1. 开10个窗口。客户选一个最短的窗口排队，中间不换窗口。业务员可能做一些长时
间的操作。
2. 开10个窗口。用户先排成一列队。哪个窗口空闲了叫号下一个。如果操作需要等待
就让客户先坐下，服务下一个，完成了叫号。
哪个效率更高？直觉是2，理论计算只算“一列队”一项2就会领先.
2就是异步操作的模型。
b*a
14 楼
该配眼镜了，咳咳
【在 f******r 的大作中提到】
: 还以为你是男主呢
【在 f******r 的大作中提到】
: 还以为你是男主呢
h*c
15 楼
以前这个版好象讨论过，异步就是select, 挂起来等signal，yield
同步就是你发我的东西没完我就不yield，就耗着
不确定，欢迎指正
非同步适合对话低带宽，个人感觉。stream还是同步好，有天才要开两个sockets;一个
对话，一个stream
同步就是你发我的东西没完我就不yield，就耗着
不确定，欢迎指正
非同步适合对话低带宽，个人感觉。stream还是同步好，有天才要开两个sockets;一个
对话，一个stream
f*r
16 楼
嗯，仔细看了看，他比你好看
【在 b***a 的大作中提到】
: 该配眼镜了，咳咳
【在 b***a 的大作中提到】
: 该配眼镜了，咳咳
d*k
17 楼
把这个比喻再改进一下：
多线程：
假设银行只有一个业务员(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就是异步操作的模型。
多线程：
假设银行只有一个业务员(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就是异步操作的模型。
b*a
18 楼
未明形象太害人了
【在 f******r 的大作中提到】
: 嗯，仔细看了看，他比你好看
【在 f******r 的大作中提到】
: 嗯，仔细看了看，他比你好看
n*1
19 楼
楼主半路出家？ IO密集型任务忙碌的是磁盘网卡之类的，如果你用sync，内核会把CPU
交给其他线程，如果用async，是在用户态把CPU利用到其他任务上。 说穿了，node就
是为了避免内核线程切换开销
交给其他线程，如果用async，是在用户态把CPU利用到其他任务上。 说穿了，node就
是为了避免内核线程切换开销
f*r
20 楼
谁让你这么实诚。。一定要用自己的照片
【在 b***a 的大作中提到】
: 未明形象太害人了
【在 b***a 的大作中提到】
: 未明形象太害人了
l*h
21 楼
这个比喻还是有问题，单线程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性能上的优点：
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性能上的优点：
b*a
22 楼
为了弘扬中国功夫
【在 f******r 的大作中提到】
: 谁让你这么实诚。。一定要用自己的照片
【在 f******r 的大作中提到】
: 谁让你这么实诚。。一定要用自己的照片
l*h
23 楼
那你给讲得仔细一点吧。
你的意思是说，async call返回之后，就不在需要任何CPU资源？比如说在node里从磁
盘读一个文件到内存，async的load_file()被call然后很快返回等待，这个期间，读磁
盘这个工作是怎么完成的，不需要另外一个线程来处理吗？如果需要另外一个线程，不
也需要线程切换吗？
CPU
【在 n****1 的大作中提到】
: 楼主半路出家？ IO密集型任务忙碌的是磁盘网卡之类的，如果你用sync，内核会把CPU
: 交给其他线程，如果用async，是在用户态把CPU利用到其他任务上。 说穿了，node就
: 是为了避免内核线程切换开销
你的意思是说，async call返回之后，就不在需要任何CPU资源？比如说在node里从磁
盘读一个文件到内存，async的load_file()被call然后很快返回等待，这个期间，读磁
盘这个工作是怎么完成的，不需要另外一个线程来处理吗？如果需要另外一个线程，不
也需要线程切换吗？
CPU
【在 n****1 的大作中提到】
: 楼主半路出家？ IO密集型任务忙碌的是磁盘网卡之类的，如果你用sync，内核会把CPU
: 交给其他线程，如果用async，是在用户态把CPU利用到其他任务上。 说穿了，node就
: 是为了避免内核线程切换开销
f*r
24 楼
穿上衣服就不能弘扬了？
【在 b***a 的大作中提到】
: 为了弘扬中国功夫
【在 b***a 的大作中提到】
: 为了弘扬中国功夫
m*2
25 楼
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后台的线程，比传统
: 服务器开的线程要轻量级很多？
【在 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*a
26 楼
穿了衣服手脚没这么利落
【在 f******r 的大作中提到】
: 穿上衣服就不能弘扬了？
【在 f******r 的大作中提到】
: 穿上衣服就不能弘扬了？
n*t
27 楼
这年头，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后台的线程，比传统
: 服务器开的线程要轻量级很多？
【在 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后台的线程，比传统
: 服务器开的线程要轻量级很多？
f*r
28 楼
那对敌的时候怎么办？ 先脱？
【在 b***a 的大作中提到】
: 穿了衣服手脚没这么利落
【在 b***a 的大作中提到】
: 穿了衣服手脚没这么利落
d*k
29 楼
运钞车是由专职司机(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 (对应你的例子，相当于有
: 不同的业务员)。
， IO过程中不需要CPU. IO完成了需要CPU的时候，会拍拍业务员的肩膀(硬件中断)来
得到CPU的响应。
CPU,
于有
【在 l**h 的大作中提到】
: 这个比喻还是有问题，单线程Event IO，你是假设了I/O任务都不需要消耗CPU,所以主
: JS程序可以一直占用cpu. 实际上，比如I/O你从磁盘读取数据，一样需要消耗少量CPU,
: 如果有一些并发的I/O,你的cpu,也需要不断做Context switch (对应你的例子，相当于有
: 不同的业务员)。
b*a
30 楼
笨，都不穿不就行了
【在 f******r 的大作中提到】
: 那对敌的时候怎么办？ 先脱？
【在 f******r 的大作中提到】
: 那对敌的时候怎么办？ 先脱？
l*h
31 楼
总算找到个还算满意的答案，就是利用系统的异步非阻塞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, 不需要什么后台进程。
在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, 不需要什么后台进程。
f*r
32 楼
那还要先脱敌人衣服？
【在 b***a 的大作中提到】
: 笨，都不穿不就行了
【在 b***a 的大作中提到】
: 笨，都不穿不就行了
l*h
33 楼
恩，DMA (Direct memory access)
【在 d******k 的大作中提到】
: 运钞车是由专职司机(IO controller) 控制，是自己的processor. 可以直接访问内存
: ， IO过程中不需要CPU. IO完成了需要CPU的时候，会拍拍业务员的肩膀(硬件中断)来
: 得到CPU的响应。
:
: CPU,
: 于有
【在 d******k 的大作中提到】
: 运钞车是由专职司机(IO controller) 控制，是自己的processor. 可以直接访问内存
: ， IO过程中不需要CPU. IO完成了需要CPU的时候，会拍拍业务员的肩膀(硬件中断)来
: 得到CPU的响应。
:
: CPU,
: 于有
b*a
34 楼
敌人不用利索啊，手脚捆起来更好
【在 f******r 的大作中提到】
: 那还要先脱敌人衣服？
【在 f******r 的大作中提到】
: 那还要先脱敌人衣服？
c*9
35 楼
公司老板喜欢。程序员应当成立工会联合抵制。
【在 n******t 的大作中提到】
: 这年头，tmd这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
【在 n******t 的大作中提到】
: 这年头，tmd这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
f*r
36 楼
你到底在做什么？
【在 b***a 的大作中提到】
: 敌人不用利索啊，手脚捆起来更好
【在 b***a 的大作中提到】
: 敌人不用利索啊，手脚捆起来更好
m*2
37 楼
你不是问异步 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
自己不是一开始就说了。
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
b*a
38 楼
歼敌
【在 f******r 的大作中提到】
: 你到底在做什么？
【在 f******r 的大作中提到】
: 你到底在做什么？
i*i
39 楼
楼主比较搞笑。一开始楼主说在系统的负载比较大时, 采用异步一样会造成阻塞。然后
问为什么异步效率高。比较莫名其妙吧。
然后找了一个异步的实现，就说找到了满意的答案。 莫名其妙。
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
问为什么异步效率高。比较莫名其妙吧。
然后找了一个异步的实现，就说找到了满意的答案。 莫名其妙。
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
f*r
40 楼
还好没typo
【在 b***a 的大作中提到】
: 歼敌
【在 b***a 的大作中提到】
: 歼敌
a9
41 楼
等于一个函数，还是会被同时在多个线程（进程）执行的是吗？
【在 i**i 的大作中提到】
: 两个银行为客户服务的策略：
: 1. 开10个窗口。客户选一个最短的窗口排队，中间不换窗口。业务员可能做一些长时
: 间的操作。
: 2. 开10个窗口。用户先排成一列队。哪个窗口空闲了叫号下一个。如果操作需要等待
: 就让客户先坐下，服务下一个，完成了叫号。
: 哪个效率更高？直觉是2，理论计算只算“一列队”一项2就会领先.
: 2就是异步操作的模型。
【在 i**i 的大作中提到】
: 两个银行为客户服务的策略：
: 1. 开10个窗口。客户选一个最短的窗口排队，中间不换窗口。业务员可能做一些长时
: 间的操作。
: 2. 开10个窗口。用户先排成一列队。哪个窗口空闲了叫号下一个。如果操作需要等待
: 就让客户先坐下，服务下一个，完成了叫号。
: 哪个效率更高？直觉是2，理论计算只算“一列队”一项2就会领先.
: 2就是异步操作的模型。
b*a
42 楼
你太邪恶了
【在 f******r 的大作中提到】
: 还好没typo
【在 f******r 的大作中提到】
: 还好没typo
d*i
43 楼
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后台的线程，比传统
: 服务器开的线程要轻量级很多？
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后台的线程，比传统
: 服务器开的线程要轻量级很多？
f*r
44 楼
评价这么高？ 一般一般
【在 b***a 的大作中提到】
: 你太邪恶了
【在 b***a 的大作中提到】
: 你太邪恶了
i*i
45 楼
可以这么说．比如磁盘读写，网络读写，都是在同时服务不同的请求.
对于CPU intensive的请求（函数），如果没有特殊处理，所有的请求都会受影响．这
种请求可以发给其他的线程，异步地得到结果．
在browser里，类似地可以通过"webworker"实现．http://www.html5rocks.com/en/tutorials/workers/basics/
【在 a9 的大作中提到】
: 等于一个函数，还是会被同时在多个线程（进程）执行的是吗？
对于CPU intensive的请求（函数），如果没有特殊处理，所有的请求都会受影响．这
种请求可以发给其他的线程，异步地得到结果．
在browser里，类似地可以通过"webworker"实现．http://www.html5rocks.com/en/tutorials/workers/basics/
【在 a9 的大作中提到】
: 等于一个函数，还是会被同时在多个线程（进程）执行的是吗？
b*a
46 楼
咳咳，整风运动如火如荼呢
【在 f******r 的大作中提到】
: 评价这么高？ 一般一般
【在 f******r 的大作中提到】
: 评价这么高？ 一般一般
s*k
47 楼
IO很多任务还真不需要CPU，都用DMA
CPU,
于有
【在 l**h 的大作中提到】
: 这个比喻还是有问题，单线程Event IO，你是假设了I/O任务都不需要消耗CPU,所以主
: JS程序可以一直占用cpu. 实际上，比如I/O你从磁盘读取数据，一样需要消耗少量CPU,
: 如果有一些并发的I/O,你的cpu,也需要不断做Context switch (对应你的例子，相当于有
: 不同的业务员)。
CPU,
于有
【在 l**h 的大作中提到】
: 这个比喻还是有问题，单线程Event IO，你是假设了I/O任务都不需要消耗CPU,所以主
: JS程序可以一直占用cpu. 实际上，比如I/O你从磁盘读取数据，一样需要消耗少量CPU,
: 如果有一些并发的I/O,你的cpu,也需要不断做Context switch (对应你的例子，相当于有
: 不同的业务员)。
f*r
48 楼
版三不在，别怕
【在 b***a 的大作中提到】
: 咳咳，整风运动如火如荼呢
【在 b***a 的大作中提到】
: 咳咳，整风运动如火如荼呢
h*c
49 楼
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,
: 于有
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,
: 于有
b*a
50 楼
那就弄死丫的
【在 f******r 的大作中提到】
: 版三不在，别怕
【在 f******r 的大作中提到】
: 版三不在，别怕
s*k
51 楼
问题是从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?
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?
f*r
52 楼
。。。别这么狠，小心他先封了你
【在 b***a 的大作中提到】
: 那就弄死丫的
【在 b***a 的大作中提到】
: 那就弄死丫的
x*d
53 楼
楼主可能混淆了两种情况
只讲单纯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。
只讲单纯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。
b*a
54 楼
我可以自己解封啊
【在 f******r 的大作中提到】
: 。。。别这么狠，小心他先封了你
【在 f******r 的大作中提到】
: 。。。别这么狠，小心他先封了你
c*e
55 楼
好多搞design的转node.js成了后台程序员。
【在 n******t 的大作中提到】
: 这年头，tmd这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
【在 n******t 的大作中提到】
: 这年头，tmd这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
c*e
56 楼
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后台的线程，比传统
: 服务器开的线程要轻量级很多？
【在 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
57 楼
把node换成ruby还差不多。
【在 c*********e 的大作中提到】
: 好多搞design的转node.js成了后台程序员。
【在 c*********e 的大作中提到】
: 好多搞design的转node.js成了后台程序员。
l*n
58 楼
单线程有单线程的好处，多线程有多线程的好处。这就好像讨论西餐和中餐哪个好。有
意义吗
意义吗
L*s
59 楼
先不谈不同OS层面的机制，IOCP／select／epoll神马的
在nodejs层面，简单地说就是一个大的event loop，单线程
每个async subroutine都注册到这个event loop上，逐个轮询
某个subroutine一旦io阻塞，就把CPU控制权yield回event loop
event loop再把CPU控制权交给下一个subroutine
在nodejs层面，简单地说就是一个大的event loop，单线程
每个async subroutine都注册到这个event loop上，逐个轮询
某个subroutine一旦io阻塞，就把CPU控制权yield回event loop
event loop再把CPU控制权交给下一个subroutine
b*e
60 楼
我来改进一下这个银行的例子：
同步多线程：有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 (对应你的例子，相当于有
: 不同的业务员)。
同步多线程：有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
61 楼
你这个比喻里，IO的角色是啥？填表和办理表分别对应什么？
【在 b***e 的大作中提到】
: 我来改进一下这个银行的例子：
: 同步多线程：有50个一模一样的银行一字排开，每个银行里有分别有填表，A，B，C四
: 个不同的职能窗口。进入一个银行的顾客必须按照以下流程办事：
: 1. 填A表，
: 2. 在A窗口办理A表，等
: 3. 填B表，
: 4. 在B窗口办理B表，等
: 5. 填C表，
: 6. 在C窗口办理C表，等
: 7. 退出。
【在 b***e 的大作中提到】
: 我来改进一下这个银行的例子：
: 同步多线程：有50个一模一样的银行一字排开，每个银行里有分别有填表，A，B，C四
: 个不同的职能窗口。进入一个银行的顾客必须按照以下流程办事：
: 1. 填A表，
: 2. 在A窗口办理A表，等
: 3. 填B表，
: 4. 在B窗口办理B表，等
: 5. 填C表，
: 6. 在C窗口办理C表，等
: 7. 退出。
e*o
62 楼
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这些莫名其妙的语言，搞的小孩子都不知道他们在写啥!
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
63 楼
cpu bound 多线程也没戏
【在 b***e 的大作中提到】
: 我来改进一下这个银行的例子：
: 同步多线程：有50个一模一样的银行一字排开，每个银行里有分别有填表，A，B，C四
: 个不同的职能窗口。进入一个银行的顾客必须按照以下流程办事：
: 1. 填A表，
: 2. 在A窗口办理A表，等
: 3. 填B表，
: 4. 在B窗口办理B表，等
: 5. 填C表，
: 6. 在C窗口办理C表，等
: 7. 退出。
【在 b***e 的大作中提到】
: 我来改进一下这个银行的例子：
: 同步多线程：有50个一模一样的银行一字排开，每个银行里有分别有填表，A，B，C四
: 个不同的职能窗口。进入一个银行的顾客必须按照以下流程办事：
: 1. 填A表，
: 2. 在A窗口办理A表，等
: 3. 填B表，
: 4. 在B窗口办理B表，等
: 5. 填C表，
: 6. 在C窗口办理C表，等
: 7. 退出。
n*n
64 楼
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.
【在 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
65 楼
填表是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的角色是啥？填表和办理表分别对应什么？
并不是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
66 楼
是。但是每个thread都会move forward。大象虽慢，不耽误老鼠从旁边快速通过。Node
里面一只大象会挡住所有的老鼠，谁也走不了。
【在 p*****2 的大作中提到】
: cpu bound 多线程也没戏
里面一只大象会挡住所有的老鼠，谁也走不了。
【在 p*****2 的大作中提到】
: cpu bound 多线程也没戏
p*2
67 楼
cluster
Node
【在 b***e 的大作中提到】
: 是。但是每个thread都会move forward。大象虽慢，不耽误老鼠从旁边快速通过。Node
: 里面一只大象会挡住所有的老鼠，谁也走不了。
Node
【在 b***e 的大作中提到】
: 是。但是每个thread都会move forward。大象虽慢，不耽误老鼠从旁边快速通过。Node
: 里面一只大象会挡住所有的老鼠，谁也走不了。
l*n
68 楼
node实际上是多线程
Node
【在 b***e 的大作中提到】
: 是。但是每个thread都会move forward。大象虽慢，不耽误老鼠从旁边快速通过。Node
: 里面一只大象会挡住所有的老鼠，谁也走不了。
Node
【在 b***e 的大作中提到】
: 是。但是每个thread都会move forward。大象虽慢，不耽误老鼠从旁边快速通过。Node
: 里面一只大象会挡住所有的老鼠，谁也走不了。
b*e
69 楼
But you cannot start a process (in cluster) for each request handling, right
? if one request handling is hanging there...
【在 p*****2 的大作中提到】
: cluster
:
: Node
? if one request handling is hanging there...
【在 p*****2 的大作中提到】
: cluster
:
: Node
b*e
70 楼
不知所云。
【在 l**********n 的大作中提到】
: node实际上是多线程
:
: Node
【在 l**********n 的大作中提到】
: node实际上是多线程
:
: Node
p*2
71 楼
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
72 楼
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，那样其实也不好
: 。
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
73 楼
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.
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
74 楼
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
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
75 楼
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
76 楼
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
77 楼
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。
, 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
78 楼
这个确实是。 所以我们在看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
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
79 楼
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.
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
80 楼
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
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
81 楼
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.
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
82 楼
本质上，single thread way 需把task分成简单的和复杂的，简单的立刻响应，复杂的
丢到job queue里让別的thread pool慢慢干，然后callback, 这样系统的总体响应就快
了，而且号称能
处理几百万concurrent requests。
【在 p*****2 的大作中提到】
: 这个确实是。 所以我们在看go。不过这又是另一个话题了。
:
: process
丢到job queue里让別的thread pool慢慢干，然后callback, 这样系统的总体响应就快
了，而且号称能
处理几百万concurrent requests。
【在 p*****2 的大作中提到】
: 这个确实是。 所以我们在看go。不过这又是另一个话题了。
:
: process
p*2
83 楼
cpu bound 没啥区别 你接了request 还是不能respond
【在 d****r 的大作中提到】
: 本质上，single thread way 需把task分成简单的和复杂的，简单的立刻响应，复杂的
: 丢到job queue里让別的thread pool慢慢干，然后callback, 这样系统的总体响应就快
: 了，而且号称能
: 处理几百万concurrent requests。
【在 d****r 的大作中提到】
: 本质上，single thread way 需把task分成简单的和复杂的，简单的立刻响应，复杂的
: 丢到job queue里让別的thread pool慢慢干，然后callback, 这样系统的总体响应就快
: 了，而且号称能
: 处理几百万concurrent requests。
d*r
84 楼
是的，其实活还是那么多，CPU还是那么快，没有奇迹会发生。能做的只是选择，比如
少放几个thread去处理heavy duty 的task，这样能确保小task的处理速度。用什么模
式和进来request 的种类很有关系。比如都是transcoding的request，single thread
way就没意义了。
【在 p*****2 的大作中提到】
: cpu bound 没啥区别 你接了request 还是不能respond
少放几个thread去处理heavy duty 的task，这样能确保小task的处理速度。用什么模
式和进来request 的种类很有关系。比如都是transcoding的request，single thread
way就没意义了。
【在 p*****2 的大作中提到】
: cpu bound 没啥区别 你接了request 还是不能respond
j*x
85 楼
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.
拿避孕套做热气球么。。。
行为艺术？
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
86 楼
我也有同样的问题
【在 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后台的线程，比传统
: 服务器开的线程要轻量级很多？
【在 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
87 楼
你第一个例子里面 如果有disk io 之类 操作系统一样会切换线程的
【在 d******k 的大作中提到】
: 把这个比喻再改进一下：
: 多线程：
: 假设银行只有一个业务员(1个cpu core), 多线程就是开多个窗口，比如10个，然后业
: 务员在窗口之间跑来跑去(context switch), 每个窗口服务固定的时间(cpu time
: slice),尽管有的客户的业务需要等待外部操作完成(Disk/Network IO)，比如要等运钞
: 车运来现金，业务员也得在那个窗口干等.
: 单线程Event IO:
: 只有一个窗口，客户排一个队。 遇到外部IO,比如等运钞车，就请客户出列，另外坐着
: 等，但是给一个呼叫器(call back), 运钞车来了，就call用户来继续处理。
: 可以看出单线程Event 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
88 楼
我想node是是自己定义file descriptor吧，所以可以多开一些websocket,就象微软的
３２内寸扩展一样
file descriptor 多了，其实default就８万多，连接请求要进入异常处理，看起来快些
当年我门组chef world top AI，shiri他表叔直接挑kernel
大概就这么糊弄一下的吧
３２内寸扩展一样
file descriptor 多了，其实default就８万多，连接请求要进入异常处理，看起来快些
当年我门组chef world top AI，shiri他表叔直接挑kernel
大概就这么糊弄一下的吧
b*e
89 楼
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
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
90 楼
我知道你丫当年为什么能从热气球里逃出来的么? 因为你丫有嘴剑.
【在 j********x 的大作中提到】
: cpu bound的东西你用毛的async。。。
: 拿避孕套做热气球么。。。
: 行为艺术？
:
: we
【在 j********x 的大作中提到】
: cpu bound的东西你用毛的async。。。
: 拿避孕套做热气球么。。。
: 行为艺术？
:
: we
w*z
91 楼
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.
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
92 楼
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
"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
93 楼
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.
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
94 楼
然. 但是这和NIO有乜关系?
我稍微研究了一下vert.x, 简直就是脱了裤子放屁. 基本就是用各种语言来模拟
Javascript. 整个就是另一个GWT. 这他妈的有意思吗? 京二你有啥大杀器的例子说
明vert.x有用吗?
【在 p*****2 的大作中提到】
: vertx
:
: usually
: of
: following
我稍微研究了一下vert.x, 简直就是脱了裤子放屁. 基本就是用各种语言来模拟
Javascript. 整个就是另一个GWT. 这他妈的有意思吗? 京二你有啥大杀器的例子说
明vert.x有用吗?
【在 p*****2 的大作中提到】
: vertx
:
: usually
: of
: following
p*2
95 楼
底层是nio
vertx现在还不成熟 但是简单易用 搞java的如获至宝
【在 b***e 的大作中提到】
: 然. 但是这和NIO有乜关系?
: 我稍微研究了一下vert.x, 简直就是脱了裤子放屁. 基本就是用各种语言来模拟
: Javascript. 整个就是另一个GWT. 这他妈的有意思吗? 京二你有啥大杀器的例子说
: 明vert.x有用吗?
vertx现在还不成熟 但是简单易用 搞java的如获至宝
【在 b***e 的大作中提到】
: 然. 但是这和NIO有乜关系?
: 我稍微研究了一下vert.x, 简直就是脱了裤子放屁. 基本就是用各种语言来模拟
: Javascript. 整个就是另一个GWT. 这他妈的有意思吗? 京二你有啥大杀器的例子说
: 明vert.x有用吗?
z*e
96 楼
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后台的线程，比传统
: 服务器开的线程要轻量级很多？
这个你看各个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
97 楼
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
反正都是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
98 楼
多线程就会有race condition
单线程不用担心
【在 z****e 的大作中提到】
: event pool同样可以用多线程轮询
: 反正都是pool，互相不干扰就可以了
: 几个threads同时轮询，怎么看都比单个thread在那边苦跑要有效率
: vert.x就是几个core爆几个threads
: 不像node，因为不支持thread，所以只能单个thread那边跑
: 这就是为什么node慢的主因
: node就是慢，怎么看benchmark也都还是慢
: 慢得一塌糊涂，简直慢成了笑话
: 让我想起来推销各种优惠的阿三
: 我说，你这个打完折扣也还是比我现在用的贵啊，为什么要用你的折扣？
单线程不用担心
【在 z****e 的大作中提到】
: event pool同样可以用多线程轮询
: 反正都是pool，互相不干扰就可以了
: 几个threads同时轮询，怎么看都比单个thread在那边苦跑要有效率
: vert.x就是几个core爆几个threads
: 不像node，因为不支持thread，所以只能单个thread那边跑
: 这就是为什么node慢的主因
: node就是慢，怎么看benchmark也都还是慢
: 慢得一塌糊涂，简直慢成了笑话
: 让我想起来推销各种优惠的阿三
: 我说，你这个打完折扣也还是比我现在用的贵啊，为什么要用你的折扣？
z*e
99 楼
本质上服务器就是多人一起访问的东西，当然会有race condition等并发问题
这就是服务器需要解决的问题，否则还要服务器干什么
【在 p*****2 的大作中提到】
: 多线程就会有race condition
: 单线程不用担心
这就是服务器需要解决的问题，否则还要服务器干什么
【在 p*****2 的大作中提到】
: 多线程就会有race condition
: 单线程不用担心
p*2
100 楼
可以在db层面解决
【在 z****e 的大作中提到】
: 本质上服务器就是多人一起访问的东西，当然会有race condition等并发问题
: 这就是服务器需要解决的问题，否则还要服务器干什么
【在 z****e 的大作中提到】
: 本质上服务器就是多人一起访问的东西，当然会有race condition等并发问题
: 这就是服务器需要解决的问题，否则还要服务器干什么
z*e
101 楼
db - persistence/disk
app - service/memory
互不干扰
【在 p*****2 的大作中提到】
: 可以在db层面解决
app - service/memory
互不干扰
【在 p*****2 的大作中提到】
: 可以在db层面解决
p*2
102 楼
in memory db
【在 z****e 的大作中提到】
: db - persistence/disk
: app - service/memory
: 互不干扰
z*e
103 楼
不适合建模，也不可能通过db来建模
【在 p*****2 的大作中提到】
:
: in memory db
【在 p*****2 的大作中提到】
:
: in memory db
相关阅读
卫平：发狗背离了围棋的精神， (转载)AI的终极优化目标nodejs performancehci, Clojure有类似windows COM那种东西吗？java ---> Kotlin --- > Native对scala的开发工具实在无力吐槽cost a cloud来收钱了CNN里面不用max pooling但是用更大的stride step[bssd] Neural network as a programming language想做DS的人都是为了掩盖编程能力低下这个无法绕过的障碍 (转载)世界上最牛逼的 Java 程序员paper help除了goog,baidu,还有哪个自动翻译的可以用？居然葵花版成为了整个mitbbs真有料的版紧急求助高人---window附件里的 notepad被覆盖的问题[bssd]已经很现实了BBS竟然没有哲学版[bssd] 广义相对论=>神经网络几何化?求介绍一本general programming design 的书．问问有什么项目可以做