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

[kslr]

用自带的 Http 写了一个简单 api 服务器，在一个简陋的 512Mvps 上跑到了每天 60 多万次调用.
系统用的 ubuntu 16.04 lts 没有任何优化
现在知道调整 socket limit 和 open file limit 优化

但是如何发现问题然后解决呢？而不是做了这些事情就可以避免。
比如读取系统日志分析问题？我该从哪里下手分析呢？
请求各位帮助

[carlclone]

每天。。。还有以天为单位的吗

[fuxiaohei]

“现在知道调整 socket limit 和 open file limit 优化”

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

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

随着业务量的增加，多搞几台机器更保险。随便修改内核的东西，危险性很大。

[pathbox]

标题有点浮夸，还是要低调

[murmur]

每天 60 万次 按照 12 个小时高峰跑的话 就是一小时 5 万次 一秒 10-20 次 别说 go 了 稍微好的设计跑带 SQL 的 CURD 都做的到吧

[Dart]

我的 ruby python php 看起来也性能好

[Kabie]

...最好还是说峰值的 QPS。。。不然根本体现不出“性能搞到爆炸”…………

另外你以前用的都是啥才会觉得这个性能就爆炸了…………

[denggj28]

话说到了 1000qps 再说说调优吧

[bolide2005]

呃，不是大家不配合，一方面你问的问题和 golang 本身没关系，另一方面，我估摸着大家都没太清楚你到底在问什么？

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

[lfzyx]

@msg7086
@bottleimp
@pymumu
@neoblackcap

按照 24 小时来获取每秒值明显是个错误的想法，大量的用户会集中在某一个时段去调用 api，而不是分散在不同时段。

[tempdban]

啥叫性能优化？
tlb miss 多了就上巨页
cache miss 多了就减少上下文切换
兄弟你开个 open file limit 就觉得发现了一片天么
这都不叫调优啊兄弟。

[moult]

laravel：吓我一跳

[ql562482472]

每天 60w，等你什么时候达到了 50QPS 再来讨论优化吧，遇到了才知道是什么问题

[Dart]

发现一只菜鸟

[junweiyang]

我们公司的 golang 服务，每台机器的 qps 是 500 ！

[Felldeadbird]

我以为楼主说每秒 60W。建议楼主补充一下帖子关于一天 60W 内， 峰值期间每秒的请求数。这样才可以体验到 GO 性能真的很爽。

[vjnjc]

我也以为是好几万的 qps。。。

[msg7086]

@lfzyx 每秒本来就是说的平均，大量用户集中在某一时段去调用 API 也是你一厢情愿的想法，具体分布需要楼主自己提供。如果是面向服务器的监控 API 呢，服务器会白天多调用晚上少调用吗？如果面向的是全世界的人呢，调用分布不也平均吗。楼主只提供了 24 小时的访问量，除以 24 小时得到每秒访问量算什么错误的想法。

就算我们退一步，楼主的 API 一天只跑一个小时，剩下 23 小时打酱油，那就是一个小时 60 万，也只是一秒 170 个请求，不还是轻轻松松。

[WinMain]

看来大公司喜欢招有高并发后台经验的人员是有道理的，哈哈哈。