Final update on this, using a technique from my HFT days, by spinning the main routing thread longer before parking I reduced the latency numbers with Java to:
duration avg 186828 min 152425 max 968440 which are back inline with the original that did not use the intermediary queue. It did not make any significant change to the throughput timings. In summary, the Go numbers were far more consistent, especially in terms of max latencies. It also exhibits no warm-up delays, and much lower memory requirements. The Go internal scheduling (fibers/CSP) exhibits awesome performance for concurrent “small IO” operations, and allows developers to write highly performant IO code in a very straight-forward manner. A job well done to the Go team! > On Nov 1, 2018, at 11:31 AM, robert engels <reng...@ix.netcom.com> wrote: > > Just an update for those who may be interested. > > With some improvements to the Java side, and using a more realistic test of 1 > pub and 1 sub, the results: > > Java: > without SSL, 3450k msgs per sec > with SSL, 1300k msgs per sec > > Go: > without SSL, 3600k msgs per sec > with SSL, 1800k msgs per sec > > Clearly using software based SSL offers superior performance in Go. > > Also, in order to improve the Java throughput numbers, the latency numbers > degraded as expected, falling to: > > latency avg 198522 min 170305 max 962827 > > with Go being: > > latency avg 187347 min 157705 max 604295 > > The intermediary queue that was added to the Java version (in order to > increase parallism and avoid some contention), shows an advantage of the Go > async+routine model. The Go scheduler (which was already subject to the OS > scheduler latency - which remains effectively constant as more Go routines > are added), can improve as more “queues/channels” are added, where a similar > design in a thread based model improves the concurrency but increases the > latency due to more OS context switching. > > As discussed I may do a last round using Java NIO to implement a similar > async model - the difference is these complexities are handled internally by > Go, and with Java you need to handle them yourself (or use a well written > library) - but even then the “code design is different” - where as in Go it > remains the same procedural handling you started with. > > The closest way (and maybe simplest) is to probably to use a Java “fibers” > library for light-weight threads, but that’s not standard Java either. > >> On Oct 30, 2018, at 3:46 PM, robert engels <reng...@ix.netcom.com> wrote: >> >> Btw, the math was off here, with 3 million vs. 5 million ops a second (and >> these are essentially IO ops - sending messages to the broker), the >> difference is 0.13 microsecs per op - or 130 nanos. Pretty insignificant for >> IO based tasks. >> >>> On Oct 30, 2018, at 8:10 AM, Robert Engels <reng...@ix.netcom.com> wrote: >>> >>> I’ve written lots of network service code. I understand what’s available. >>> Actually, for a small number of clients threads are faster than async/nio. >>> In this case there is only a single active thread during the test. >>> >>> The main benefit of using nio is that you can avoid the java space to >>> native copying by using a direct byte buffer. This would make things >>> considerably faster, and put less pressure on the garbage collector. But to >>> do this you need to use channels, and these are a pain with SSL - not >>> impossible but certainly not trivial. >>> >>> I plan on reworking so of the code to use a buffer chain - which is what >>> the Go version does. >>> >>> One thing to keep in mind, at 3-5 million operations a second, the >>> difference is under 2 microsecs an op. With the GC pauses in Go being half >>> that of Java, it doesn’t take too many pauses to account speed difference. >>> >>> >>>> On Oct 30, 2018, at 7:17 AM, gerrit.jansen_van_vuu...@datastax.com wrote: >>>> >>>> Some notes on your java impl: >>>> >>>> You really want to use a framework for handling the connections and >>>> threading, its tricky in java. >>>> Your current implementation creates 2 new threads on each connection which >>>> is wasteful and very expensive. >>>> >>>> For threading please see: >>>> https://stackoverflow.com/questions/5483047/why-is-creating-a-thread-said-to-be-expensive >>>> >>>> You would either use: >>>> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html >>>> or >>>> go for https://netty.io/. >>>> >>>> For TLS >>>> >>>> Java's implementation is unfortunately slow :(. >>>> (https://nbsoftsolutions.com/blog/the-cost-of-tls-in-java-and-solutions) >>>> The solution is to either use something like HAproxy or try and use native >>>> ssl libraries, https://netty.io/wiki/forked-tomcat-native.html. >>>> >>>> For a fairer comparison please do a rerun with the latest jre 11 and the >>>> threads being created in a global Executor service >>>> >>>> >>>> -- >>>> 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. >> > -- 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.
