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

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

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

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

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

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 应该也有类似的问题。

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

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

@Trim21 嗷嗷快。嗯。

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

@mstmdev

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

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

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

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

@sadfQED2

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

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

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

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

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

用 uber/zap

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

io 和 捕捉异常 都很耗时

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