有专门讲 message server performance 的资料吗 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Programming - 葵花宝典

有专门讲 message server performance 的资料吗

有专门讲 message server performance 的资料吗# Programming - 葵花宝典

z*a2014-02-20 08:02

1 楼

各位大牛好。
我目前处在F1 OPT，目前公司帮我申请H1B的材料今天刚寄到Vermont移民局，还不知道
今年能不能抽中。我目前想注册一家C Corp公司，我知道这个是没有问题的。关键的问
题是如何证明我没有运营这个自己的公司，那这样的话是不是需要我雇佣一个合法的人
（比如有opt的同学？）给公司工作，管理，我付工资就行？
还有就是我以后打算回国，可能今年底或明年吧，那这个公司还是靠这样的模式运行，
我在国内网上联系就行吗？人回到了国内，公司还可以继续存在吧？
谢谢各位！

P*a2014-02-20 08:02

2 楼

太小气和斤斤计较，令人再也不想和其打交道。
做BF还是不错的

e*u2014-02-20 08:02

3 楼

【以下文字转载自 Family 讨论区】
发信人: LACBC (CBC), 信区: Family
标题: 男同胞们，千万别让你的lp/gf看av
发信站: BBS 未名空间站 (Fri Jul 17 01:16:40 2009, 美东)
迷上后患无穷啊。我gf迷上av后对xx的要求呈直线上升，令我忙于招架。那可不是一般
的一周三次啊。刚开始我还奇怪怎么她突然对xx要求多了，最近才发现她偷偷看av

d*n2014-02-20 08:02

4 楼

现在的穿越剧，穿越小说看多了，很多人都会说，穿越回古代多好啊，那个时候山清水
秀，空气新鲜，食物都是没有添加剂的，也不用上学考试，简直是好山好水好快活。
可是古代没有想象的那么美好，毕竟是落后的时代，食物也远远没有现如今这么丰富。
中国的菜谱都是一代一代传下来的，又不断的创新，古代虽然也有很多种食物的做法，
但是古代的规矩和禁忌很多，牛肉都是奢侈品，只有身份极为特殊的人才可以吃得到，
比如身份显赫的人，和强盗之类的非正常渠道获得的。
毕竟古代是没有现在这么机械化的，牛是和人类一起工作的伙伴，是家庭成员，谁家里
有1头牛，有10头牛和没有牛，这些差别都很大，直接代表了阶层和家庭贫富差距，可
能就跟现在有几套房子，几辆豪车的差距类似。
牛越多，代表这家的劳动能力越多，那么收成也就越好，生活也更加宽裕。
这么重要的牛，在古代是不让吃的，谁也不敢随便吃牛肉，这是犯法的，而且一般人也
不会吃自家的牛肉，哪里舍得呀，劳动力没了，生活水平就直线下降了。
现在的生活是最好的了，又现代化，又传承了古代的美食文化，这才能幸福吃上各种牛
肉。

d*r2014-02-20 08:02

5 楼

有专门讲 message server performance 的资料吗, 书，网站，blog，系统点那种。
我想知道主要怎样系统地 measure 一个 message server, 比如有哪些主要测试工具 (
jmeter, tsung 等等，他们的优劣), 主要需要测试好哪些 measurements (e.g.
messages/sec, connections/sec, kbits/sec ...)
message 可以是自定义的。 e.g. JSON over TCP, 甚至 UDP
也可以是 HTTP messages。其实一直没有定量研究和测试过 HTTP 跟自定义的简单
message 包比较起来，到底有多 heavy, 延迟高多少，处理能力要额外耗费多少。
琢磨着 build 这样一个 server，收发大量的 messages. 不是只针对 server hosts
端内网的，也便于从公网上收发 messages. 比如就当 HTTP server 或者 gaming
protocol server 用。
可以有 cluster 模式，可以堆机器 scale out 或者和 load balancing.
方便接入内存DB (e.g. Redis, memcache) 也是挺好的plus。
对这个问题非常感兴趣 (所以之前看到vert.x也觉得很有意思, 虽然它的 P2P message
bus 没有自带server)。
有没有专门讲这方面的书，网站，blog?
请本版的大牛们多指点呀。

d*u2014-02-20 08:02

6 楼

找合伙人开董事会，就可以了

b*e2014-02-20 08:02

7 楼

keng

n*r2014-02-20 08:02

8 楼

属实，古代是吃不到孜然牛肉，番茄牛腩等等的，梁山好汉敢吃，是因为他们是土匪
了

w*z2014-02-20 08:02

