k*******r
发帖数: 90 | 1 不要扯什么半吊子的订票系统，看着一堆半瓶油在那里晃就烦的很
哥们正好认识几个Google，Facebook的招聘经理需要找这方面的人才
有这个能力保证不刷题也能给你推进去 |
j******a
发帖数: 100 | |
N*****m
发帖数: 42603 | 3 facebook要这种人干啥？不说他们自己的facebook chat，他们买的whatsapp
2011年就可以handle c1m了
https://blog.whatsapp.com/196/1-million-is-so-2011
【在 k*******r 的大作中提到】
: 不要扯什么半吊子的订票系统，看着一堆半瓶油在那里晃就烦的很
: 哥们正好认识几个Google，Facebook的招聘经理需要找这方面的人才
: 有这个能力保证不刷题也能给你推进去
|
j******a
发帖数: 100 | 4 我是装机的，我的理解是找两台机器10G或100G对接
跑iperf，我们lab有人跑过，我没仔细看过数据，我明天上班找，不行我架起来跑一次
1M/s tcp
我把系统状态结果比方kernel time，都post出来
大概可以估算出有多少余量给上层app
不知这样可行否 |
z****e
发帖数: 54598 | 5
搞运维等operation用这种人正好
【在 j******a 的大作中提到】
: 直接用硬件碾，要什么技术含量
|
k*******r
发帖数: 90 | 6 没有见识就不要瞎bb
1m个tcp连接跟1m qps是等价的吗
不懂的人就是见风就是雨，随便瞎找几个slides，看看几个kernel参数就以为
自己什么都懂了，其实连门在哪里都没有找到
Google，facebook为什么要找这样的人，不是因为他们有这些迫切的问题需要解决
这也不是他们解决问题的思路
有能力能解决这种问题的人，对系统的理解自然不在话下
干什么都是一把好手, 这才是这些公司的招人思路
【在 N*****m 的大作中提到】
: facebook要这种人干啥？不说他们自己的facebook chat，他们买的whatsapp
: 2011年就可以handle c1m了
: https://blog.whatsapp.com/196/1-million-is-so-2011
|
k*******r
发帖数: 90 | 7 承认自己是装机的我就懂了
知道普通的内核一次read或者recv的系统调用大概要多少时间吗?
【在 j******a 的大作中提到】
: 我是装机的，我的理解是找两台机器10G或100G对接
: 跑iperf，我们lab有人跑过，我没仔细看过数据，我明天上班找，不行我架起来跑一次
: 1M/s tcp
: 我把系统状态结果比方kernel time，都post出来
: 大概可以估算出有多少余量给上层app
: 不知这样可行否
|
z****e
发帖数: 54598 | 8
这个算不算？
http请求达到了1m+
费用是$8000
https://www.techempower.com/blog/2014/03/04/one-million-http-rps-without-
load-balancing-is-easy/
【在 k*******r 的大作中提到】
: 没有见识就不要瞎bb
: 1m个tcp连接跟1m qps是等价的吗
: 不懂的人就是见风就是雨，随便瞎找几个slides，看看几个kernel参数就以为
: 自己什么都懂了，其实连门在哪里都没有找到
: Google，facebook为什么要找这样的人，不是因为他们有这些迫切的问题需要解决
: 这也不是他们解决问题的思路
: 有能力能解决这种问题的人，对系统的理解自然不在话下
: 干什么都是一把好手, 这才是这些公司的招人思路
|
k*******r
发帖数: 90 | 9 算啊， 这个作者看上去脑子还比较正常
拿这个抄也可以， 抄出来且能理解我也可以当作合格
【在 z****e 的大作中提到】
:
: 这个算不算？
: http请求达到了1m+
: 费用是$8000
: https://www.techempower.com/blog/2014/03/04/one-million-http-rps-without-
: load-balancing-is-easy/
|
j******a
发帖数: 100 | 10 你以为现在进内核还走int 80
动不动就google facebook，就这追求了
【在 k*******r 的大作中提到】
: 承认自己是装机的我就懂了
: 知道普通的内核一次read或者recv的系统调用大概要多少时间吗?
|
|
|
k*******r
发帖数: 90 | 11 哟，还知道 int80
那你倒是告诉我一次 read 要多大开销， 知道数量级就行了
【在 j******a 的大作中提到】
: 你以为现在进内核还走int 80
: 动不动就google facebook，就这追求了
|
g*****y
发帖数: 7271 | 12 没人否认能解决这种问题的人是一把好手。但是这种堆机器就能解决的
事情，我觉得level不算很高的说。
我觉得卖车票这个实验level还是要高一点，毕竟强耦合的系统，堆机器的
效率比较低下。
真不知道你的优越感是哪里来的.
【在 k*******r 的大作中提到】
: 没有见识就不要瞎bb
: 1m个tcp连接跟1m qps是等价的吗
: 不懂的人就是见风就是雨，随便瞎找几个slides，看看几个kernel参数就以为
: 自己什么都懂了，其实连门在哪里都没有找到
: Google，facebook为什么要找这样的人，不是因为他们有这些迫切的问题需要解决
: 这也不是他们解决问题的思路
: 有能力能解决这种问题的人，对系统的理解自然不在话下
: 干什么都是一把好手, 这才是这些公司的招人思路
|
j******a
发帖数: 100 | 13 进kernel一个far call有什么开销，在 cache里直接有的话，流水线都不会堵
【在 k*******r 的大作中提到】
: 哟，还知道 int80
: 那你倒是告诉我一次 read 要多大开销， 知道数量级就行了
|
k*******r
发帖数: 90 | 14 因为这个版上二把刀太多
也不能怪他们
计算机这门科学好多半道出家的以为学点皮毛就以为可以关公耍大刀
殊不知很多时候能知其所以然都做不到
的确，如果计算机的频率一直往上跑， 1M qps并不是什么大不了的问题
但是关键是现在频率没法加了，多核的情况下不是简单的堆机器就能搞定 1M qps
teacherwei还说什么一个核处理网络，一个核处理订票
一看就是完全不懂其中的利害的
一个系统调用就能超过1微秒，还一个核搞定
【在 g*****y 的大作中提到】
: 没人否认能解决这种问题的人是一把好手。但是这种堆机器就能解决的
: 事情，我觉得level不算很高的说。
: 我觉得卖车票这个实验level还是要高一点，毕竟强耦合的系统，堆机器的
: 效率比较低下。
: 真不知道你的优越感是哪里来的.
|
j******a
发帖数: 100 | 15 我是老实人，不喜欢人说话怪声怪气的
你说的read/write的开销，其实depends on应用的复杂程度，和写程序的人对需求和系
统的了解
最后开销差很远
其实我的想法是，天才总是少的，大多数人只能handle一般的code，而这个世界上编程
的需求做不玩，所以没必要逼迫大多数人痛苦的拔高自己去做所谓的优化，转而把精力
放在需求业务的理解上，靠堆机器，可能生产力更高 |
g*****y
发帖数: 7271 | 16 我说的堆机器是多个机器，不是多核。
一个机器达到100k qps，10个机器不就1M了么？
高度并行啊！太容易scale了。还是我哪里理解错了？
【在 k*******r 的大作中提到】
: 因为这个版上二把刀太多
: 也不能怪他们
: 计算机这门科学好多半道出家的以为学点皮毛就以为可以关公耍大刀
: 殊不知很多时候能知其所以然都做不到
: 的确，如果计算机的频率一直往上跑， 1M qps并不是什么大不了的问题
: 但是关键是现在频率没法加了，多核的情况下不是简单的堆机器就能搞定 1M qps
: teacherwei还说什么一个核处理网络，一个核处理订票
: 一看就是完全不懂其中的利害的
: 一个系统调用就能超过1微秒，还一个核搞定
|
j******a
发帖数: 100 | |
f******2
发帖数: 2455 | 18 你是专家，给个talk吧。老魏好歹给了个iot的平台作品。
再说了，在google，fb做你说的这个活的人也不是什么高大上的位置吧？弄不好还没有
老姜的店小儿每天有奋斗目标。
这个版上不怕二把刀，jeff dean来这儿干啥?
这个版怕的是不亮credential就人挡杀人，佛挡杀佛的牛人，到头来我等小白都没法正
常讨论问题。您要是牛，就亮个项目甚至rfc啥的，把老魏等一干"烂人"都轰杀。
【在 k*******r 的大作中提到】
: 因为这个版上二把刀太多
: 也不能怪他们
: 计算机这门科学好多半道出家的以为学点皮毛就以为可以关公耍大刀
: 殊不知很多时候能知其所以然都做不到
: 的确，如果计算机的频率一直往上跑， 1M qps并不是什么大不了的问题
: 但是关键是现在频率没法加了，多核的情况下不是简单的堆机器就能搞定 1M qps
: teacherwei还说什么一个核处理网络，一个核处理订票
: 一看就是完全不懂其中的利害的
: 一个系统调用就能超过1微秒，还一个核搞定
|
n**********5
发帖数: 1707 | 19 你也很清楚有这个能力的人根本就不愁吃穿。你怎么知道这些人就哭着喊着一定要去字
母表拿2000+股RSU呢。你不觉得可能是一种冒犯吗。
路人甲我给一个建议。多吃水果、生的蔬菜。钱是赚不完的。硅谷这里的人动脑太多。
我算过，一天要吃9公斤苹果才能勉强补充正常思维活动所需的其中一种营养。我动脑
太多要吃27公斤才行。吃够了发现这个世界原来这么美好。
我相信Google、FB的员工工作充满热忱不眠不休地思考。如果一天没吃上50公斤苹果，
1年365天地亏空。做peer review之前会不会正面一点呢。
【在 k*******r 的大作中提到】
: 不要扯什么半吊子的订票系统，看着一堆半瓶油在那里晃就烦的很
: 哥们正好认识几个Google，Facebook的招聘经理需要找这方面的人才
: 有这个能力保证不刷题也能给你推进去
|
g****u
发帖数: 252 | 20 他的协议每个请求/回复是16 byte。以我三角猫的网络水平看来，
一次放80个请求到一个包里发出去，系统调用的overhead可能
就没关系了。如果您有更好的办法，请给我们指点一下该
怎么弄。
【在 k*******r 的大作中提到】
: 因为这个版上二把刀太多
: 也不能怪他们
: 计算机这门科学好多半道出家的以为学点皮毛就以为可以关公耍大刀
: 殊不知很多时候能知其所以然都做不到
: 的确，如果计算机的频率一直往上跑， 1M qps并不是什么大不了的问题
: 但是关键是现在频率没法加了，多核的情况下不是简单的堆机器就能搞定 1M qps
: teacherwei还说什么一个核处理网络，一个核处理订票
: 一看就是完全不懂其中的利害的
: 一个系统调用就能超过1微秒，还一个核搞定
|
|
|
g****u
发帖数: 252 | 21 你说的这种营养是什么？我这两天脑子不够用了，也想补一补。
【在 n**********5 的大作中提到】
: 你也很清楚有这个能力的人根本就不愁吃穿。你怎么知道这些人就哭着喊着一定要去字
: 母表拿2000+股RSU呢。你不觉得可能是一种冒犯吗。
: 路人甲我给一个建议。多吃水果、生的蔬菜。钱是赚不完的。硅谷这里的人动脑太多。
: 我算过，一天要吃9公斤苹果才能勉强补充正常思维活动所需的其中一种营养。我动脑
: 太多要吃27公斤才行。吃够了发现这个世界原来这么美好。
: 我相信Google、FB的员工工作充满热忱不眠不休地思考。如果一天没吃上50公斤苹果，
: 1年365天地亏空。做peer review之前会不会正面一点呢。
|
N*****m
发帖数: 42603 | 22 bottleneck就在IO，能同时连1m连接指的就是能multiplexing这1m连接的请求
你要说每个请求做hadoop运算才行，这不是扯淡吗
c10k这种问题是2000年代的问题，现在commodity的机器解决c1m根本不需要特殊处理
还好意思瞎扯淡
【在 k*******r 的大作中提到】
: 没有见识就不要瞎bb
: 1m个tcp连接跟1m qps是等价的吗
: 不懂的人就是见风就是雨，随便瞎找几个slides，看看几个kernel参数就以为
: 自己什么都懂了，其实连门在哪里都没有找到
: Google，facebook为什么要找这样的人，不是因为他们有这些迫切的问题需要解决
: 这也不是他们解决问题的思路
: 有能力能解决这种问题的人，对系统的理解自然不在话下
: 干什么都是一把好手, 这才是这些公司的招人思路
|
j******a
发帖数: 100 | 23 系统调用很好测试
int main()
{
int fd;
int zero;
ssize_t read_bytes;
double t1,t2;
t1 = getTime();
fd = open("/dev/zero",O_RDONLY);
for (size_t i=0; i<100000000LL; i++) {
read_bytes= read(fd,&zero,sizeof(zero));
}
t2 = getTime();
printf("Total time = %fn", t2 - t1);
close(fd);
return 0;
}
我的台式机跑出来是7.690460
你数量级都没有对
当然我的机器可能比较好，是台E5 v3，但也是我这边最差就这台了
【在 k*******r 的大作中提到】
: 因为这个版上二把刀太多
: 也不能怪他们
: 计算机这门科学好多半道出家的以为学点皮毛就以为可以关公耍大刀
: 殊不知很多时候能知其所以然都做不到
: 的确，如果计算机的频率一直往上跑， 1M qps并不是什么大不了的问题
: 但是关键是现在频率没法加了，多核的情况下不是简单的堆机器就能搞定 1M qps
: teacherwei还说什么一个核处理网络，一个核处理订票
: 一看就是完全不懂其中的利害的
: 一个系统调用就能超过1微秒，还一个核搞定
|
n******7
发帖数: 12463 | 24 你是pugetsystems的？
【在 j******a 的大作中提到】
: 系统调用很好测试
: int main()
: {
: int fd;
: int zero;
: ssize_t read_bytes;
: double t1,t2;
: t1 = getTime();
: fd = open("/dev/zero",O_RDONLY);
: for (size_t i=0; i<100000000LL; i++) {
|
n****j
发帖数: 1708 | 25 好像 /dev/null 还能再快一点点，不知道我记错没有
【在 j******a 的大作中提到】
: 系统调用很好测试
: int main()
: {
: int fd;
: int zero;
: ssize_t read_bytes;
: double t1,t2;
: t1 = getTime();
: fd = open("/dev/zero",O_RDONLY);
: for (size_t i=0; i<100000000LL; i++) {
|
f******2
发帖数: 2455 | 26 是的。
【在 n****j 的大作中提到】
: 好像 /dev/null 还能再快一点点，不知道我记错没有
:
:
|
j******a
发帖数: 100 | 27 我是supermicro的，很多公司找system integration公司买机器不如直接找我们买，真
是有问题很多时候他们也就是邮件转发
【在 n******7 的大作中提到】
: 你是pugetsystems的？
|
d******e
发帖数: 2265 | 28 不知道写这个有什么要求。
要写点乒乓也不算特别难吧。
当然什么都有上pool的有些困难。
【在 k*******r 的大作中提到】
: 不要扯什么半吊子的订票系统，看着一堆半瓶油在那里晃就烦的很
: 哥们正好认识几个Google，Facebook的招聘经理需要找这方面的人才
: 有这个能力保证不刷题也能给你推进去
|
d******e
发帖数: 2265 | 29 不知道写这个有什么要求。
要写点乒乓也不算特别难吧。
当然什么都有上pool的有些困难。
【在 k*******r 的大作中提到】
: 不要扯什么半吊子的订票系统，看着一堆半瓶油在那里晃就烦的很
: 哥们正好认识几个Google，Facebook的招聘经理需要找这方面的人才
: 有这个能力保证不刷题也能给你推进去
|
b*******s
发帖数: 5216 | 30 bookmarked
【在 j******a 的大作中提到】
: 我是supermicro的，很多公司找system integration公司买机器不如直接找我们买，真
: 是有问题很多时候他们也就是邮件转发
|
|
|
j******a
发帖数: 100 | 31 1M 个 TCP 开关没有机器做得到,协议就是这样了
长连接 1M 个 tcp req/response，轻轻松松
兰州信口开河，挺会忽悠，1ms+ 系统调用时间随口就来
其实随手ping一台就知道他在扯淡
64 bytes from 172.31.32.255: icmp_seq=1 ttl=64 time=0.016 ms
前面的哥们说很对
/dev/null read是空的，/dev/zero多了地址check，中途要reshed一次，所以会慢，而
且结果不稳定
【在 d******e 的大作中提到】
: 不知道写这个有什么要求。
: 要写点乒乓也不算特别难吧。
: 当然什么都有上pool的有些困难。
|
g****u
发帖数: 252 | 32 你们玩硬件的太爽了。
【在 j******a 的大作中提到】
: 1M 个 TCP 开关没有机器做得到,协议就是这样了
: 长连接 1M 个 tcp req/response，轻轻松松
: 兰州信口开河，挺会忽悠，1ms+ 系统调用时间随口就来
: 其实随手ping一台就知道他在扯淡
: 64 bytes from 172.31.32.255: icmp_seq=1 ttl=64 time=0.016 ms
: 前面的哥们说很对
: /dev/null read是空的，/dev/zero多了地址check，中途要reshed一次，所以会慢，而
: 且结果不稳定
|
t**********1
发帖数: 550 | 33 给你们看看这个吧mTCP
claim上million connections/second
http://www.cs.princeton.edu/~sihm/papers/mtcp-nsdi14.pdf
https://github.com/eunyoung14/mtcp
【在 j******a 的大作中提到】
: 1M 个 TCP 开关没有机器做得到,协议就是这样了
: 长连接 1M 个 tcp req/response，轻轻松松
: 兰州信口开河，挺会忽悠，1ms+ 系统调用时间随口就来
: 其实随手ping一台就知道他在扯淡
: 64 bytes from 172.31.32.255: icmp_seq=1 ttl=64 time=0.016 ms
: 前面的哥们说很对
: /dev/null read是空的，/dev/zero多了地址check，中途要reshed一次，所以会慢，而
: 且结果不稳定
|
g****u
发帖数: 252 | 34 软件做这个都是浮云。我已经被supermicro那哥们震撼了。
【在 t**********1 的大作中提到】
: 给你们看看这个吧mTCP
: claim上million connections/second
: http://www.cs.princeton.edu/~sihm/papers/mtcp-nsdi14.pdf
: https://github.com/eunyoung14/mtcp
|
t**********1
发帖数: 550 | 35 这个还真得软件做。不信你问那个哥们？
硬件不行的。这个楼主张口闭口kernel，我连讨论的兴趣都没有了。
【在 g****u 的大作中提到】
: 软件做这个都是浮云。我已经被supermicro那哥们震撼了。
|
d******e
发帖数: 2265 | 36 https://www.techempower.com/benchmarks/#section=data-r11&hw=peak&test=
plaintext
这里做到6M 个hello word就是买个好机器装个web server搞定。
akka actor可以跑到50M/s.。28核的192G内存而已 ，要是xeon24核估计跑的分还要高。
【在 j******a 的大作中提到】
: 1M 个 TCP 开关没有机器做得到,协议就是这样了
: 长连接 1M 个 tcp req/response，轻轻松松
: 兰州信口开河，挺会忽悠，1ms+ 系统调用时间随口就来
: 其实随手ping一台就知道他在扯淡
: 64 bytes from 172.31.32.255: icmp_seq=1 ttl=64 time=0.016 ms
: 前面的哥们说很对
: /dev/null read是空的，/dev/zero多了地址check，中途要reshed一次，所以会慢，而
: 且结果不稳定
|
j******a
发帖数: 100 | 37 我看了你的link，他是长连接的
GET /json HTTP/1.1
Host: server
User-Agent: Mozilla/5.0 (X11; Linux x86_64) Gecko/20130501 Firefox/30.0
AppleWebKit/600.00 Chrome/30.0.0000.0 Trident/10.0 Safari/600.00
Cookie: uid=12345678901234567890; __utma=1.1234567890.1234567890.1234567890.
1234567890.12; wd=2560x1600
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive |
n*******7
发帖数: 181 | 38 几年前测过Lenovo T43, L1 cache - <4 ns, L2 & L3 forgotten, external memory
90 ns.
【在 k*******r 的大作中提到】
: 哟，还知道 int80
: 那你倒是告诉我一次 read 要多大开销， 知道数量级就行了
|
c*****5
发帖数: 100 | 39 我能很轻松的吗出一个5M/s的web handler，就用Java的轮子。
你能推荐吗？ |
w***x
发帖数: 105 | 40 关于syscall的消耗，我以前曾经测试过，写一个noop的ioctl，然后从user进入kernel
再返回，没记错的话，Linux下时间大概是小于2 microseconds。 |
|
|
x****k
发帖数: 2932 | 41 这个回答靠谱，
重复调用同一ioctl，然后用总时间除以循环次数，对比只调用一次ioctl的时间，后者
会更耗时一些，sandy bridge的xeon上花2～3us算常见的。
kernel
【在 w***x 的大作中提到】
: 关于syscall的消耗，我以前曾经测试过，写一个noop的ioctl，然后从user进入kernel
: 再返回，没记错的话，Linux下时间大概是小于2 microseconds。
|
b****r
发帖数: 45 | |
a9
发帖数: 21638 | 43 那load balance是怎么做到的？
【在 j******a 的大作中提到】
: 1M 个 TCP 开关没有机器做得到,协议就是这样了
: 长连接 1M 个 tcp req/response，轻轻松松
: 兰州信口开河，挺会忽悠，1ms+ 系统调用时间随口就来
: 其实随手ping一台就知道他在扯淡
: 64 bytes from 172.31.32.255: icmp_seq=1 ttl=64 time=0.016 ms
: 前面的哥们说很对
: /dev/null read是空的，/dev/zero多了地址check，中途要reshed一次，所以会慢，而
: 且结果不稳定
|
