@PureWhite #15 试了下去掉所有 Redis 操作，runtime 占用比例下降了一小截，不够明显，但是能跑到 60000 请求 /秒了。基本可以确认是 IO 等待带来的 goroutine 调度开销。

@PureWhite #15 这接口之前有个 Python 版本，现在用 Go 重写之后并发上限提升十几倍，内存占用是十分之一 https://ws3.sinaimg.cn/bmiddle/62e721e4gw1et02ek7u61j200k00k3y9.jpg

@zts1993 #12 这个可以看出什么信息？还没试过，明天试试看。

@PureWhite #11 感谢！我觉得这个想法可以验证，我把接口的 Redis 操作去掉，然后再压上去看看会不会有缓解。
自身业务代码占用的 CPU 时间并不多，Redis 连接和 session 反序列化带来的性能开销暂时也不太能做改动，我觉得我已经尽力了......

@PureWhite #8 每一个请求有一次 Redis 写操作一次读操作，我打码的那部分业务代码最后大多都耗在 Redis 的库里。

@PureWhite #6 Go 版本 1.9.2，Ubuntu 16.04 ，从 pprof 里看到的 goroutine 在 10000 个左右。没有硬盘 IO，只有 Redis 读写和内存操作，CPU 密集。我的疑问在于这样的压力下 runtime 接近一半的 CPU 时间占用是否是正常的。

@whileFalse #2 schedule 看着不太像干垃圾回收的事情啊。

@denghongcai #3 每个 request 进来后都会创建一个新的 goroutine，所以肯定是有大量 goroutine 需要管理的。但我不确定这样程度的 runtime 开销是否正常。

这里是火焰图：
https://ws2.sinaimg.cn/large/7086a498gy1fnqgmgal8lj20x70nfgqg.jpg

跟网易严选这个好像一个模板出来的 http://you.163.com/item/detail?id=1369014

@Icezers #19 就一个信用分罢了，还能是什么大佬。算分方式是黑盒，只能靠以往经验猜，多做一些履行信用的事情，没房没车也可以慢慢涨上来。

你有没有看过买家的信用分？我的原则是低于 700 的尽量不交易，790 以上基本还行。

@est #13 你知道的太多了，感觉这帖子要进 Chamber https://ws3.sinaimg.cn/bmiddle/62e721e4gw1et02ek7u61j200k00k3y9.jpg

@est #7 我惊讶的地方在于有民间企业可以提供这样性质的服务。

@Imgur #3 你仔细看最后说的三个案例 https://ws4.sinaimg.cn/bmiddle/62e721e4gw1et02g5wksrj200k00k3y9.jpg

@isCyan #1 国内流量不过墙，这不叫解封。

如果是真线，说明弄错了，没啥事。
如果是假线，使用寿命可能会比官方线长很多。

乐观点。

@lhx2008 #6 谢谢，但是写反了 https://ws4.sinaimg.cn/bmiddle/62e721e4gw1et02g5wksrj200k00k3y9.jpg

sov2ex.com

map 不是 goroutine 安全的，你这种就是设计错了，不叫防御性编程。