n**x
发帖数: 606 | 1 按照老魏的算法，详见：
http://www.mitbbs.com/article_t0/Programming/31312727.html
我做了如下测试：
- 纯计算.
- 12 core xeon
- 200 concurrent threads（大家都说200个太浪费，我当然没坐过此类应用， 不过我
测了12,24,50,100,结果都差不多，没提高多少）
- one big array: long[20000]
- every thread handles 50,000 interlocked.increment (get random item from
the array and do increment)
- total number of interlocked.increment = 1千万 (10M)
average time spent: 0.2 second.
也就是每秒50M. |
n*****t
发帖数: 22014 | 2 差不多，如果考虑 network/disk io 的话，5m/s 不是狠可怕
【在 n**x 的大作中提到】
: 按照老魏的算法，详见：
: http://www.mitbbs.com/article_t0/Programming/31312727.html
: 我做了如下测试：
: - 纯计算.
: - 12 core xeon
: - 200 concurrent threads（大家都说200个太浪费，我当然没坐过此类应用， 不过我
: 测了12,24,50,100,结果都差不多，没提高多少）
: - one big array: long[20000]
: - every thread handles 50,000 interlocked.increment (get random item from
: the array and do increment)
|
b*******s
发帖数: 5216 | 3 不错
【在 n**x 的大作中提到】
: 按照老魏的算法，详见：
: http://www.mitbbs.com/article_t0/Programming/31312727.html
: 我做了如下测试：
: - 纯计算.
: - 12 core xeon
: - 200 concurrent threads（大家都说200个太浪费，我当然没坐过此类应用， 不过我
: 测了12,24,50,100,结果都差不多，没提高多少）
: - one big array: long[20000]
: - every thread handles 50,000 interlocked.increment (get random item from
: the array and do increment)
|
b*******s
发帖数: 5216 | 4 主要问题还是在io上
【在 n*****t 的大作中提到】
: 差不多，如果考虑 network/disk io 的话，5m/s 不是狠可怕
|
n**x
发帖数: 606 | 5 老魏有超级网卡，io号称不是问题。。 呵呵。硬件我不懂。
【在 b*******s 的大作中提到】
: 主要问题还是在io上
|
n*****t
发帖数: 22014 | 6 我预估的是 1M/s 处理能力，比较保守，不过也能满足应用需求了
【在 b*******s 的大作中提到】
: 主要问题还是在io上
|
b*******s
发帖数: 5216 | 7 我估计half million应该问题不大，实际环境
【在 n*****t 的大作中提到】
: 我预估的是 1M/s 处理能力，比较保守，不过也能满足应用需求了
|
q*c
发帖数: 9453 | 8 这只是对内操作， 还要把这些结果以对外network IO 的方式传出去。
【在 n**x 的大作中提到】
: 按照老魏的算法，详见：
: http://www.mitbbs.com/article_t0/Programming/31312727.html
: 我做了如下测试：
: - 纯计算.
: - 12 core xeon
: - 200 concurrent threads（大家都说200个太浪费，我当然没坐过此类应用， 不过我
: 测了12,24,50,100,结果都差不多，没提高多少）
: - one big array: long[20000]
: - every thread handles 50,000 interlocked.increment (get random item from
: the array and do increment)
|
n**x
发帖数: 606 | 9 老魏有超级网卡，io号称不是问题。。 呵呵。硬件我不懂。
【在 q*c 的大作中提到】
: 这只是对内操作， 还要把这些结果以对外network IO 的方式传出去。
|
q*c
发帖数: 9453 | 10 而且你不能单纯 increment. 每次increment 后还要 compare, 超过了上限要
rollback. 这些都只算一个 transaction.
而且因为有人不断退票， 所以每次都得 compare.
【在 q*c 的大作中提到】
: 这只是对内操作， 还要把这些结果以对外network IO 的方式传出去。
|
|
|
b*******s
发帖数: 5216 | 11 我觉得老魏再做个io的试验
这事就结了吧
不懂的人这辈子都搞不懂的
【在 n**x 的大作中提到】
: 老魏有超级网卡，io号称不是问题。。 呵呵。硬件我不懂。
|
n*****t
发帖数: 22014 | 12 Network 其实还好，据说老魏的网卡毫无压力，基本就是几个 clock 的 io weite
disk io 会开销大点，当然可以考虑干脆不写了，真当鸡了就从前端按 log 算
【在 q*c 的大作中提到】
: 这只是对内操作， 还要把这些结果以对外network IO 的方式传出去。
|
b*******s
发帖数: 5216 | 13 要考虑全部当掉，所以总得有人写disk
【在 n*****t 的大作中提到】
: Network 其实还好，据说老魏的网卡毫无压力，基本就是几个 clock 的 io weite
: disk io 会开销大点，当然可以考虑干脆不写了，真当鸡了就从前端按 log 算
|
q*c
发帖数: 9453 | 14 问题是超级网卡也要 CPU 啊。难道某种网卡根本不需要 CPU 负载就把数据传出传入
500 万次每秒？
再把 compare, rollback 等加上， 50 万次也许就成了 10 万次了。
【在 n**x 的大作中提到】
: 老魏有超级网卡，io号称不是问题。。 呵呵。硬件我不懂。
|
n*****t
发帖数: 22014 | 15 前端实际出票的写，抢到就是赚到，保证不冲突，核心节点就不用管了
【在 b*******s 的大作中提到】
: 要考虑全部当掉，所以总得有人写disk
|
b*******s
发帖数: 5216 | 16 等老魏做io实验吧
反正我没有超级网卡
原子操作的我迟一点在老机器上再做一遍，摸个下限
【在 q*c 的大作中提到】
: 问题是超级网卡也要 CPU 啊。难道某种网卡根本不需要 CPU 负载就把数据传出传入
: 500 万次每秒？
: 再把 compare, rollback 等加上， 50 万次也许就成了 10 万次了。
|
n*****t
发帖数: 22014 | 17 10 万次也够了，再上老魏的牛叉鸡，性能还能翻 2-3 番
【在 q*c 的大作中提到】
: 问题是超级网卡也要 CPU 啊。难道某种网卡根本不需要 CPU 负载就把数据传出传入
: 500 万次每秒？
: 再把 compare, rollback 等加上， 50 万次也许就成了 10 万次了。
|
b*******s
发帖数: 5216 | 18 总共峰值也就20万请求，老魏单机够了
【在 n*****t 的大作中提到】
: 10 万次也够了，再上老魏的牛叉鸡，性能还能翻 2-3 番
|
S*A
发帖数: 7142 | 19 靠，这道题的关键瓶颈就在 IO。
那个内存做 atomic 操作的那里有什么压力。
每次操作 IO 的时候网卡 driver 上面都有 lock。
而且还不止一个。一个系统的快慢是由最慢的环节
决定的。
5M tcp OPS，每个 TCP 需要三个包建立两个包
撤销。单机 5M TCP 是吊爆天的东西。让我们拭目
以待看看实测，没有实测我坚决不相信。 |
n*****t
发帖数: 22014 | 20 前端可以 combine requests，一个包 512B，包含 40 个 requests
【在 S*A 的大作中提到】
: 靠，这道题的关键瓶颈就在 IO。
: 那个内存做 atomic 操作的那里有什么压力。
: 每次操作 IO 的时候网卡 driver 上面都有 lock。
: 而且还不止一个。一个系统的快慢是由最慢的环节
: 决定的。
: 5M tcp OPS，每个 TCP 需要三个包建立两个包
: 撤销。单机 5M TCP 是吊爆天的东西。让我们拭目
: 以待看看实测，没有实测我坚决不相信。
|
|
|
b*******s
发帖数: 5216 | 21 内存原子操作的效率已经打了很多人的脸了
【在 S*A 的大作中提到】
: 靠，这道题的关键瓶颈就在 IO。
: 那个内存做 atomic 操作的那里有什么压力。
: 每次操作 IO 的时候网卡 driver 上面都有 lock。
: 而且还不止一个。一个系统的快慢是由最慢的环节
: 决定的。
: 5M tcp OPS，每个 TCP 需要三个包建立两个包
: 撤销。单机 5M TCP 是吊爆天的东西。让我们拭目
: 以待看看实测，没有实测我坚决不相信。
|
z****g
发帖数: 75 | 22 200threads 太多了，一个NIC一个，了不得一个core一个才行
【在 n**x 的大作中提到】
: 按照老魏的算法，详见：
: http://www.mitbbs.com/article_t0/Programming/31312727.html
: 我做了如下测试：
: - 纯计算.
: - 12 core xeon
: - 200 concurrent threads（大家都说200个太浪费，我当然没坐过此类应用， 不过我
: 测了12,24,50,100,结果都差不多，没提高多少）
: - one big array: long[20000]
: - every thread handles 50,000 interlocked.increment (get random item from
: the array and do increment)
|
T********i
发帖数: 2416 | 23 他的这个大多消耗在context switching上。尤其是0.2m，分布及其不均匀。
所有我说他根本没做做过此类应用。
No offense。术业有专攻而已。非常感谢他花时间做实验。
【在 z****g 的大作中提到】
: 200threads 太多了，一个NIC一个，了不得一个core一个才行
|
S*A
发帖数: 7142 | 24 那就不是 5M TCP OPS。
combine 就没有公平性。因为你 combine 就需要前端不是最快时间
把数据包发出去，而是等后面攒足够多了一起发。你攒的时候，别人
后发的 request 可以先到达牛B机器。
【在 n*****t 的大作中提到】
: 前端可以 combine requests，一个包 512B，包含 40 个 requests
|
n*****t
发帖数: 22014 | 25 前端和后端之间有中端，负责把 http request 转换成 TCP，捎带打包一下 requests
也没啥问题，对前端来说还是一样结果。再说，你真的那么在乎几个 us 的公平吗？
【在 S*A 的大作中提到】
: 那就不是 5M TCP OPS。
: combine 就没有公平性。因为你 combine 就需要前端不是最快时间
: 把数据包发出去，而是等后面攒足够多了一起发。你攒的时候，别人
: 后发的 request 可以先到达牛B机器。
|
S*A
发帖数: 7142 | 26 我没由爬全部的楼，你的意思是是 50M 比预计
的要低很多吗？
【在 b*******s 的大作中提到】
: 内存原子操作的效率已经打了很多人的脸了
|
T********i
发帖数: 2416 | 27 你连Throughput优化和latency优化都不知道，还是别说为好。
就算latency优化，单网卡可达20M IOPS。更何况我是双网卡。
不懂可以牵狗。难道非要有老师教才能学习么？
【在 S*A 的大作中提到】
: 那就不是 5M TCP OPS。
: combine 就没有公平性。因为你 combine 就需要前端不是最快时间
: 把数据包发出去，而是等后面攒足够多了一起发。你攒的时候，别人
: 后发的 request 可以先到达牛B机器。
|
S*A
发帖数: 7142 | 28 请给出接口让好虫测一下你的 5M 吧，
Talk is cheap。
【在 T********i 的大作中提到】
: 你连Throughput优化和latency优化都不知道，还是别说为好。
: 就算latency优化，单网卡可达20M IOPS。更何况我是双网卡。
: 不懂可以牵狗。难道非要有老师教才能学习么？
|
n**x
发帖数: 606 | 29 测了12个thread,结果差不多还是大约0.2秒。说明我的机器性能还是不错滴。。呵呵。
context switch,几个register而已。。。
【在 T********i 的大作中提到】
: 他的这个大多消耗在context switching上。尤其是0.2m，分布及其不均匀。
: 所有我说他根本没做做过此类应用。
: No offense。术业有专攻而已。非常感谢他花时间做实验。
|
d***a
发帖数: 13752 | 30 你这TCP/IP stack是特制的吧
搞了user-level TCP/IP, zero copy等技巧?
【在 T********i 的大作中提到】
: 你连Throughput优化和latency优化都不知道，还是别说为好。
: 就算latency优化，单网卡可达20M IOPS。更何况我是双网卡。
: 不懂可以牵狗。难道非要有老师教才能学习么？
|
|
|
T********i
发帖数: 2416 | 31 Solarflare OpenOnLoad
Kernel by pass。
【在 d***a 的大作中提到】
: 你这TCP/IP stack是特制的吧
: 搞了user-level TCP/IP, zero copy等技巧?
|
b*******s
发帖数: 5216 | 32 有时还牵涉到cache write through和reload
尤其是跨进程，代价非常大
【在 n**x 的大作中提到】
: 测了12个thread,结果差不多还是大约0.2秒。说明我的机器性能还是不错滴。。呵呵。
: context switch,几个register而已。。。
|
T********i
发帖数: 2416 | 33 你测6个试一试？
或许能至少加倍 :-)
【在 n**x 的大作中提到】
: 测了12个thread,结果差不多还是大约0.2秒。说明我的机器性能还是不错滴。。呵呵。
: context switch,几个register而已。。。
|
b*******s
发帖数: 5216 | 34 hoho，又学到一点
【在 T********i 的大作中提到】
: Solarflare OpenOnLoad
: Kernel by pass。
|
d***a
发帖数: 13752 | 35 呵呵，我很久以前做过类似的项目，把linux kernel搞崩溃了N次。
【在 T********i 的大作中提到】
: Solarflare OpenOnLoad
: Kernel by pass。
|
S*A
发帖数: 7142 | 36 context switch 可不是几个 register。
建议测一下和 core 数目一样多的 thread。
【在 n**x 的大作中提到】
: 测了12个thread,结果差不多还是大约0.2秒。说明我的机器性能还是不错滴。。呵呵。
: context switch,几个register而已。。。
|
h**********c
发帖数: 4120 | 37 tech tip ONLY
Linux card bond can combine multiple physical card, i used two cards bond
before, theoretically can be two+.
Real scenario: one card only send, the other one ceceives.
shown in ifconfig |
n**x
发帖数: 606 | 38 12个core，12个thread,还是0.2秒. 看样子context switch的效率还是比较高的。我的
系统是windows server 2012 R2.
【在 S*A 的大作中提到】
: context switch 可不是几个 register。
: 建议测一下和 core 数目一样多的 thread。
|
T********i
发帖数: 2416 | 39 你错了，有些core被系统占用，可能导致分配不均。
而且Windows Scheduler粒度过粗。
所以，建议用6个core。
【在 n**x 的大作中提到】
: 12个core，12个thread,还是0.2秒. 看样子context switch的效率还是比较高的。我的
: 系统是windows server 2012 R2.
|
h**********c
发帖数: 4120 | 40 tech tip ONLY I
Linux card bond can combine multiple physical card, i used two cards bond
before, theoretically can be two+.
Real scenario: one card only send, the other one ceceives.
shown in ifconfig
tech tip ONLY II
research on Linux volume in memory, I used it in my 8G desktop for my thesis
five years ago |
|
|
h**********c
发帖数: 4120 | 41 The point of II is a home work.
I lao give the answer tomorrow.
thesis
【在 h**********c 的大作中提到】
: tech tip ONLY I
: Linux card bond can combine multiple physical card, i used two cards bond
: before, theoretically can be two+.
: Real scenario: one card only send, the other one ceceives.
: shown in ifconfig
: tech tip ONLY II
: research on Linux volume in memory, I used it in my 8G desktop for my thesis
: five years ago
|
b*******s
发帖数: 5216 | 42 赞，有启发
thesis
【在 h**********c 的大作中提到】
: tech tip ONLY I
: Linux card bond can combine multiple physical card, i used two cards bond
: before, theoretically can be two+.
: Real scenario: one card only send, the other one ceceives.
: shown in ifconfig
: tech tip ONLY II
: research on Linux volume in memory, I used it in my 8G desktop for my thesis
: five years ago
|
S*A
发帖数: 7142 | 43 那个 20 M OPS 估计是 UDP 盲发吧，如果是那样，
有 context 来回那种会低些。就算是 20M OPS，
用 5M TCP 带建立连接已经不够了。所以我很好奇
老老实实 TCP 建立连接可以做到多少 M。
我看了一下那个 OpenOnLoad 的演讲， 还挺有意思的。 |
n*****t
发帖数: 22014 | 44 TCP连接为啥要断？
【在 S*A 的大作中提到】
: 那个 20 M OPS 估计是 UDP 盲发吧，如果是那样，
: 有 context 来回那种会低些。就算是 20M OPS，
: 用 5M TCP 带建立连接已经不够了。所以我很好奇
: 老老实实 TCP 建立连接可以做到多少 M。
: 我看了一下那个 OpenOnLoad 的演讲， 还挺有意思的。
|
i*****o
发帖数: 1714 | 45 在老魏的算法里，他做最后端，在他前面有无数个web front。所以他只要和每个web
front 搭一个persistent tcp就好了。
★ 发自iPhone App: ChineseWeb 8.6
【在 S*A 的大作中提到】
: 那个 20 M OPS 估计是 UDP 盲发吧，如果是那样，
: 有 context 来回那种会低些。就算是 20M OPS，
: 用 5M TCP 带建立连接已经不够了。所以我很好奇
: 老老实实 TCP 建立连接可以做到多少 M。
: 我看了一下那个 OpenOnLoad 的演讲， 还挺有意思的。
|
g*****g
发帖数: 34805 | 46 increment是不行的，你最少也要做InterlockedCompareExchange吧。
另外，网络来的请求，serialization, deserialization都是需要cpu的。
【在 n**x 的大作中提到】
: 按照老魏的算法，详见：
: http://www.mitbbs.com/article_t0/Programming/31312727.html
: 我做了如下测试：
: - 纯计算.
: - 12 core xeon
: - 200 concurrent threads（大家都说200个太浪费，我当然没坐过此类应用， 不过我
: 测了12,24,50,100,结果都差不多，没提高多少）
: - one big array: long[20000]
: - every thread handles 50,000 interlocked.increment (get random item from
: the array and do increment)
|
h**********c
发帖数: 4120 | 47 Somebody mentioned Gemfire like, so I don't have to Maiguanzi.
The point is if it is a volume in memory, then it can go NFS, GFS for
redundancy.
So the memory volume is not volatile, redundnacy saved in NFS, it can even
be hybrid (mechanic disks/volumes + main memory disks/volumes).
【在 h**********c 的大作中提到】
: The point of II is a home work.
: I lao give the answer tomorrow.
:
: thesis
|
g*****g
发帖数: 34805 | 48 The budget is 20K, you better don't go too fancy.
【在 h**********c 的大作中提到】
: Somebody mentioned Gemfire like, so I don't have to Maiguanzi.
: The point is if it is a volume in memory, then it can go NFS, GFS for
: redundancy.
: So the memory volume is not volatile, redundnacy saved in NFS, it can even
: be hybrid (mechanic disks/volumes + main memory disks/volumes).
|
h**********c
发帖数: 4120 | 49 200G ECC 1000d abt
in developing countries, can be less expansive.
Regards,
【在 g*****g 的大作中提到】
: The budget is 20K, you better don't go too fancy.
|
a****i
发帖数: 1182 | 50 代码有没有？
【在 n**x 的大作中提到】
: 按照老魏的算法，详见：
: http://www.mitbbs.com/article_t0/Programming/31312727.html
: 我做了如下测试：
: - 纯计算.
: - 12 core xeon
: - 200 concurrent threads（大家都说200个太浪费，我当然没坐过此类应用， 不过我
: 测了12,24,50,100,结果都差不多，没提高多少）
: - one big array: long[20000]
: - every thread handles 50,000 interlocked.increment (get random item from
: the array and do increment)
|
|
|
n**x
发帖数: 606 | 51 就是起100个thread,每个队一个大数字做interlocked.increment。很简单。代码我正
在升级为增强版，看看能不能模拟真实情况。
【在 a****i 的大作中提到】
: 代码有没有？
|
a****i
发帖数: 1182 | 52 你确定这个可以锁票？我有点糊涂了
比如说卖了济南到上海的(T[234], S2)，南京到上海区段就也要锁一张(T[234], S6)
简单地 Interlocked.Decrement( T[X234，S2] ) 怕是不行吧？
不需要锁S3, S4, S5....？
联票可能更有问题
【在 n**x 的大作中提到】
: 就是起100个thread,每个队一个大数字做interlocked.increment。很简单。代码我正
: 在升级为增强版，看看能不能模拟真实情况。
|
g*****g
发帖数: 34805 | 53 我简单的测试用例给了。没有正确性不谈性能，常识。
【在 n**x 的大作中提到】
: 就是起100个thread,每个队一个大数字做interlocked.increment。很简单。代码我正
: 在升级为增强版，看看能不能模拟真实情况。
|
f******n
发帖数: 314 | 54 太尼玛牛逼了，这么个复杂的系统就被转进成内存锁 io 网卡之类的性能测试了。别整
虚的，代码挂出来看看! |
z****e
发帖数: 54598 | 55 老魏没有锁，千万记住，呀的就是一个计数器
用最简单的原子操作回避了锁的操作
我们都错了，多线程上来就教锁，老魏认为这是错误的
十个图零奖小意思
【在 f******n 的大作中提到】
: 太尼玛牛逼了，这么个复杂的系统就被转进成内存锁 io 网卡之类的性能测试了。别整
: 虚的，代码挂出来看看!
|
g*********9
发帖数: 1285 | 56 随便上个lockfree的算法，能提高一大截，这个结果太差，不make sense.
【在 n**x 的大作中提到】
: 按照老魏的算法，详见：
: http://www.mitbbs.com/article_t0/Programming/31312727.html
: 我做了如下测试：
: - 纯计算.
: - 12 core xeon
: - 200 concurrent threads（大家都说200个太浪费，我当然没坐过此类应用， 不过我
: 测了12,24,50,100,结果都差不多，没提高多少）
: - one big array: long[20000]
: - every thread handles 50,000 interlocked.increment (get random item from
: the array and do increment)
|
