S*A
发帖数: 7142 | 1
epoll
是一定更差啦。关键是差的比较远，我有点吃惊而以。
IO
goroutine 太多 go 自己调度不过来，这个的确会是个问题。
go
go 1.9 的 epoll不知道啊，新的 goroutine 可能已经用 epoll了，
但是还是不如直接控制 epoll + callback。 goroutine 太多我意识到
是个无解的问题。
go 可以直接 system call 调用的。可以用全部 go 来做。
如果我 C 写底层我就直接 C 全部橹了，只考虑 Linux epoll 其实不复杂，
我写过。复杂的是想上面包各种各样东西兼容 kqueue 这些。 |
|
S*A
发帖数: 7142 | 2
netpoll
现在试的就是这个。感受就是，你基本上要很熟悉 C 的那个 epoll
是如何写的，然后再等价转换到 go 去。如果写不出 C 的 epoll
完整玩法，也没法理解这个 go 的 epoll 是如何玩的。基本上类似
隔着 go 写 C 代码。那个 netpoll 只是 epoll 部分的 API。
不少复杂的地方在上层什么时候用这个 read，有没有把 socket
读干净这些。（读干净才会重新 arm edge trigger）。
那个 netpoll 基本上就是个 epoll 的系统调用的接口而以，
然后包了其他古古怪怪的 API 名字，没有太多东西。
是的，所以觉得比较坑上来抱怨一下。Go 其他设计还是感觉大体合理的。 |
|
|
|
|
S*A
发帖数: 7142 | 6 epoll 还好吧，很多游戏公司包括腾讯都用 epoll。
有bug 也早 fix 啦。
BTW, ngix 等一系列 http server 都是用 epoll 的。
这个应该是非常成熟的技术了。 |
|
S*A
发帖数: 7142 | 7 我是不了解 openonload, 没有玩过10G 的网卡。
openonload 没有提供更加底层的 API？
那就是说还有可以更加优化的地方。
如果是包接受的话，用 socket read 需要至少
memcpy 一次。网卡的数据包进来的时候不知道
是哪个socket的，所以要先收下来，然后 copy
到现成的用户 buffer。 这个不用新的 API 是没法
优化的。openonload 有更加优化的接受办法吗？
还有 openonload 应该兼容 epoll 吧？
连接数量少，epoll 不是最优，但是也差不到那里
去吧。关键是 epoll 时间不会随着和连接个数线性
增加，连接数目多了必然要用这种 API 的。
速。 |
|
S*A
发帖数: 7142 | 8 epoll 还好吧，很多游戏公司包括腾讯都用 epoll。
有bug 也早 fix 啦。
BTW, ngix 等一系列 http server 都是用 epoll 的。
这个应该是非常成熟的技术了。 |
|
S*A
发帖数: 7142 | 9 我是不了解 openonload, 没有玩过10G 的网卡。
openonload 没有提供更加底层的 API？
那就是说还有可以更加优化的地方。
如果是包接受的话，用 socket read 需要至少
memcpy 一次。网卡的数据包进来的时候不知道
是哪个socket的，所以要先收下来，然后 copy
到现成的用户 buffer。 这个不用新的 API 是没法
优化的。openonload 有更加优化的接受办法吗？
还有 openonload 应该兼容 epoll 吧？
连接数量少，epoll 不是最优，但是也差不到那里
去吧。关键是 epoll 时间不会随着和连接个数线性
增加，连接数目多了必然要用这种 API 的。
速。 |
|
|
S*A
发帖数: 7142 | 11 哦，如果 epoll 不是 go 做的话，如何交接收到的数据是个问题。
需要按照 go 的规则把收下的数据包打包成 go 的 object。
这个如果 epoll 用 go 来写也需要有同样的过程。
所以我现在看看纯 go 来写 epoll call back如何。
上层用 goroutine 来写是没有问题的。但是同样要限制数目。
goroutine 太多其实没有帮助，只能帮倒忙。因为你的 CPU
个数是有限的，一次能真正同时做的东西有限。多出来的
goroutine 之间的调度是浪费。相比之下，call back 的代
价要小很多，没有切换 context 的问题。没有 goroutine
霸占的 context 的内存问题。 |
|
r*****n
发帖数: 4844 | 12 前言
你是否觉得自己从学校毕业的时候只做过小玩具一样的程序？走入职场后哪怕没有什么
经验也可以把以下这些课外练习走一遍（朋友的抱怨：学校课程总是从理论出发，作业
项目都看不出有什么实际作用，不如从工作中的需求出发）
建议：
不要乱买书，不要乱追新技术新名词，基础的东西经过很长时间积累而且还会在未来至
少10年通用。
回顾一下历史，看看历史上时间线上技术的发展，你才能明白明天会是什么样。
一定要动手，例子不管多么简单，建议至少自己手敲一遍看看是否理解了里头的细枝末
节。
一定要学会思考，思考为什么要这样，而不是那样。还要举一反三地思考。
注：你也许会很奇怪为什么下面的东西很偏Unix/Linux，这是因为我觉得Windows下的
编程可能会在未来很没有前途，原因如下：
现在的用户界面几乎被两个东西主宰了，1）Web，2）移动设备iOS或Android。Windows
的图形界面不吃香了。
越来越多的企业在用成本低性能高的Linux和各种开源技术来构架其系统，Windows的成
本太高了。
微软的东西变得太快了，很不持久，他们完全是在玩弄程序员。详情参见《Windows编
程革命史》
所以... 阅读全帖 |
|
|
|
|
|
l**********g
发帖数: 426 | 17 I've just finished the interview. It is my first time that an
interviewer stopped talk before it should be (10 minutes).
Unfortunately, at this time I do not feel apple has a strong match
with my needs. Thank you and the interviewer for taking the time and
exploring this opportunity. I'll be sure to keep apple on mind for
future opportunities, if the interviewers can give more respect and
patience to job seekers.
估计是华人ABC吧，本科在这边读的。
谁能告诉我epoll和poll的区别？至少我还知道一点epoll支持更多的descriptors， > 1024。
第10分钟时... 阅读全帖 |
|
l**********g
发帖数: 426 | 18 I've just finished the interview. It is my first time that an
interviewer stopped talk before it should be (10 minutes).
Unfortunately, at this time I do not feel apple has a strong match
with my needs. Thank you and the interviewer for taking the time and
exploring this opportunity. I'll be sure to keep apple on mind for
future opportunities, if the interviewers can give more respect and
patience to job seekers.
估计是华人ABC吧，本科在这边读的。
谁能告诉我epoll和poll的区别？至少我还知道一点epoll支持更多的descriptors> 1024。
第10分钟时打断... 阅读全帖 |
|
n******r
发帖数: 869 | 19 贡献好文：
http://coolshell.cn/articles/4990.html
月光博客6月12日发表了《写给新手程序员的一封信》，翻译自《An open letter to
those who want to start programming》，我的朋友（他在本站的id是Mailper）告诉
我，他希望在酷壳上看到一篇更具操作性的文章。因为他也是喜欢编程和技术的家伙，
于是，我让他把他的一些学习Python和Web编程的一些点滴总结一下。于是他给我发来
了一些他的心得和经历，我在把他的心得做了不多的增改，并根据我的经历增加了“进
阶”一节。这是一篇由新手和我这个老家伙根据我们的经历完成的文章。
我的这个朋友把这篇文章取名叫Build Your Programming Technical Skills，我实在
不知道用中文怎么翻译，但我在写的过程中，我觉得这很像一个打网游做任务升级的一
个过程，所以取名叫“技术练级攻略”，题目有点大，呵呵，这个标题纯粹是为了好玩
。这里仅仅是在分享Mailper和我个人的学习经历。（注：省去了我作为一个初学者曾
经学习过的一些技术(今天明显... 阅读全帖 |
|
c****3
发帖数: 10787 | 20 高吞吐必然是低延迟，高延迟，必然是低吞吐。
因为大量TCP连接的问题是应用程序如何以最短的时间，知道那个Socket里面有新数据
（请求），快速响应请求，所以必然是高吞吐，低延迟。做不到这点，必然是高延迟，
低吞吐。这涉及如何用多线程，如何选择select，poll，epoll或者其他socket API的
策略。我记得微软的io complete port（等同linux里epoll的边沿触发），推荐的使用
线程数是CPU核心数+2。
也有人用非常规做法，达到高性能。比如减少poll里面的数组长度，把大量socket分成
很多小的组，快速采样。应用程序可以选择的策略很多，好坏性能可以差非常多。 |
|
|
S*A
发帖数: 7142 | 22 你现成的运行库使用 OpenOnLoad 或者 DKDP 吗？
还是直接用 Linux epoll 那样裸写？
epoll 裸写大概 200 行左右，这个我写过。 |
|
T********i
发帖数: 2416 | 23 有底层API。但是限制挺多的。zero copy其实不是那么重要。
openonload能基本消除interrupt，这个提升更大。
Sandy bridge是PCI E直接读到LLC的。就这一点性能就提高好几倍了。zcp很不重要了。
openonload epoll现在优化的很好。前两年还不行。
C10M应用，要用epoll。 |
|
|
S*A
发帖数: 7142 | 25 你现成的运行库使用 OpenOnLoad 或者 DKDP 吗？
还是直接用 Linux epoll 那样裸写？
epoll 裸写大概 200 行左右，这个我写过。 |
|
T********i
发帖数: 2416 | 26 有底层API。但是限制挺多的。zero copy其实不是那么重要。
openonload能基本消除interrupt，这个提升更大。
Sandy bridge是PCI E直接读到LLC的。就这一点性能就提高好几倍了。zcp很不重要了。
openonload epoll现在优化的很好。前两年还不行。
C10M应用，要用epoll。 |
|
S*A
发帖数: 7142 | 27 这个练习1 已经发现了，C10M 没有强壮的内存支持是
没戏的。单单是 kernel 部分就已经消耗很多内存了。
所以我们把目标调整一下，1M per 4G RAM。
这样 64G 内存就有可能实现 10M。
练习2 就是看看，我们如果保留 1M/4G 的空TCP
连接，可不可以。完全不往 TCP 里面发东西。就是
建立连接而已。这样也不存在 epoll 问题。
和实验1一样，我会发些拍脑瓜想出来的简单代码。
你直接用这个代码冲刺 1M/4G 会碰到些实际问题。
有兴趣的同学跟着做一下实验，看看有没有办法解
决这些问题。
BTW，我是实验出了 1M/4G (服务器方），所以是
有可能的。建立1M 连接还花了不少时间。
服务器方代码。端口是80， 大家可以自己改。
include
#include
#include
#include
#include
#include
#include
#include 阅读全帖 |
|
S*A
发帖数: 7142 | 28 这个练习1 已经发现了，C10M 没有强壮的内存支持是
没戏的。单单是 kernel 部分就已经消耗很多内存了。
所以我们把目标调整一下，1M per 4G RAM。
这样 64G 内存就有可能实现 10M。
练习2 就是看看，我们如果保留 1M/4G 的空TCP
连接，可不可以。完全不往 TCP 里面发东西。就是
建立连接而已。这样也不存在 epoll 问题。
和实验1一样，我会发些拍脑瓜想出来的简单代码。
你直接用这个代码冲刺 1M/4G 会碰到些实际问题。
有兴趣的同学跟着做一下实验，看看有没有办法解
决这些问题。
BTW，我是实验出了 1M/4G (服务器方），所以是
有可能的。建立1M 连接还花了不少时间。
服务器方代码。端口是80， 大家可以自己改。
include
#include
#include
#include
#include
#include
#include
#include 阅读全帖 |
|
T********i
发帖数: 2416 | 29 TCP的设计确实够烂。几十年来一直没停的patch。
现实中人不可能不犯错误，大系统的可靠性足够让任何相关人士一直提心吊胆。
OpenOnLoad其实也是大路货。比如错误，就是connect不尊重SO_SNDTIMEO。表现就是
non-blocking connect不能timeout报错。最新版本也没解决。这些，没做过的不可能
知道。
其实，我一直都不担心C10M maintain connection的问题。我关心的是，系统
bandwidth能做到什么程度。这些，基本上和socket API无关了。但是和你的threading
model + I/O model有关。
SSA曾经问过我连接少的话，epoll即使不是最优的，性能也不会差对不对？其实，这要
结合应用去理解。我要求latency尽可能低。epoll两个选项，一个是spin，这样会占用
一个core，一个是kernel wait，这样会有context switch。我系统只有16个core呀。
这样就需要有创造性了。其实，技术离不开commen sense。
真正做C10M，其中的同步技巧，很多是conter int... 阅读全帖 |
|
g*****g
发帖数: 34805 | 30 我给的例子，用的ning async httpclient, 底下是Netty，用的是NIO, 在Linux上就是
epoll。你用啥语言到最底层不还是epoll。 |
|
d******e
发帖数: 2265 | 31 epoll就是能海量开fd.这个和异步模型没有关系。
你就是不用epoll，最多少点好来。1000个并发。这个问题也够了。windows iocp也不
错。
但是，上层模型，要么你用connection pool，spawn thread被后台block住等结果，等
结果来了，oncompleted活着set future. 主线要么await。要么直接运行下去。
要么你替换当前stack,象python和go一样。
要么你想node. 不停的event loop.
那好，我说java是第一种，你要是不同意。你告诉我那种实现模型。我去学习去。 |
|
g*****g
发帖数: 34805 | 32 epoll跟异步模型没关系？别跟我老瞎扯。
epoll is a Linux kernel system call, a scalable I/O event notification
mechanism。这就是异步IO
IO的速度本来就是下层，而不是上层决定的。connection pool并不会比node的event-
loop慢，你不服大可做benchmark。那个网站benchmark比较，undertow就是基于netty
的，秒杀了node. 另外,Netty当然不是spawn thread等结果，那个叫做同步IO，不叫异
步IO。 |
|
|
f****y
发帖数: 243 | 34 tornado和node肯定是了。。c++那个看起来就只是开了个线程的样子？
另外epoll真的就是async的终极解法么。。
：这些异步其实就是在epoll上实现的吧
： |
|
S*A
发帖数: 7142 | 35 这个我们的确有这个需求，至少要 demo 能够处理这样的流量。
如果是我一个人写和维护就直接 C + epoll 橹了，而且保证是最优化的。
这个 go 的头不是我开的，但是也不是完全没有解就是了。
其实说白了就是放弃 goroutine N：1 tcp 的对应关系。
然后把 go 当 C 写，自己处理 server pool，epoll 这些。
网上有人讨论这个基本上是这个结果。
java 就算了吧。我这个不是典型的 web 后段应用，
有其他考虑，java 基本上不考虑了。
B |
|
S*A
发帖数: 7142 | 36 buffer 足够，内存不是问题。
就算你有足够buffer，网卡不是一次能传完的，
还是回到调度问题。如果你有很多 goroutine，
如何在几万个goroutine 里面调度不是一个容易的
事情。
go 的编程模式是让 goroutine 写成连续的一个
类似进程的东西。这个方式看来是没法上大规模的。
你看看 go 为什么拒绝提供 net 上的 epoll API。
就是觉得 epoll 这种 event + callback
驱动 IO 的方式和 go 的精髓不合。
我觉得是个 goroutine 调度问题，你一定要说是
channel 问题我也没法。你去仔细看看我提供的
那个连接，连接里有提到这个问题和解决的。非常印证
我的直观理解。 |
|
s********k
发帖数: 6180 | 37 你自己配置这个肯定更好，因为IO交互性应用，goroutine的schedule不一定会比epoll
这个更好，个人感觉你的问题不是goroutine 1：1 socket 不适合做大并发， 而是IO
密集型go不如手动好，就像开车自动车舒服省心，但是追求极致性能就需要手动档，go
的目的就是为了给大多数手动觉得麻烦人提供便利
话说你的go+epoll，现在最新的go1.9是不是也在做了？你是打算用C写底层，然后
signal去go吗？ |
|
l****e
发帖数: 609 | 38 (一)历史篇
（1）总统辩论
1980年里根和卡特的十月28日辩论之前，卡特的Favorable 和支持率都很高。当时10月
28日辩论的收看人数是个记录(80+million) ，辩论之后，获得辩论胜利的里根扭转局
势，他的Favorable 和支持率急速上升，两个星期后当选总统。
今年的辩论的收视率也是个记录（84+millions），还有人看网络直播的。Hillary获得
了辩论的胜利，本来她的Favorable 和支持率本来就比trump的要好，辩论之后她的他
的Favorable 和支持率扶摇直上。
虽然第二场副总统辩论是Pence赢了，但是9月26日的第一次辩论是这四场辩论中最重要
的一场，而且观看的人那么多，由此推论Hillary必会当选。
（2）Favorable 和 Unfavorable rating
http://www.gallup.com/poll/193376/trump-leads-clinton-historically-bad-image-ratings.aspx
Favorable 和 Unfavorable是一个重要指标。根据历史数据，从1956年... 阅读全帖 |
|
|
|
|
|
|
|
j******s
发帖数: 42 | 45 一开始也有同感，觉得共和党真够搞笑，都有奥巴马8年的前车之鉴了，怎么又出了个
黑人,怎么可能有人选他。
但是看了他的采访和观点后，发觉此人颇有智慧，Trump和Hillary和他不是一个级别的。
现在最新的几乎所有民调，他都已经领先了Trump：
Carson's 29 percent is followed by Donald Trump at 23 percent, Marco Rubio
at 11 percent, Ted Cruz at 10 percent and Jeb Bush at 8 percent.
同时赶超了Hillary
http://www.realclearpolitics.com/epolls/2016/president/us/gener |
|
V*****2
发帖数: 7930 | 46 看看这个结果，如果不是在民主党内部，公众认为SANDERS更加能赢共和党。
http://www.realclearpolitics.com/epolls/latest_polls/dem_pres_p
General Election: Trump vs. Clinton
CNN/ORC
Clinton52
Trump44
Clinton +8
General Election: Trump vs. Sanders
CNN/ORC
Sanders55
Trump43
Sanders +12
General Election: Cruz vs. Clinton
CNN/ORC
Cruz49
Clinton48
Cruz +1
General Election: Cruz vs. Sanders
CNN/ORC
Sanders57
Cruz40
Sanders +17
More Latest Polls |
|
|
|
l****e
发帖数: 609 | 49 (一)历史篇
（1）总统辩论
1980年里根和卡特的十月28日辩论之前，卡特的Favorable 和支持率都很高。当时10月
28日辩论的收看人数是个记录(80+million) ，辩论之后，获得辩论胜利的里根扭转局
势，他的Favorable 和支持率急速上升，两个星期后当选总统。
今年的辩论的收视率也是个记录（84+millions），还有人看网络直播的。Hillary获得
了辩论的胜利，本来她的Favorable 和支持率本来就比trump的要好，辩论之后她的他
的Favorable 和支持率扶摇直上。
虽然第二场副总统辩论是Pence赢了，但是9月26日的第一次辩论是这四场辩论中最重要
的一场，而且观看的人那么多，由此推论Hillary必会当选。
（2）Favorable 和 Unfavorable rating
http://www.gallup.com/poll/193376/trump-leads-clinton-historically-bad-image-ratings.aspx
Favorable 和 Unfavorable是一个重要指标。根据历史数据，从1956年... 阅读全帖 |
|
|
