这是一个创建于 2440 天前的主题，其中的信息可能已经有所发展或是发生改变。
用自带的 Http 写了一个简单 api 服务器，在一个简陋的 512Mvps 上跑到了每天 60 多万次调用.
系统用的 ubuntu 16.04 lts 没有任何优化
现在知道调整 socket limit 和 open file limit 优化
但是如何发现问题然后解决呢？而不是做了这些事情就可以避免。
比如读取系统日志分析问题？我该从哪里下手分析呢？
请求各位帮助
系统用的 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 不知道怎么回事视线全转移到语言上面了。
我想讨论的是随着请求量的增加如何调整系统参数，该从哪里下手。
“这不是很容易实现吗” 搞不懂和主题有什么关系
p.s
我只是提到了 GO 不知道怎么回事视线全转移到语言上面了。
我想讨论的是随着请求量的增加如何调整系统参数，该从哪里下手。
“这不是很容易实现吗” 搞不懂和主题有什么关系
 |
1
gamexg 2018-04-07 15:43:22 +08:00 via Android
go pprof
|
 |
2
msg7086 2018-04-07 15:44:44 +08:00  5
每秒不到 10 次，估计对 Go 来说就像挠痒痒。
|
 |
4
bottleimp 2018-04-07 17:25:45 +08:00 4
你说个支持不了每天 60 万次请求的语言吧.
|
 |
5
kefengong 2018-04-07 17:38:59 +08:00 via Android
带来了什么问题？
|
 |
6
cloverstd 2018-04-07 17:52:54 +08:00
pprof 和火焰图
|
 |
7
hiboshi 2018-04-07 17:54:12 +08:00
我感觉这点量 lnmp 架构也没问题
|
 |
8
webjin1 2018-04-07 18:07:54 +08:00 via Android
rust 更屌
|
 |
9
pymumu 2018-04-07 18:39:20 +08:00
我看成每秒 60 万了，每天 60 万，也太少了。
|
 |
10
neoblackcap 2018-04-07 19:36:08 +08:00
哪怕是 8 个小时，也是一秒 21 个请求，我想我用 Python 都能实现这样的水平
|
 |
11
boyxupers 2018-04-07 19:44:30 +08:00 via iPhone
你 golang 党水平不错…
|
 |
12
binbinyouliiii 2018-04-07 19:47:18 +08:00
“ Go 的性能真是高到爆炸”这句话很明显的就是夸 Go 啊，可不是“只是提到了 Go ”
|
 |
13
kslr OP |
 |
15
widewing 2018-04-07 19:54:00 +08:00 via Android
问题是每秒十来个请求还没到需要调优的地步吧。。
|
|
16
kslr OP @widewing #15 以快速增长的业务抛出来论点，现在的请求是这几个星期增长的，并且一马奔腾。迟早都要面对这个问题，所以现在来讨论一下。
不过看来凉了，我还是多研究文档吧，这里还是灌水生活琐事居多。 |
|
17
binbinyouliiii 2018-04-07 19:57:21 +08:00
@kslr #13 这么夸张的修辞手法，引不起战才不正常。所以楼主你还没认识到问题所在吗？
|
 |
18
lights 2018-04-07 20:09:52 +08:00 via iPhone
原谅我没 get 到楼主的问题在哪里
|
 |
19
cholerae 2018-04-07 20:11:24 +08:00
还以为是 60w qps。。。
|
 |
20
goodryb 2018-04-07 20:21:28 +08:00
从楼主的标题以及描述来看，楼主是个新手 go 程序员吧
性能好轮不到 go 称第一 请求频率一般是 QPS，而不是每天 xx 万 |
 |
21
carlclone 2018-04-07 20:21:46 +08:00
每天。。。还有以天为单位的吗
|
 |
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 一类的，修改可能造成内核的不稳定。 随着业务量的增加，多搞几台机器更保险。随便修改内核的东西，危险性很大。 |
 |
23
pathbox 2018-04-07 20:53:24 +08:00 via iPhone
标题有点浮夸，还是要低调
|
 |
24
murmur 2018-04-07 20:59:19 +08:00
每天 60 万次 按照 12 个小时高峰跑的话 就是一小时 5 万次 一秒 10-20 次 别说 go 了 稍微好的设计跑带 SQL 的 CURD 都做的到吧
|
 |
25
Dart 2018-04-07 21:05:22 +08:00 via Android
我的 ruby python php 看起来也性能好
|
 |
26
Kabie 2018-04-07 21:45:15 +08:00
...最好还是说峰值的 QPS。。。不然根本体现不出“性能搞到爆炸”…………
另外你以前用的都是啥才会觉得这个性能就爆炸了………… |
 |
27
denggj28 2018-04-07 22:02:35 +08:00
话说到了 1000qps 再说说调优吧
|
 |
28
bolide2005 2018-04-07 22:43:50 +08:00
呃，不是大家不配合，一方面你问的问题和 golang 本身没关系，另一方面，我估摸着大家都没太清楚你到底在问什么？
试着给个建议，自己写的服务如果可靠性不是特别有把握的话，前面可以挂一个更加成熟的 server，比如 nginx，或者如果你用 aws 的话就放个 elb，阿里云我记得也有类似的负载均衡器，这些一般都有日志或者统计信息，假设这些前置的 server 不出问题，那么就能正常记录你自己写的 server 的错误信息，然后再根据错误信息做优化，是内存还是文件描述符或者别的什么原因，想一劳永逸除非服务特别简单，访问量很低，不然还是需要留有足够的日志信息 |
 |
29
lfzyx 2018-04-07 23:12:05 +08:00
|
 |
30
tempdban 2018-04-08 00:39:33 +08:00 via Android 1
啥叫性能优化？
tlb miss 多了就上巨页 cache miss 多了就减少上下文切换 兄弟你开个 open file limit 就觉得发现了一片天么 这都不叫调优啊兄弟。 |
 |
31
moult 2018-04-08 00:45:26 +08:00 via iPhone
laravel：吓我一跳
|
 |
32
ql562482472 2018-04-08 10:04:41 +08:00
每天 60w，等你什么时候达到了 50QPS 再来讨论优化吧，遇到了才知道是什么问题
|
|
33
Dart 2018-04-08 10:39:35 +08:00 via Android
发现一只菜鸟
|
 |
34
junweiyang 2018-04-08 11:00:41 +08:00
我们公司的 golang 服务，每台机器的 qps 是 500 ！
|
 |
35
Felldeadbird 2018-04-08 11:06:20 +08:00
我以为楼主说每秒 60W。建议楼主补充一下帖子关于一天 60W 内， 峰值期间每秒的请求数。这样才可以体验到 GO 性能真的很爽。
|
 |
36
vjnjc 2018-04-08 12:41:40 +08:00
我也以为是好几万的 qps。。。
|
|
37
msg7086 2018-04-08 12:51:41 +08:00
@lfzyx 每秒本来就是说的平均，大量用户集中在某一时段去调用 API 也是你一厢情愿的想法，具体分布需要楼主自己提供。如果是面向服务器的监控 API 呢，服务器会白天多调用晚上少调用吗？如果面向的是全世界的人呢，调用分布不也平均吗。楼主只提供了 24 小时的访问量，除以 24 小时得到每秒访问量算什么错误的想法。
就算我们退一步，楼主的 API 一天只跑一个小时，剩下 23 小时打酱油，那就是一个小时 60 万，也只是一秒 170 个请求，不还是轻轻松松。 |
 |
38
WinMain 2018-04-08 17:22:51 +08:00
看来大公司喜欢招有高并发后台经验的人员是有道理的，哈哈哈。
|
Select Language