Hello Gophers, I’ve been chastised in the past regarding some of my Go performance tests - using Java as a baseline. In most of these micro-benchmarks Go has performed more poorly than expected.
So, I ported nats (https://nats.io <https://nats.io/>) message broker (which is written in Go) to Java. It is available at github.com/robaho/jnatsd <http://github.com/robaho/jnatsd> This was an ideal test case, as only the server broker was ported, and all of the client tools and benchmarks could be run unmodified. So, using the Java based broker (under OpenJDK11 with Shenandoah) and the nats bench with defaults: without SSL, 3200k msgs per second with SSL, 900k msgs per second using the Go based server (under Go 1.11) and the same test parameters: without SSL, 5400k msgs per second with SSL, 2600k msgs per second The latency numbers are much closer, but notice the much higher max in Java (attributed to larger GC pauses). It is expected that in the above throughput tests, more GC cycles, thus a much larger penalty. Java: latency avg 191214 min 167079 max 936848 ns Go: latency avg 188338 min 158997 max 588876 ns So, Go shows VERY, VERY impressive performance numbers in a real-world application, and aligns with my thoughts that Go is ideally suited to replacing systems level software currently written in C/C++. Some notes, the Java implementation uses some custom string processing classes to improve performance, but does not use async IO (mainly since doing so with SSL is a huge PITA). The Go server is also FAR more robust in terms of ‘handling slow consumers, handling lots of clients, etc.” I might try modifying the Java to use NIO direct buffers and channels to observe any improved performance. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
