V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
alexapollo
V2EX  ›  程序员

后台程序开发:性能的极限是什么?

  •  
  •   alexapollo ·
    geekan · 2016-01-14 22:52:41 +08:00 · 6851 次点击
    这是一个创建于 3218 天前的主题,其中的信息可能已经有所发展或是发生改变。

    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 很轻松
    30 条回复    2016-01-15 21:14:05 +08:00
    alexapollo
        1
    alexapollo  
    OP
       2016-01-14 23:22:30 +08:00
    看来这个标题起的很不好……
    应该起『性能提升的 16 个法则』?
    zongwan
        2
    zongwan  
       2016-01-14 23:23:36 +08:00
    小米 预约抢购 需要你..
    提供 C 10M 的 DDOS 攻击小米服务器
    alexapollo
        3
    alexapollo  
    OP
       2016-01-15 00:12:11 +08:00
    @zongwan 还别说…… C10M 做 DDOS 还真最合适
    jedihy
        4
    jedihy  
       2016-01-15 00:56:44 +08:00
    Good ! 收藏了!!!!!!!!
    k9982874
        5
    k9982874  
       2016-01-15 01:09:26 +08:00 via iPhone   ❤️ 2
    准备好啃干货 点开一看就几行字 一股脱了裤子就给我看这个的感觉
    xiaocsl
        6
    xiaocsl  
       2016-01-15 03:54:48 +08:00
    帖子发了两个网址
    第一个 anwcl.com 的网址 网页用了什么黑科技,
    我等会要专门开个帖子.问一下.太厉害了,直接导致显示器(电视)黑屏..
    dcoder
        7
    dcoder  
       2016-01-15 04:02:48 +08:00
    干货,收藏了
    loading
        8
    loading  
       2016-01-15 06:56:11 +08:00 via iPhone
    就几行字…楼主,不要随意消耗自己在 V2EX 的形象~
    mengzhuo
        9
    mengzhuo  
       2016-01-15 07:51:29 +08:00
    @k9982874

    同意啊…… LZ 你这坑得还不如 CloudFlare 随便拖出来的一篇技术博客
    FifiLyu
        10
    FifiLyu  
       2016-01-15 09:10:32 +08:00
    Archlinux 已经推送更新源,修复这个 BUG 了。真快。
    alexapollo
        11
    alexapollo  
    OP
       2016-01-15 09:51:13 +08:00
    @k9982874
    @loading
    @mengzhuo
    其实性能确实是几行字就可以讲完了
    C10M 的关键点:更少的内存操作、更少的上下文切换
    后台性能调优的关键工具: perf+flamegraph
    完了。。。

    想看文笔的还是去看技术博文吧,“干货”有时候寥寥几句话就够了。。
    alexapollo
        12
    alexapollo  
    OP
       2016-01-15 09:56:34 +08:00
    几位用手机看的,可以看下 prezi ,里面写的多
    Andiry
        13
    Andiry  
       2016-01-15 09:56:34 +08:00
    @alexapollo 为什么是更少的内存操作,难道不是更少的网络 /磁盘 IO 么
    louk78
        14
    louk78  
       2016-01-15 09:58:20 +08:00
    更少的内存操作、更少的上下文切换
    alexapollo
        15
    alexapollo  
    OP
       2016-01-15 10:07:52 +08:00
    @Andiry C10K 的难点是 IO , C10M 的不是
    C10M 的主要难点是内核做了太多,已经不堪重负
    零拷贝可以解决一点问题,在不改变内核的运行模式下提升少许的性能
    更彻底的解决方法是把内核的一部分工作剥离出来, offload 到用户态
    outfocontrol
        16
    outfocontrol  
       2016-01-15 10:12:29 +08:00
    博文标题和内容不太符啊
    firefox12
        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 没有什么意义,更大的瓶颈根本不在这里。更多只是一个理论值。
    alexapollo
        18
    alexapollo  
    OP
       2016-01-15 10:25:36 +08:00
    @firefox12 是的, C10M 还有它自己的问题,但值得指出的是,它的场景并不通常,相当于把整体的网络 IO 瓶颈抹除了,把问题简化到了内存和 CPU 的二元上。(纯粹的长连接问题于它而言没有多大意义)

    而且,到了这种规模,才会有 700 和 70 的区别。
    业务量级是万台的前提下,成本早已过亿,节省 10%成本也已经非常可观。
    alexapollo
        19
    alexapollo  
    OP
       2016-01-15 10:27:18 +08:00
    @firefox12 注意,这里讲的 C10M 指的是每秒 10M 包的能力,而非 10M 长连接,语境稍微有点不同。
    10M 长连接只要有合适的机器就可以达到。
    Andiry
        20
    Andiry  
       2016-01-15 10:56:50 +08:00
    @alexapollo 你说的这些在你的链接里完全没体现出来啊。那个 Prezi 里面清清楚楚有一页写着“更少的网络 /磁盘 IO ,更多的内存 IO ”,也没提到更少的上下文切换。总而言之,光有结论,没有数据支撑,谁知道你提到的这些因素里面哪些更重要呢?

    举个简单的例子,现在的 CPU 执行用户态到内核态的切换只需要 100ns 不到。那么上下文切换在你的系统里到底占了多少 overhead ?把工作移到用户态可以提升多少性能?系统的瓶颈是在这里吗?还是在你所说的数据结构?还是在粗粒度锁? cache pollution 对系统性能有多大影响?无锁结构减少了锁争用但也带来了其他的问题和 overhead ,这些有量化比较过吗?

    当然我相信你做的东西还是很有意思的,只不过写的这么简略对别人的帮助太少。
    alexapollo
        21
    alexapollo  
    OP
       2016-01-15 11:48:55 +08:00 via iPhone
    @Andiry 如果没有引申到 C10M ,我觉得探讨这些是没有必要的。。
    操作系统底层的计算、存储、网络都有很值得优化的点,但对于大部分后台开发者来说,反而是希望能屏蔽掉的底层细节。
    我觉得你的回复很有道理,但我比较喜欢一个观念:尽可能提供最需要的信息。(换而言之:懒)相信你也见过来源社区那些无穷无尽的文档,令人厌烦,尽可能的简单才是美。
    楼里的同学们,你们可以都试试上面提到的调优组合。
    这东西传播开了会成为业界标准的。。
    Andiry
        22
    Andiry  
       2016-01-15 12:12:16 +08:00
    @alexapollo 你难道不是在讨论 C10M 么,怎么又没有引申到了

    后台开发者还要屏蔽掉这些细节,那我很好奇后台开发者每天在开发些什么东西,接口吗?
    至于这些组合,都是老生常谈,也没什么新鲜的啊,或者说早就成为业界标准了。 cache 争用,数据结构,细粒度锁,无锁化,这些不说我也知道。 Bypassing kernel 也不是什么新奇东西, RDMA 早就这么做了,最近几年也有一堆论文在讨论这些东西。
    alexapollo
        23
    alexapollo  
    OP
       2016-01-15 13:23:04 +08:00 via iPhone
    @Andiry
    1. C10M 与前文的讨论无关
    2. 每个后台开发者都需要很清楚内核吗,是否标准太高了?是否可以做个调查,看看所有 V 友里同时清楚后台(这些业界标准)和内核的有多少?
    3. 组合指的是 perf+flamegraph ,我打赌你没用过
    alexapollo
        24
    alexapollo  
    OP
       2016-01-15 13:31:18 +08:00 via iPhone
    @Andiry 后台开发与内核开发是两码事,关注点是完全不同的
    Andiry
        25
    Andiry  
       2016-01-15 13:41:34 +08:00
    @alexapollo
    1. 我还以为你整篇文章都在讨论 C10M 的优化呢
    2. 这个倒是。
    3. 你的文章里根本没提 perf+flamegraph ,谁知道你说的组合是啥。另外我还真用过,不知道你哪来信心打这个赌。。。
    xpol
        26
    xpol  
       2016-01-15 14:08:56 +08:00
    标题党!
    读完之后完全没有回答标题提的问题。
    alexapollo
        27
    alexapollo  
    OP
       2016-01-15 14:18:21 +08:00
    @Andiry 不错哟,这个组合在两个公司都是我引入的,还没见非我宣传之外的人用过。。
    alexapollo
        28
    alexapollo  
    OP
       2016-01-15 14:46:43 +08:00
    @outfocontrol
    @xpol
    两位,看下补充是否满意
    xpol
        29
    xpol  
       2016-01-15 16:17:30 +08:00
    pzhjie
        30
    pzhjie  
       2016-01-15 21:14:05 +08:00
    看了你的博客很受教,谢谢,希望我也能进腾讯
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1079 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 19:51 · PVG 03:51 · LAX 11:51 · JFK 14:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.