V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
kslr
V2EX  ›  Go 编程语言

Go 的性能真是高到爆炸,不过快速增长也带来了一些问题

  •  
  •   kslr · 2018-04-07 15:37:35 +08:00 · 9165 次点击
    这是一个创建于 2423 天前的主题,其中的信息可能已经有所发展或是发生改变。
    用自带的 Http 写了一个简单 api 服务器,在一个简陋的 512Mvps 上跑到了每天 60 多万次调用.
    系统用的 ubuntu 16.04 lts 没有任何优化
    现在知道调整 socket limit 和 open file limit 优化

    但是如何发现问题然后解决呢?而不是做了这些事情就可以避免。
    比如读取系统日志分析问题?我该从哪里下手分析呢?
    请求各位帮助
    第 1 条附言  ·  2018-04-07 17:32:14 +08:00
    没有帮助一味捧 GO 的就没必要回复了
    第 2 条附言  ·  2018-04-07 18:03:06 +08:00
    已经找到问题了,CloudFlare 部分城市故障

    p.s
    我只是提到了 GO 不知道怎么回事视线全转移到语言上面了。
    我想讨论的是随着请求量的增加如何调整系统参数,该从哪里下手。
    “这不是很容易实现吗” 搞不懂和主题有什么关系
    38 条回复    2018-04-08 17:22:51 +08:00
    gamexg
        1
    gamexg  
       2018-04-07 15:43:22 +08:00 via Android
    go pprof
    msg7086
        2
    msg7086  
       2018-04-07 15:44:44 +08:00   ❤️ 5
    每秒不到 10 次,估计对 Go 来说就像挠痒痒。
    kslr
        3
    kslr  
    OP
       2018-04-07 15:45:56 +08:00
    @gamexg #1
    @msg7086 #2 我指的是 linux 上面的 socket 等等
    bottleimp
        4
    bottleimp  
       2018-04-07 17:25:45 +08:00   ❤️ 4
    你说个支持不了每天 60 万次请求的语言吧.
    kefengong
        5
    kefengong  
       2018-04-07 17:38:59 +08:00 via Android
    带来了什么问题?
    cloverstd
        6
    cloverstd  
       2018-04-07 17:52:54 +08:00
    pprof 和火焰图
    hiboshi
        7
    hiboshi  
       2018-04-07 17:54:12 +08:00
    我感觉这点量 lnmp 架构也没问题
    webjin1
        8
    webjin1  
       2018-04-07 18:07:54 +08:00 via Android
    rust 更屌
    pymumu
        9
    pymumu  
       2018-04-07 18:39:20 +08:00
    我看成每秒 60 万了,每天 60 万,也太少了。
    neoblackcap
        10
    neoblackcap  
       2018-04-07 19:36:08 +08:00
    哪怕是 8 个小时,也是一秒 21 个请求,我想我用 Python 都能实现这样的水平
    boyxupers
        11
    boyxupers  
       2018-04-07 19:44:30 +08:00 via iPhone
    你 golang 党水平不错…
    binbinyouliiii
        12
    binbinyouliiii  
       2018-04-07 19:47:18 +08:00
    “ Go 的性能真是高到爆炸”这句话很明显的就是夸 Go 啊,可不是“只是提到了 Go ”
    kslr
        13
    kslr  
    OP
       2018-04-07 19:50:13 +08:00
    @binbinyouliiii #12
    @boyxupers #11 所以我就搞不懂了,好端端的帖子,最后变成了优越感了。没有人愿意坐下来讨论
    stzz
        14
    stzz  
       2018-04-07 19:52:20 +08:00 via Android
    @kslr 你的标题内容把 go 拿掉,他们就会和你好好讨论问题了。
    widewing
        15
    widewing  
       2018-04-07 19:54:00 +08:00 via Android
    问题是每秒十来个请求还没到需要调优的地步吧。。
    kslr
        16
    kslr  
    OP
       2018-04-07 19:56:53 +08:00
    @widewing #15 以快速增长的业务抛出来论点,现在的请求是这几个星期增长的,并且一马奔腾。迟早都要面对这个问题,所以现在来讨论一下。
    不过看来凉了,我还是多研究文档吧,这里还是灌水生活琐事居多。
    binbinyouliiii
        17
    binbinyouliiii  
       2018-04-07 19:57:21 +08:00
    @kslr #13 这么夸张的修辞手法,引不起战才不正常。所以楼主你还没认识到问题所在吗?
    lights
        18
    lights  
       2018-04-07 20:09:52 +08:00 via iPhone
    原谅我没 get 到楼主的问题在哪里
    cholerae
        19
    cholerae  
       2018-04-07 20:11:24 +08:00
    还以为是 60w qps。。。
    goodryb
        20
    goodryb  
       2018-04-07 20:21:28 +08:00
    从楼主的标题以及描述来看,楼主是个新手 go 程序员吧

    性能好轮不到 go 称第一
    请求频率一般是 QPS,而不是每天 xx 万
    carlclone
        21
    carlclone  
       2018-04-07 20:21:46 +08:00
    每天。。。还有以天为单位的吗
    fuxiaohei
        22
    fuxiaohei  
       2018-04-07 20:40:51 +08:00   ❤️ 1
    “现在知道调整 socket limit 和 open file limit 优化”

    其实我觉得你理解的优化和一般做的 linux 优化不是一回事。ulimit 和 open file 这些都是基本系统配置问题,修改了就可以了。

    更多的优化是修改系统内核参数,比如 /etc/sysctl.conf 里的 net.core 和 net.ipv4 一类的,修改可能造成内核的不稳定。

    随着业务量的增加,多搞几台机器更保险。随便修改内核的东西,危险性很大。
    pathbox
        23
    pathbox  
       2018-04-07 20:53:24 +08:00 via iPhone
    标题有点浮夸,还是要低调
    murmur
        24
    murmur  
       2018-04-07 20:59:19 +08:00
    每天 60 万次 按照 12 个小时高峰跑的话 就是一小时 5 万次 一秒 10-20 次 别说 go 了 稍微好的设计跑带 SQL 的 CURD 都做的到吧
    Dart
        25
    Dart  
       2018-04-07 21:05:22 +08:00 via Android
    我的 ruby python php 看起来也性能好
    Kabie
        26
    Kabie  
       2018-04-07 21:45:15 +08:00
    ...最好还是说峰值的 QPS。。。不然根本体现不出“性能搞到爆炸”…………

    另外你以前用的都是啥才会觉得这个性能就爆炸了…………
    denggj28
        27
    denggj28  
       2018-04-07 22:02:35 +08:00
    话说到了 1000qps 再说说调优吧
    bolide2005
        28
    bolide2005  
       2018-04-07 22:43:50 +08:00
    呃,不是大家不配合,一方面你问的问题和 golang 本身没关系,另一方面,我估摸着大家都没太清楚你到底在问什么?

    试着给个建议,自己写的服务如果可靠性不是特别有把握的话,前面可以挂一个更加成熟的 server,比如 nginx,或者如果你用 aws 的话就放个 elb,阿里云我记得也有类似的负载均衡器,这些一般都有日志或者统计信息,假设这些前置的 server 不出问题,那么就能正常记录你自己写的 server 的错误信息,然后再根据错误信息做优化,是内存还是文件描述符或者别的什么原因,想一劳永逸除非服务特别简单,访问量很低,不然还是需要留有足够的日志信息
    lfzyx
        29
    lfzyx  
       2018-04-07 23:12:05 +08:00
    @msg7086
    @bottleimp
    @pymumu
    @neoblackcap

    按照 24 小时来获取每秒值明显是个错误的想法,大量的用户会集中在某一个时段去调用 api,而不是分散在不同时段。
    tempdban
        30
    tempdban  
       2018-04-08 00:39:33 +08:00 via Android   ❤️ 1
    啥叫性能优化?
    tlb miss 多了就上巨页
    cache miss 多了就减少上下文切换
    兄弟你开个 open file limit 就觉得发现了一片天么
    这都不叫调优啊兄弟。
    moult
        31
    moult  
       2018-04-08 00:45:26 +08:00 via iPhone
    laravel:吓我一跳
    ql562482472
        32
    ql562482472  
       2018-04-08 10:04:41 +08:00
    每天 60w,等你什么时候达到了 50QPS 再来讨论优化吧,遇到了才知道是什么问题
    Dart
        33
    Dart  
       2018-04-08 10:39:35 +08:00 via Android
    发现一只菜鸟
    junweiyang
        34
    junweiyang  
       2018-04-08 11:00:41 +08:00
    我们公司的 golang 服务,每台机器的 qps 是 500 !
    Felldeadbird
        35
    Felldeadbird  
       2018-04-08 11:06:20 +08:00
    我以为楼主说每秒 60W。建议楼主补充一下帖子关于一天 60W 内, 峰值期间每秒的请求数。这样才可以体验到 GO 性能真的很爽。
    vjnjc
        36
    vjnjc  
       2018-04-08 12:41:40 +08:00
    我也以为是好几万的 qps。。。
    msg7086
        37
    msg7086  
       2018-04-08 12:51:41 +08:00
    @lfzyx 每秒本来就是说的平均,大量用户集中在某一时段去调用 API 也是你一厢情愿的想法,具体分布需要楼主自己提供。如果是面向服务器的监控 API 呢,服务器会白天多调用晚上少调用吗?如果面向的是全世界的人呢,调用分布不也平均吗。楼主只提供了 24 小时的访问量,除以 24 小时得到每秒访问量算什么错误的想法。

    就算我们退一步,楼主的 API 一天只跑一个小时,剩下 23 小时打酱油,那就是一个小时 60 万,也只是一秒 170 个请求,不还是轻轻松松。
    WinMain
        38
    WinMain  
       2018-04-08 17:22:51 +08:00
    看来大公司喜欢招有高并发后台经验的人员是有道理的,哈哈哈。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4526 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 04:07 · PVG 12:07 · LAX 20:07 · JFK 23:07
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.