9 楼

看看Kafka.

【在 d*******r 的大作中提到】

: 有专门讲 message server performance 的资料吗, 书，网站，blog，系统点那种。
: 我想知道主要怎样系统地 measure 一个 message server, 比如有哪些主要测试工具 (
: jmeter, tsung 等等，他们的优劣), 主要需要测试好哪些 measurements (e.g.
: messages/sec, connections/sec, kbits/sec ...)
: message 可以是自定义的。 e.g. JSON over TCP, 甚至 UDP
: 也可以是 HTTP messages。其实一直没有定量研究和测试过 HTTP 跟自定义的简单
: message 包比较起来，到底有多 heavy, 延迟高多少，处理能力要额外耗费多少。
: 琢磨着 build 这样一个 server，收发大量的 messages. 不是只针对 server hosts
: 端内网的，也便于从公网上收发 messages. 比如就当 HTTP server 或者 gaming
: protocol server 用。

r*22014-02-20 08:02

10 楼

帮顶，另外问下楼主开corporation是否需要找律师，还是可以自己搞？

b*n2014-02-20 08:02

11 楼

有点小矛盾。。。
不想打交道。。。那怎么成bf啊？

【在 P*****a 的大作中提到】

: 太小气和斤斤计较，令人再也不想和其打交道。
: 做BF还是不错的

l*g2014-02-20 08:02

12 楼

呵呵，还是一样的
有钱人什么时候缺过肉吃

d*r2014-02-20 08:02

13 楼

之前看一下的

【在 w**z 的大作中提到】

: 看看Kafka.

n*g2014-02-20 08:02

14 楼

我就自己搞的,也是用的这里推荐的一个服务,叫做bizfilings的网站,很方便.

【在 r*********2 的大作中提到】

: 帮顶，另外问下楼主开corporation是否需要找律师，还是可以自己搞？

P*a2014-02-20 08:02

15 楼

也就是不喜欢和其做朋友
但是做BF还是不错的选择，对女友还是很投入的
做朋友总是被其算计，不爽

【在 b******n 的大作中提到】

: 有点小矛盾。。。
: 不想打交道。。。那怎么成bf啊？

d*n2014-02-20 08:02

16 楼

p*22014-02-20 08:02

17 楼

大牛给个summary?
我现在产生80M/S数据，他们就开始抱怨了。

【在 d*******r 的大作中提到】

: 之前看一下的

r*22014-02-20 08:02

18 楼

谢谢，我去看看，我主要身份比较尴尬，另外是和国内朋友合伙开

【在 n******g 的大作中提到】

:
: 我就自己搞的,也是用的这里推荐的一个服务,叫做bizfilings的网站,很方便.

m*i2014-02-20 08:02

19 楼

