有日志(stdout or file) qps 4k，没日志 qps 10w. why?

[dzdh]

很简单的一个 echo 的 hello world 小 demo 。

wrk -c2000 -d10s -t6 http://localhost:8000/

use(logger)就 4k 的 qps （默认是 stdout ），不 use 就 10w 的 qps ??

因为同步输出到 stdout 需要时间嘛？那正式线上服务还需要考虑异步写日志咯？

搞个有 buffer 的 writer ？那 panic 的时候没来得及刷盘的日志咋弄。

[Maboroshii]

writer 本来也有 buffer 吧。你可以搞个写日志的 benchmark 试下，在你的机器上到底什么性能。另外 writer 可能还有锁，这个也有性能消耗。

[Trim21]

不至于这么慢吧，你把 log 输出到 io.Discard 试试?

[xupefei]

>那正式线上服务还需要考虑异步写日志咯？
不要过度优化。

[msg7086]

你正式上线如果要跑 10w qps 的话还是单独开一台日志服务器吧。

[mstmdev]

goos: windows
goarch: amd64
go:1.18.1
cpu: Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz

BenchmarkPrintln-12 18981 110532 ns/op 24 B/op 1 allocs/op
BenchmarkStdout-12 15235 84465 ns/op 24 B/op 1 allocs/op
BenchmarkBufio-12 56409 25036 ns/op 163 B/op 0 allocs/op
BenchmarkDiscard-12 348340519 3.703 ns/op 0 B/op 0 allocs/op

简单测试了一下，光打印“hello world\n”，性能相差还是很大的，Stdout 底层有系统调用和锁，访问量大的话还是会影响性能的。java 的 System.out.println 应该也有类似的问题。

[CEBBCAT]

可否详细说明 panic 和落盘的关系？网络服务不一般都对 request 逐个做了 recovery 吗？

[kiwi95]

@CEBBCAT 虽然都会有一个 recovery middleware ，但是 request 处理内部会起 goroutine 就可能整个程序 panic ，不做处理的话这可能导致日志会丢失一些

[dzdh]

@Trim21 嗷嗷快。嗯。

[ToBeHacker]

相比于 echo HelloWorld ，写日志本身就很重了。在高性能场景下，除了 debug 日志都要关掉的

[dzdh]

@mstmdev

goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
BenchmarkStdout-8 10000 261816 ns/op

[sadfQED2]

1.go 语言的输出队列是 1k 还是多大来着，当高并发写日志的时候把输出队列占满了，其他输出就会等待，因此你 qps 就下去了

2.你应该把日志改成写文件再试试

3.线上服务写日志难道还有人不是异步的？

[dzdh]

@sadfQED2

2. 好像更满了....
3. 这块儿有好用的包吗

[sadfQED2]

@dzdh 开源的不知道，我呆过的公司日志框架都是内部实现的。写日志都是异步操作

[lwch]

估计是你这个日志库里有锁，或者队列长度比较短导致大量调用被 block 住了

[misaka19000]

写日志到磁盘肯定慢啊，磁盘和网络内存 CPU 比起来实在是太慢了

[misaka19000]

写日志必须是异步的操作，不然会影响业务性能

[tairan2006]

用 uber/zap

[iseki]

Java 那边一般也不会 System.out.println ，一般库都是异步的，go 也一样

[awanabe]

io 和 捕捉异常 都很耗时

[sujin190]

stdout 输出到控制台的写性能确实不高，stdout 重定向到文件的区别应该不大吧