这是一个创建于 3273 天前的主题，其中的信息可能已经有所发展或是发生改变。
Background
笔者（俺）
* 之前参与过国际顶级的开源社区
* 对内核进行过深度定制（使用本文提到的技术）
* 浸淫 C10M 已久
正文
传送门：后台程序开发：性能的极限是什么？
prezi ： https://prezi.com/3p17hwgqpqvs/presentation/
去年写的 prezi ，到现在其中的知识仍然完全适用。
欢迎点评交流~
第 1 条附言 · 2016-01-15 14:45:45 +08:00
为了防止做了标题党，特意补充一下
性能的极限在于“平衡”：
- 计算、存储、网络，三者要做到平衡。
- 大部分计算、网络的瓶颈都可以用增大存储来解决，但要有度。
大部分的性能 state-of-art （一台普通 4 核服务器）：
- 这台服务器的最大报文数在~50w/s （和服务器年份有关）
- 通过 C10M （ dpdk 、 netmap ）等技术可以达到 1kw+/s 的最大报文数，然而目前并没有太多卵用
- thrift 、 grpc 这类框架，一个业务逻辑较轻的服务 TPS 大概能到上万（后台服务标准）
- 分词、分类（ SVM 等），文本处理等 CPU 密集型的业务， TPS 大多只能到百级
- 特殊的：只要内存足够，长连接服务上 C10M 很轻松
 |
1
alexapollo OP 看来这个标题起的很不好……
应该起『性能提升的 16 个法则』？ |
 |
2
zongwan 2016-01-14 23:23:36 +08:00
小米 预约抢购 需要你..
提供 C 10M 的 DDOS 攻击小米服务器 |
|
3
alexapollo OP @zongwan 还别说…… C10M 做 DDOS 还真最合适
|
 |
4
jedihy 2016-01-15 00:56:44 +08:00
Good ！ 收藏了！！！！！！！！
|
 |
5
k9982874 2016-01-15 01:09:26 +08:00 via iPhone  2
准备好啃干货 点开一看就几行字 一股脱了裤子就给我看这个的感觉
|
 |
6
xiaocsl 2016-01-15 03:54:48 +08:00
|
 |
7
dcoder 2016-01-15 04:02:48 +08:00
干货，收藏了
|
 |
8
loading 2016-01-15 06:56:11 +08:00 via iPhone
就几行字…楼主，不要随意消耗自己在 V2EX 的形象~
|
 |
10
FifiLyu 2016-01-15 09:10:32 +08:00
Archlinux 已经推送更新源，修复这个 BUG 了。真快。
|
|
11
alexapollo OP |
|
12
alexapollo OP 几位用手机看的，可以看下 prezi ，里面写的多
|
 |
13
Andiry 2016-01-15 09:56:34 +08:00
@alexapollo 为什么是更少的内存操作，难道不是更少的网络 /磁盘 IO 么
|
 |
14
louk78 2016-01-15 09:58:20 +08:00
更少的内存操作、更少的上下文切换
|
|
15
alexapollo OP @Andiry C10K 的难点是 IO ， C10M 的不是
C10M 的主要难点是内核做了太多，已经不堪重负 零拷贝可以解决一点问题，在不改变内核的运行模式下提升少许的性能 更彻底的解决方法是把内核的一部分工作剥离出来， offload 到用户态 |
 |
16
outfocontrol 2016-01-15 10:12:29 +08:00
博文标题和内容不太符啊
|
 |
