Btw, with some minor code updates, and using the new GraalVM (http://www.graalvm.org <http://www.graalvm.org/>) the Java numbers improved to:
without SSL, 4300k msgs per sec Running GraalVM with SSL is VERY slow - 270k msgs per second - looks like a bug. Also, the latest code (running under Shenandoah) has Java pulling slightly ahead in terms of average and min latency, with: latency avg 178187 min 150741 max 892040 Still can’t touch Go in terms of max due to the extremely low pause times I am assuming. > On Oct 29, 2018, at 3:53 PM, robert engels <reng...@ix.netcom.com> wrote: > > 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.
