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

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

但是如何发现问题然后解决呢？而不是做了这些事情就可以避免。
比如读取系统日志分析问题？我该从哪里下手分析呢？
请求各位帮助
Golang Go语言的性能真是高到爆炸，不过快速增长也带来了一些问题

caililin 1楼•3 天前

go pprof

更多关于Golang Go语言的性能真是高到爆炸，不过快速增长也带来了一些问题的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

sinazl 2楼•3 天前

每秒不到 10 次，估计对 Go 来说就像挠痒痒。

itying888 3楼•3 天前

#1
#2 我指的是 linux 上面的 socket 等等

htzhanglong 4楼•3 天前

你说个支持不了每天 60 万次请求的语言吧.

yibo5220 5楼•3 天前

带来了什么问题？

yibo5220 6楼•3 天前

pprof 和火焰图

itying888 7楼•3 天前

我感觉这点量 lnmp 架构也没问题

ionicwang 8楼•3 天前

rust 更屌

bupafengyu 9楼•3 天前

我看成每秒 60 万了，每天 60 万，也太少了。

gougou168 10楼•3 天前

哪怕是 8 个小时，也是一秒 21 个请求，我想我用 Python 都能实现这样的水平

nodeper 11楼•3 天前

你 golang 党水平不错…

wuwangju 12楼•3 天前作者

“ Go 的性能真是高到爆炸”这句话很明显的就是夸 Go 啊，可不是“只是提到了 Go ”

ionicwang 13楼•3 天前

#12
#11 所以我就搞不懂了，好端端的帖子，最后变成了优越感了。没有人愿意坐下来讨论

itying888 14楼•3 天前

你的标题内容把 go 拿掉，他们就会和你好好讨论问题了。

yibo5220 15楼•3 天前

问题是每秒十来个请求还没到需要调优的地步吧。。

itying888 16楼•3 天前

#15 以快速增长的业务抛出来论点，现在的请求是这几个星期增长的，并且一马奔腾。迟早都要面对这个问题，所以现在来讨论一下。
不过看来凉了，我还是多研究文档吧，这里还是灌水生活琐事居多。

ionicwang 17楼•3 天前

#13 这么夸张的修辞手法，引不起战才不正常。所以楼主你还没认识到问题所在吗？

zlyuanteng 18楼•3 天前

原谅我没 get 到楼主的问题在哪里

eggper 19楼•3 天前

还以为是 60w qps。。。

itying888 20楼•3 天前

从楼主的标题以及描述来看，楼主是个新手 go 程序员吧

性能好轮不到 go 称第一
请求频率一般是 QPS，而不是每天 xx 万

sinazl 21楼•3 天前

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

bupafengyu 22楼•3 天前

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

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

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

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

bupafengyu 23楼•3 天前

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

itying888 24楼•3 天前

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

sinazl 25楼•3 天前

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

yuanlaile 26楼•3 天前

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

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

vueper 27楼•3 天前

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

caililin 28楼•3 天前

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

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

songsunli 29楼•3 天前

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

ionicwang 30楼•3 天前

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

gougou168 31楼•3 天前

laravel：吓我一跳

songsunli 32楼•3 天前

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

ionicwang 33楼•3 天前

发现一只菜鸟

itying888 34楼•3 天前

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

eggper 35楼•3 天前

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

yibo5220 36楼•3 天前

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

phonegap100 37楼•3 天前

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

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

sinazl 38楼•3 天前

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

yibo5220 39楼•3 天前

确实，Go语言（Golang）以其出色的性能和高并发处理能力赢得了广泛的赞誉，尤其在云计算、微服务架构以及系统编程等领域展现出强大的竞争力。其内置的goroutine和channel机制，使得编写高效并发程序变得既简单又直观，这是Go语言性能卓越的重要原因之一。

然而，随着Go语言的快速普及和增长，也确实带来了一些挑战。首先，社区和生态系统的快速扩张，虽然为开发者提供了丰富的库和工具，但也增加了选择难度和学习成本。新手可能会在面对众多选项时感到困惑，需要投入更多时间来筛选和熟悉合适的资源。

其次，随着Go语言项目的规模扩大，代码质量和维护性成为了关键问题。大型项目往往伴随着复杂的依赖关系和代码结构，这要求开发者在追求性能的同时，也要注重代码的可读性、可维护性和可扩展性。

为了应对这些挑战，建议Go语言开发者积极参与社区交流，利用社区资源提升自己的技能；同时，在项目初期就建立良好的代码规范和文档体系，确保代码质量随着项目的增长而不断提升。此外，利用Go语言的静态分析工具、测试框架等，可以有效提升代码质量和降低维护成本。

总之，Go语言的性能优势为其赢得了广泛的认可，但快速增长也带来了新的挑战。通过积极参与社区、注重代码质量和利用工具支持，我们可以更好地应对这些挑战，充分发挥Go语言的潜力。