17
firefox12 2016-01-15 10:13:00 +08:00
这种没有硬件环境配置，业务要求特点的 测试条件，测试方法，以及最终测试结果的 C10M 文章是没有意义。
后端业务 是那种业务， CPU 的负载有多重，简单的 echo 和要进行大量计算的业务完全是 2 个概念的程序。说到 c10M, 那么需要搞清楚 每个连接上的业务请求频率和大小，这点对性能的影响也是数量级别的， 业务本身的特点 也会完全影响性能，是大量短连接 不断的断开连接，还是长连接，这在链接对象的重用和侧重点上也是完全不一样的。 既然已经做到 c10M ，想必你也知道原生的 TCP ／ IP 堆栈无法良好的处理网络，需要改底层，但是我觉得在这方面继续深究下去，不如在对水平可扩展性的方面加以研究，一套业务层可以快速水平扩展的系统意义更大。 垂直扩展，到 C1M C2M ，的时候 CPU Mem 基本上负载已经很高。 以服务业务对象来看，如果到 tx 这样 7 亿用户 c1M, 也只需要 700 台主机就可以完全接受服务。当然你也知道在那种规模 700 和 70 没有什么意义，更大的瓶颈根本不在这里。更多只是一个理论值。 |
|
18
alexapollo OP @firefox12 是的， C10M 还有它自己的问题，但值得指出的是，它的场景并不通常，相当于把整体的网络 IO 瓶颈抹除了，把问题简化到了内存和 CPU 的二元上。（纯粹的长连接问题于它而言没有多大意义）
而且，到了这种规模，才会有 700 和 70 的区别。 业务量级是万台的前提下，成本早已过亿，节省 10%成本也已经非常可观。 |
|
19
alexapollo OP @firefox12 注意，这里讲的 C10M 指的是每秒 10M 包的能力，而非 10M 长连接，语境稍微有点不同。
10M 长连接只要有合适的机器就可以达到。 |
|
20
Andiry 2016-01-15 10:56:50 +08:00
@alexapollo 你说的这些在你的链接里完全没体现出来啊。那个 Prezi 里面清清楚楚有一页写着“更少的网络 /磁盘 IO ，更多的内存 IO ”，也没提到更少的上下文切换。总而言之，光有结论，没有数据支撑，谁知道你提到的这些因素里面哪些更重要呢？
举个简单的例子，现在的 CPU 执行用户态到内核态的切换只需要 100ns 不到。那么上下文切换在你的系统里到底占了多少 overhead ？把工作移到用户态可以提升多少性能？系统的瓶颈是在这里吗？还是在你所说的数据结构？还是在粗粒度锁？ cache pollution 对系统性能有多大影响？无锁结构减少了锁争用但也带来了其他的问题和 overhead ，这些有量化比较过吗？ 当然我相信你做的东西还是很有意思的，只不过写的这么简略对别人的帮助太少。 |
|
21
alexapollo OP @Andiry 如果没有引申到 C10M ，我觉得探讨这些是没有必要的。。
操作系统底层的计算、存储、网络都有很值得优化的点，但对于大部分后台开发者来说，反而是希望能屏蔽掉的底层细节。 我觉得你的回复很有道理，但我比较喜欢一个观念：尽可能提供最需要的信息。（换而言之：懒）相信你也见过来源社区那些无穷无尽的文档，令人厌烦，尽可能的简单才是美。 楼里的同学们，你们可以都试试上面提到的调优组合。 这东西传播开了会成为业界标准的。。 |
|
22
Andiry 2016-01-15 12:12:16 +08:00
@alexapollo 你难道不是在讨论 C10M 么，怎么又没有引申到了
后台开发者还要屏蔽掉这些细节，那我很好奇后台开发者每天在开发些什么东西，接口吗？ 至于这些组合，都是老生常谈，也没什么新鲜的啊，或者说早就成为业界标准了。 cache 争用，数据结构，细粒度锁，无锁化，这些不说我也知道。 Bypassing kernel 也不是什么新奇东西， RDMA 早就这么做了，最近几年也有一堆论文在讨论这些东西。 |
|
23
alexapollo OP @Andiry
1. C10M 与前文的讨论无关 2. 每个后台开发者都需要很清楚内核吗，是否标准太高了？是否可以做个调查，看看所有 V 友里同时清楚后台（这些业界标准）和内核的有多少？ 3. 组合指的是 perf+flamegraph ，我打赌你没用过 |
|
24
alexapollo OP @Andiry 后台开发与内核开发是两码事，关注点是完全不同的
|
|
25
Andiry 2016-01-15 13:41:34 +08:00
@alexapollo
1. 我还以为你整篇文章都在讨论 C10M 的优化呢 2. 这个倒是。 3. 你的文章里根本没提 perf+flamegraph ，谁知道你说的组合是啥。另外我还真用过，不知道你哪来信心打这个赌。。。 |
 |
26
xpol 2016-01-15 14:08:56 +08:00
标题党！
读完之后完全没有回答标题提的问题。 |
|
27
alexapollo OP @Andiry 不错哟，这个组合在两个公司都是我引入的，还没见非我宣传之外的人用过。。
|
|
28
alexapollo OP |
|
29
xpol 2016-01-15 16:17:30 +08:00
@alexapollo :)
|
 |
30
pzhjie 2016-01-15 21:14:05 +08:00
看了你的博客很受教，谢谢，希望我也能进腾讯
|
Select Language