l******o
发帖数: 144 | 1 还是只是应用层的时间？这个我觉得差别很大啊。网卡不够好说不定在网卡里的延迟都
要过1us了吧。
十大观光党路过，不太了解事情的来龙去脉，有什么总结贴么？ |
t****n
发帖数: 263 | 2 那是魏实现的问题。测试的时候只管能不能handle 1M QPS。
【在 l******o 的大作中提到】
: 还是只是应用层的时间？这个我觉得差别很大啊。网卡不够好说不定在网卡里的延迟都
: 要过1us了吧。
: 十大观光党路过，不太了解事情的来龙去脉，有什么总结贴么？
|
l******o
发帖数: 144 | 3 那我估计很悬。
那是魏实现的问题。测试的时候只管能不能handle 1M QPS。
【在 t****n 的大作中提到】
: 那是魏实现的问题。测试的时候只管能不能handle 1M QPS。
|
b*******g
发帖数: 603 | 4 比如ping一个，有个网络延迟，1us处理的意思就是结果还是跟ping一样。如果有显著
延迟那显然不行。
当然我们说的是宏观上，不是每个包都确保1us.
【在 l******o 的大作中提到】
: 还是只是应用层的时间？这个我觉得差别很大啊。网卡不够好说不定在网卡里的延迟都
: 要过1us了吧。
: 十大观光党路过，不太了解事情的来龙去脉，有什么总结贴么？
|
l******o
发帖数: 144 | 5 还是不太明确啊，我才疏学浅，不太懂ping是在哪里处理的？在网卡就直接处理了，还
是在kernel处理的，还是在user space？如果ping在网卡处理，那就是说1us必须包含
packet在网卡和kernel的时间， 那对于wei非常不利；反之，如果ping在user space处
理，那么1us就只是在user space的时间，对wei有利。我觉得延迟这个需求不是特别明
确，有必要加以定义清楚。
当然1M的QPS这个需求还算明确。其实只要multi core同时处理N个request，那么延迟
只要达到N us就可以了，比1us这个就宽松多了。
比如ping一个，有个网络延迟，1us处理的意思就是结果还是跟ping一样。如果有显著
延迟那显然不行。
当然我们说的是宏观上，不是每个包都确保1us.
【在 b*******g 的大作中提到】
: 比如ping一个，有个网络延迟，1us处理的意思就是结果还是跟ping一样。如果有显著
: 延迟那显然不行。
: 当然我们说的是宏观上，不是每个包都确保1us.
|
s******u
发帖数: 501 | 6 网卡不处理ping，这个由network stack在kernel处理，然后再通过网卡发送response
packet回去
【在 l******o 的大作中提到】
: 还是不太明确啊，我才疏学浅，不太懂ping是在哪里处理的？在网卡就直接处理了，还
: 是在kernel处理的，还是在user space？如果ping在网卡处理，那就是说1us必须包含
: packet在网卡和kernel的时间， 那对于wei非常不利；反之，如果ping在user space处
: 理，那么1us就只是在user space的时间，对wei有利。我觉得延迟这个需求不是特别明
: 确，有必要加以定义清楚。
: 当然1M的QPS这个需求还算明确。其实只要multi core同时处理N个request，那么延迟
: 只要达到N us就可以了，比1us这个就宽松多了。
:
: 比如ping一个，有个网络延迟，1us处理的意思就是结果还是跟ping一样。如果有显著
: 延迟那显然不行。
|
b*******g
发帖数: 603 | 7 白盒测试。他说了单线程写，先看正确性。然后测本地能 1us, 然后再测 qps.
【在 l******o 的大作中提到】
: 还是不太明确啊，我才疏学浅，不太懂ping是在哪里处理的？在网卡就直接处理了，还
: 是在kernel处理的，还是在user space？如果ping在网卡处理，那就是说1us必须包含
: packet在网卡和kernel的时间， 那对于wei非常不利；反之，如果ping在user space处
: 理，那么1us就只是在user space的时间，对wei有利。我觉得延迟这个需求不是特别明
: 确，有必要加以定义清楚。
: 当然1M的QPS这个需求还算明确。其实只要multi core同时处理N个request，那么延迟
: 只要达到N us就可以了，比1us这个就宽松多了。
:
: 比如ping一个，有个网络延迟，1us处理的意思就是结果还是跟ping一样。如果有显著
: 延迟那显然不行。
|
l******o
发帖数: 144 | 8 只是本地，完全不考虑网络的话，还是很容易的。我写了一下，大概每秒能handle 5-
6M张票。
白盒测试。他说了单线程写，先看正确性。然后测本地能 1us, 然后再测 qps.
【在 b*******g 的大作中提到】
: 白盒测试。他说了单线程写，先看正确性。然后测本地能 1us, 然后再测 qps.
|
z*******r
发帖数: 415 | 9 是的小朋友,恭喜你实现了一个魏式订票机
【在 l******o 的大作中提到】
: 只是本地，完全不考虑网络的话，还是很容易的。我写了一下，大概每秒能handle 5-
: 6M张票。
:
: 白盒测试。他说了单线程写，先看正确性。然后测本地能 1us, 然后再测 qps.
|
j******a
发帖数: 100 | 10 新的网卡早能offload这活了，我是看好魏老师，摩尔定律大家都知道，呵呵
直接上E788xx v3 3T memory + 4张100G LAN
没什么不可能的，搞不好轻轻松松，等code都出来我找机器做测试 |
n**********5
发帖数: 1707 | 11 除非不走TCP/IP，否则有一个“窗口”问题。要注意packet大小。Twitter就限制消息
长度在一个packet以内以最大限度增加并发数。
还有就是不能用传统的网络服务架构。因为它们并发进来的request数超过CPU数则要放
到队列里等待处理。这个队列长度是有限制的（5000？）。超过了了就杯具了。
TCP/IP还有一个杀笔的地方是协商通讯速度。理论上没个用户进来都要先协商一下。从
醉慢速度开始协商。管你是的速度是1TTTBps。等协商完哪真是黄花菜都凉了。
现在的小青年会刷算法白布。这些脏乱差和他们是没啥关系的。
【在 j******a 的大作中提到】
: 新的网卡早能offload这活了，我是看好魏老师，摩尔定律大家都知道，呵呵
: 直接上E788xx v3 3T memory + 4张100G LAN
: 没什么不可能的，搞不好轻轻松松，等code都出来我找机器做测试
|
j******a
发帖数: 100 | 12 这里的人应该不关心硬件发展的，这些年virtualization的需求出来以后，能想到的HW
优化基本都有了，上边说E7-88xx 找18core的，我不用HT,一台4 way就有72 core，现
在kernel的network stack优化使得一个interrupt进去效率很高，网卡上一堆一堆的
queue，封包加密安全隔离你能想到的都在网卡做掉了，连最基本的DMA都有crystal
beach做了，实测100G跑满，kernel time很低。你这个backlog 哪里跑得满。
做硬件真tmd的jian，这么台机器可能2w能配下来。考虑转行刷题中.. |
