T********i
发帖数: 2416 | 1 qxc也承认5M TPS REST是强人所难。
假定每个请求1000字节，就要超过25G的带宽。你有这种网络环境么？
更何况要支撑5M的TCP连接请求。着不是闹着玩的。
500K倒是没啥问题，有人如果肯拿100K刀赌一把我愿意迎战。 |
x****u
发帖数: 44466 | 2 魏老师你不能把啥话题都跑题到自己的三分地上去。
【在 T********i 的大作中提到】
: qxc也承认5M TPS REST是强人所难。
: 假定每个请求1000字节，就要超过25G的带宽。你有这种网络环境么？
: 更何况要支撑5M的TCP连接请求。着不是闹着玩的。
: 500K倒是没啥问题，有人如果肯拿100K刀赌一把我愿意迎战。
|
w***g
发帖数: 5958 | 3 同意。HTTP overhead太大，远远超出了实际数据大小。100K刀太多了，赌不起。
你后台不需要支持5M的TCP连接请求。最少只需要支持你cache机数量的链接就行。
【在 T********i 的大作中提到】
: qxc也承认5M TPS REST是强人所难。
: 假定每个请求1000字节，就要超过25G的带宽。你有这种网络环境么？
: 更何况要支撑5M的TCP连接请求。着不是闹着玩的。
: 500K倒是没啥问题，有人如果肯拿100K刀赌一把我愿意迎战。
|
T********i
发帖数: 2416 | 4 怎么叫我的三分地？
goodbug一口咬定我不是做网站的，他是做网站的。
这个REST算网站吧？是不是比他的还网站？单机500K TPS还附送抢票功能。
【在 x****u 的大作中提到】
: 魏老师你不能把啥话题都跑题到自己的三分地上去。
|
x****u
发帖数: 44466 | 5 12306这种网站，一切技术的前提必须是能及其灵活的定义规则，修改运行模式。
多几倍的机器不是大问题，但某个紧急策略布置不下去麻烦就大了。
你们把出票率当成最大问题，方向就不对。
【在 T********i 的大作中提到】
: 怎么叫我的三分地？
: goodbug一口咬定我不是做网站的，他是做网站的。
: 这个REST算网站吧？是不是比他的还网站？单机500K TPS还附送抢票功能。
|
T********i
发帖数: 2416 | 6 我这个交易系统，前端GUI不同的Window就10几个。
20” monitor 9个实时监控还嫌不够用。
论实时灵活定义规则，实时操纵实时系统，12306这种实在小儿科。
我把票源控制住了。搞定了。规则可以在前端web机上改。任何时候都能实时上线。
后端座位分配也scale out了，那上面也可以改规则。
你们这种一样做不好的，样样都做不好。
不懂技术，就不懂business。
【在 x****u 的大作中提到】
: 12306这种网站，一切技术的前提必须是能及其灵活的定义规则，修改运行模式。
: 多几倍的机器不是大问题，但某个紧急策略布置不下去麻烦就大了。
: 你们把出票率当成最大问题，方向就不对。
|
T********i
发帖数: 2416 | |
x****u
发帖数: 44466 | 8 你对“灵活”和“规则”的理解太简单了。
【在 T********i 的大作中提到】
: 我这个交易系统，前端GUI不同的Window就10几个。
: 20” monitor 9个实时监控还嫌不够用。
: 论实时灵活定义规则，实时操纵实时系统，12306这种实在小儿科。
: 我把票源控制住了。搞定了。规则可以在前端web机上改。任何时候都能实时上线。
: 后端座位分配也scale out了，那上面也可以改规则。
: 你们这种一样做不好的，样样都做不好。
: 不懂技术，就不懂business。
|
z*******3
发帖数: 13709 | 9 qxc不是说了，cloud内部用带宽不算钱么？
难不成打算不用cloud了？
【在 T********i 的大作中提到】
: qxc也承认5M TPS REST是强人所难。
: 假定每个请求1000字节，就要超过25G的带宽。你有这种网络环境么？
: 更何况要支撑5M的TCP连接请求。着不是闹着玩的。
: 500K倒是没啥问题，有人如果肯拿100K刀赌一把我愿意迎战。
|