lol
感觉还是比较了解世情处事蛮有分寸的~~`

【在 P*****a 的大作中提到】

: 太小气和斤斤计较，令人再也不想和其打交道。
: 做BF还是不错的

n*r2014-02-20 08:02

20 楼

属实，古代是吃不到孜然牛肉，番茄牛腩等等的，梁山好汉敢吃，是因为他们是土匪
了

d*r2014-02-20 08:02

21 楼

我就是觉得kafka的特色是默认persistent写到硬盘吧，有用这个来做实时系统的吗？
比 fast accessing 肯定不如 Redis之类吧。
写到硬盘，又不像 C* 支持复杂的 query。总觉得用处有限。
当然我知道得太浅显了。还是请 wwzz 来说说吧。

【在 p*****2 的大作中提到】

:
: 大牛给个summary?
: 我现在产生80M/S数据，他们就开始抱怨了。

s*x2014-02-20 08:02

22 楼

呵呵，部分真理。天蝎男本性并不厚道。

【在 P*****a 的大作中提到】

: 太小气和斤斤计较，令人再也不想和其打交道。
: 做BF还是不错的

l*g2014-02-20 08:02

23 楼

呵呵，还是一样的
有钱人什么时候缺过肉吃

w*z2014-02-20 08:02

24 楼

实时可以用kafka +storm. 我觉得好处是 throughput 大，自动purge, 支持多个
consumer reading the same queue.， easy to scale.

【在 d*******r 的大作中提到】

: 我就是觉得kafka的特色是默认persistent写到硬盘吧，有用这个来做实时系统的吗？
: 比 fast accessing 肯定不如 Redis之类吧。
: 写到硬盘，又不像 C* 支持复杂的 query。总觉得用处有限。
: 当然我知道得太浅显了。还是请 wwzz 来说说吧。

h*x2014-02-20 08:02

25 楼

I would rather have them to be friends than anyone too close to me.

【在 P*****a 的大作中提到】

: 太小气和斤斤计较，令人再也不想和其打交道。
: 做BF还是不错的

p*22014-02-20 08:02

26 楼

看需求吧？有些需求要求latency很低。

【在 w**z 的大作中提到】

: 实时可以用kafka +storm. 我觉得好处是 throughput 大，自动purge, 支持多个
: consumer reading the same queue.， easy to scale.

h*x2014-02-20 08:02

27 楼

Cannot agree more.

【在 s**x 的大作中提到】

: 呵呵，部分真理。天蝎男本性并不厚道。

d*r2014-02-20 08:02

28 楼

二爷说的也是我想问的，比如想达到做游戏server(或者其他 interactive apps)的
latency的话，像kafka一样把 message 写到硬盘上，再从硬盘上读出来，能达到ms级
别的latency要求吗? 如果不能达到的话，难道还是得扔到 Redis 一样的内存 DB 里面?
kafka throughput 是牛，可能主要用途是 logging?

【在 w**z 的大作中提到】

: 实时可以用kafka +storm. 我觉得好处是 throughput 大，自动purge, 支持多个
: consumer reading the same queue.， easy to scale.

k*52014-02-20 08:02

29 楼

xixi

【在 s**x 的大作中提到】

: 呵呵，部分真理。天蝎男本性并不厚道。

d*r2014-02-20 08:02

30 楼

这么有意思的问题你们都不讨论，怎么满版都是 atoi 的水... -_-

M*o2014-02-20 08:02

31 楼

心胸狭窄的人, 做BF, 未必不计较了, 只是方式不同而已了。
一个人的心地，如果对别人和对亲近的人，相差悬殊，是要警惕的。

【在 P*****a 的大作中提到】

: 太小气和斤斤计较，令人再也不想和其打交道。
: 做BF还是不错的

z*e2014-02-20 08:02

32 楼

topic的scope太小
msg server本来就已经不那么常用
至少要在cluster以上才会用到
而且你还局限在performance
这个很多时候是一个动态变化的过程
今天a比b强，明天b版本升级了，反过来
你这让人怎么说？只能自己去试了

【在 d*******r 的大作中提到】

: 这么有意思的问题你们都不讨论，怎么满版都是 atoi 的水... -_-

M*o2014-02-20 08:02

33 楼

还好了, 你如果通情达理, 天蝎男最终也会讲道理, 你如果不是, 那可能未必厚道。

【在 s**x 的大作中提到】

: 呵呵，部分真理。天蝎男本性并不厚道。

d*r2014-02-20 08:02

34 楼

我是打算自己去测了
我的意思是总有些系统的方法论，来测试这些吧，
我问的就是这些系统的方法

【在 z****e 的大作中提到】

: topic的scope太小
: msg server本来就已经不那么常用
: 至少要在cluster以上才会用到
: 而且你还局限在performance
: 这个很多时候是一个动态变化的过程
: 今天a比b强，明天b版本升级了，反过来
: 你这让人怎么说？只能自己去试了

s*x2014-02-20 08:02

35 楼

呵呵，好久没见，欢迎回来。

【在 k********5 的大作中提到】

: xixi

d*r2014-02-20 08:02

36 楼

正在看 10M 那个帖子，里面很多干货。
http://www.mitbbs.com/article_t1/Programming/31330685_0_2.html
比如 cxu123 转的 10M 的帖子,
特别是 user space scheduling/protocol_stack 的东西，这几年还真接触过。
魏老师这一楼的帖子，给了个极简化的测试 message server performance 的标准:
=============================================
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏]
[举报] [ 28 ]
发信人: TeacherWei (TW), 信区: Programming
标题: Re: 10M persistent TCP connections
发信站: BBS 未名空间站 (Fri Feb 28 16:36:24 2014, 美东)
我说过了。去年11月第一贴就讲的清清楚楚。
其他的都是虚的。只有throughput是实实在在的。
号称同时连接是多少，每秒多少message都没意义。
俺们这行很简单，就是concurrent connection，messages per second，size of
message。然后告诉大家你一台server能handle多少throughput。
谁都知道，一个NIC的throughput是多少，10G/20G full duplex。然后你看看你能做到
多少。越接近极限越牛逼。
=============================================
那就是主要看:
concurrent connection (应该是long live，比如 long live TCP/HTTP)，
messages per second，size of message。
然后告诉大家你一台server能handle多少throughput。