To achieve similar performance numbers as reported, the resident Java memory size was 96 MB, while the Go was 14 MB. Again very impressive for Go.
> On Oct 30, 2018, at 8:11 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > I will do so and report back. > > On Oct 30, 2018, at 8:03 AM, T L <tapir....@gmail.com > <mailto:tapir....@gmail.com>> wrote: > >> OP really should compare the memory consumptions of the Java version and Go >> version. >> >> On Monday, October 29, 2018 at 4:53:52 PM UTC-4, robert engels 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 >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. -- 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.
