Author: lni ( https://github.com/lni)
Go 1.12 brings formal Go module support, preliminary TLS 1.3 support, various improvements to the runtime and standard library, and tools are also improved. In terms of trace, the minimum mutator utilization graph is introduced to facilitate the tuning of GC performance.
This article uses the recently released high-performance distributed consensus library Dragonboat as the background to explain the new features from the perspective of actual projects.
Go Module support
The initial Go module support of the last Go release was turned off by default, which implies that it has many implementation problems. In fact, the support of replace was ambiguous even at the time of the three most basic concepts of module, package, and import path. These problems have been solved in Go 1.12, and the official release of the Go module has closed a path for brainless spraying of Go. Real Go users can use Go more comfortably and conveniently.
Taking Dragonboat as an example, for ordinary users, a go.mod in the following two lines completely defines the dependencies of the Dragonboat library.
module github.com/lni/dragonboat
require github.com/golang/protobuf v1.2.0
The Monkey Test used by Dragopnboat requires the Drummer package, and its additional dependencies include several packages under golang.org. We need to replace them with official mirrors located on github.com. The replacement support of the Go module can be done by adding the following replacement entries to the go.mod file to replace the affected import paths. An example is as follows:
replace (
golang.org/x/build => github.com/golang/build v0.0.0-20190215225244-0261b66eb045
golang.org/x/text => github.com/golang/text v0.3.0
)
Lower STW latency
The STW pauses in Go version 1.12 are significantly shorter than those in version 1.11. The figure below is the STW pause value of 120 consecutive GC cycles reported by runtime.ReadMemStats when Dragonboat processes more than 8 million 16-byte Proposals per second. Compared with 1.12 and 1.11, the STW drops significantly, from 350 microseconds to 250 microseconds or so.
Minimum Mutator Utilization graph support
Mutator Utilization measures how much CPU resources are obtained by applications other than the resources consumed by GC. The Minimum Mutator Utilization graph is the minimum amount of CPU resources that can be obtained by rendering the application on different time windows. The trace tool in Go 1.12 has added support for the Minimum Mutator Utilization graph, which makes it extremely convenient to find situations where GC performance is limited.
The figure below is the Minimum Mutator Utilization diagram of Dragonboat when processing 16-byte proposals. It can be seen from the figure that when the time window is less than 250 microseconds, the application cannot get any CPU in the worst case, because the length of STW is basically 250 microseconds. When the time window is continuously enlarged, the Minimum Mutator Utilization rises rapidly and tends to 100% and finally stabilizes at about 98%. This means that from the perspective of the entire trace execution cycle (maximum time window), the application can guarantee 98% of the CPU time in the worst case. It can be seen that this example does not have any value for GC optimization.
The Minimum Mutator Utilization diagram of Dragonboat when dealing with proposals of 1024 bytes shows another situation. In 1.3 milliseconds, the worst-case CPU resources available to the application are all 0, implying that the STW is an order of magnitude higher than that of 16 bytes. With the expansion of the time window, the Minimum Mutator Utilization gradually approaches and stabilizes at about 90%. From the perspective of the execution cycle of the entire trace, the application can guarantee 90% of the CPU time in the worst case. Higher STW and more CPU resources occupied by GC clearly show that continuing to optimize memory usage in this scenario is a certain expected benefit, and Minimum Mutator Utilization is quite intuitive and convenient.
Preliminary TLS 1.3 support
Go 1.12 provides preliminary TLS 1.3 support in a timely manner. TLS 1.3 eliminates old museum-level algorithms such as DES, MD5, RC4, and SHA1 that have clear security risks, and supports an RTT to complete the preparation required to establish a secure link.
From the performance benchmark of TLS 1.3 built in Go 1.12, the benchmark performance of TLS 1.3 is not much different from that of 1.2, and there is still some room for optimization in the future. If you are interested, you can test the benchmark performance on your own target server:
go test -v crypto/tls -run=$^ -bench BenchmarkThroughput
The 0-RTT feature of TLS 1.3 has not yet been supported. The discussion of the security risks of this feature itself has nothing to do with the standard library implementation of a common language such as Go, and will not be expanded here.
Various other improvements
Some of the improvements related to a high-performance, distributed systems library like Dragonboat are:
- The performance of Timer and Deadline has been optimized, and the cost of the deadline setting on the connection has been reduced
- TCP KeepAlive is enabled by default
- The os package begins to provide the UserHomeDir function, which no longer requires a third-party library for cross-platform support
- The problem that calling File.Sync on macOS does not ensure actual disk placement is resolved
For all the improvements and changes, please see the 1.12 document
Finally, thanks for reading, and please visit Dragonboat 's github page for star support. Thanks!