I did provide the details. It is using the ‘bench’ test program provided with Nats (it is a Go client). It can be configured for multiple producers and consumers. It was run with only a single producer and no consumer.
I am in the process of running the tests with a single producer and single consumer. > On Oct 30, 2018, at 10:23 AM, Space A. <reexist...@gmail.com> wrote: > > You didn't provide any details on the tests. But I think the idea was same as > usual - send some "Hello world" over network. If so all these numbers have > nothing to do with real world. > > PS: ofc this doesn't mean that something is more or less performant than the > other. > > > понедельник, 29 октября 2018 г., 23:53:52 UTC+3 пользователь robert engels > написал: > 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.
