在工作中负责开发 qps 较高的中间件过程中,发现原来使用的 seelog 中每次函数调用均会调用 runtime.Caller 及 runtime.FuncForPC 这两个极为耗时的操作(单 goroutine 下,每次需要 0.1~0.2ms),这意味着调用 n 次 seelog 的日志函数后,耗时将增加 n * (0.1~0.2)ms. 换用了 logrus 后情况有所缓解,而且也挺好用的(JSON 格式输出)。但是 logrus 不支持配置文件,这一点上没有 seelog 可以通过 xml 文件配置来的优雅。此时在想,有没两者优点合二为一的呢?
另外,在 fmt 包格式化字符串的探索中,发现将格式化字符串和输出过程融合,而不等整个字符串格式化完再输出(一边格式化,一边输出),这样的效率会提高 20%左右,在亲测在 100 goroutines 的情况下提高更为可观。由此便有了这个库的初步构想。最后增加了 buf.io, timeCache, format const, bytes.buffer 等各种技巧的使用,使得日志输出效率极大的提高。最终用到线上环境中,运行稳定,中间件的处理能力也得到了满意的提升。
期待感兴趣的大大们的建议~
项目地址:
https://github.com/YoungPioneers/blog4go
BLog4go is an efficient logging library written in the Go programming language, providing logging hook, log rotate, filtering and formatting log message.
BLog4go 是高性能日志库。创新地使用“边解析边输出”方法进行日志输出,同时支持回调函数、日志淘汰和配置文件。可以解决高并发,调用日志函数频繁的情境下,日志库造成的性能问题。
I do some benchmark on a HDD disk comparing amoung fmt,blog4go,seelog,logrus. Benchmark Code
BenchmarkBlog4goSingleGoroutine-4 1000000 1087 ns/op
BenchmarkBlog4goMultiGoroutine-4 30000 56569 ns/op
BenchmarkFmtFormatSingleGoroutine-4 300000 5104 ns/op
BenchmarkFmtFormatWithTimecacheSingleGoroutine-4 300000 4256 ns/op
BenchmarkFmtFormatWithTimecacheMultiGoroutine-4 3000 509579 ns/op
BenchmarkLogrusSingleGoroutine-4 100000 13757 ns/op
BenchmarkLogrusWithTimecacheSingleGoroutine-4 100000 12752 ns/op
BenchmarkLogrusWithTimecacheMultiGoroutine-4 1000 2049809 ns/op
BenchmarkSeelogSingleGoroutine-4 50000 32846 ns/op
BenchmarkSeelogMultiGoroutine-4 1000 3191334 ns/op
It shows that blog4go can write log very fast, especially in situation with multi goroutines running at the same time~
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.