d*******r
发帖数: 3299 | 1 我支持 TeacherWei 和 Goodbug 专开一帖制定需求
不然大家自己说自己的，这个没法进展啊 |
n**x
发帖数: 606 | |
n*****t
发帖数: 22014 | 3 需要 buyer seller initial
【在 n**x 的大作中提到】
: 我已经把老魏的方案写出来了， 老魏似乎没啥异议：
: http://www.mitbbs.com/article_t/Programming/31312727.html
|
z****e
发帖数: 54598 | |
d***a
发帖数: 13752 | 5 写得不错。
还可以简化。按魏那个方案，网卡不是瓶颈，主要是看schedule能不能达到throughput
的要求。
可以简化成这样：事先生成一个文件，包含500M个出票请求。写一个程序，读取请求，
生成出票记录，写到一个输出文件里。如果能在100秒内完成，并且结果正确，那就算
行了。
这样做测试的一个好处，是测试简单，做完后谁都可以测试一下。
【在 n**x 的大作中提到】
: 我已经把老魏的方案写出来了， 老魏似乎没啥异议：
: http://www.mitbbs.com/article_t/Programming/31312727.html
|
z****e
发帖数: 54598 | 6 出票也是一个很繁琐的过程
估计老魏又交给了其他server去做
估计他那台机器只有一个功能
throughput
【在 d***a 的大作中提到】
: 写得不错。
: 还可以简化。按魏那个方案，网卡不是瓶颈，主要是看schedule能不能达到throughput
: 的要求。
: 可以简化成这样：事先生成一个文件，包含500M个出票请求。写一个程序，读取请求，
: 生成出票记录，写到一个输出文件里。如果能在100秒内完成，并且结果正确，那就算
: 行了。
: 这样做测试的一个好处，是测试简单，做完后谁都可以测试一下。
|
L***n
发帖数: 6727 | 7 schedue双方定义差别较大...
throughput
【在 d***a 的大作中提到】
: 写得不错。
: 还可以简化。按魏那个方案，网卡不是瓶颈，主要是看schedule能不能达到throughput
: 的要求。
: 可以简化成这样：事先生成一个文件，包含500M个出票请求。写一个程序，读取请求，
: 生成出票记录，写到一个输出文件里。如果能在100秒内完成，并且结果正确，那就算
: 行了。
: 这样做测试的一个好处，是测试简单，做完后谁都可以测试一下。
|
n*****t
发帖数: 22014 | 8 恩，network io 换成 disk io，基本公平
throughput
【在 d***a 的大作中提到】
: 写得不错。
: 还可以简化。按魏那个方案，网卡不是瓶颈，主要是看schedule能不能达到throughput
: 的要求。
: 可以简化成这样：事先生成一个文件，包含500M个出票请求。写一个程序，读取请求，
: 生成出票记录，写到一个输出文件里。如果能在100秒内完成，并且结果正确，那就算
: 行了。
: 这样做测试的一个好处，是测试简单，做完后谁都可以测试一下。
|
z****e
发帖数: 54598 | 9 这样会做成主机的
【在 n*****t 的大作中提到】
: 恩，network io 换成 disk io，基本公平
:
: throughput
|
S*A
发帖数: 7142 | 10 network io 换成 disk 是不公平的。
network 的中断数目高很多很多。 |
|
|
n*****t
发帖数: 22014 | 11 你去看看老魏的 network，再跟好虫掐一掐
【在 S*A 的大作中提到】
: network io 换成 disk 是不公平的。
: network 的中断数目高很多很多。
|
n*****t
发帖数: 22014 | 12 这本来就没啥不妥，拉长流水线，老板只负责签字，能出货就行
【在 z****e 的大作中提到】
: 出票也是一个很繁琐的过程
: 估计老魏又交给了其他server去做
: 估计他那台机器只有一个功能
:
: throughput
|
z****e
发帖数: 54598 | 13 关键是老魏一开始要吹牛自己是牛鼻单机
问题在于，没做多少事
【在 n*****t 的大作中提到】
: 这本来就没啥不妥，拉长流水线，老板只负责签字，能出货就行
|
d***a
发帖数: 13752 | 14 他那个方案，network倒真应该不是问题。
也可以再做一个测试，写一个web server，把收到的request收集起来放到一个文件里
。如果100秒内，能往文件里写入500M个请求（假设有足够的请求），那网络部分就算
过关了。再把这部分和schedule部分合起来，就是一个系统了。
【在 S*A 的大作中提到】
: network io 换成 disk 是不公平的。
: network 的中断数目高很多很多。
|
n*****t
发帖数: 22014 | 15 我不知道老魏打算怎么实现，我的设计就是一个金字塔，我保证塔尖一个节点能做到
1M/s
【在 z****e 的大作中提到】
: 关键是老魏一开始要吹牛自己是牛鼻单机
: 问题在于，没做多少事
|
T********i
发帖数: 2416 | 16 假定每个请求100字节，如果做不到10M REQs/SEC 算我输。
【在 d***a 的大作中提到】
: 他那个方案，network倒真应该不是问题。
: 也可以再做一个测试，写一个web server，把收到的request收集起来放到一个文件里
: 。如果100秒内，能往文件里写入500M个请求（假设有足够的请求），那网络部分就算
: 过关了。再把这部分和schedule部分合起来，就是一个系统了。
|
z****e
发帖数: 54598 | 17 response阿，查询的response可不小哦，100字节够做啥事
当然我知道，你会把这一块剥离给其他server去做的
【在 T********i 的大作中提到】
: 假定每个请求100字节，如果做不到10M REQs/SEC 算我输。
|
n*****t
发帖数: 22014 | 18 哎妈你比我阔气多了，我一个 req 4-8 bytes，1M/s
【在 T********i 的大作中提到】
: 假定每个请求100字节，如果做不到10M REQs/SEC 算我输。
|
T********i
发帖数: 2416 | 19 肯定地说 10M TPS/s没压力。
做到20M有可能。
今年年中Intel新server出来是50-80M。
【在 n*****t 的大作中提到】
: 哎妈你比我阔气多了，我一个 req 4-8 bytes，1M/s
|
