Performance

[benjchristensen]

As of 3e52b25 the performance looks as follows:

./gradlew benchmarks '-Pjmh=-f 1 -tu s -bm thrpt -wi 5 -i 5 -r 6 .*ReactiveSocketPerf*'

Benchmark                                   Mode  Cnt        Score        Error  Units
ReactiveSocketPerf.requestResponseHello    thrpt    5  3466701.646 ± 232969.245  ops/s
ReactiveSocketPerf.requestStreamHello1000  thrpt    5    13441.690 ±    977.459  ops/s

(On my 2.3 GHz Intel Core i7 running OSX)

This involves no IO, just an in-memory dual-channel for simulating transport and exercising the protocol handlers.

This is 3.5M "hello" request/response per second (with a static payload each time) and 16M messages/second with streams of 1000 "hello" messages (again, all static, so no compute time to encoding).

Here is a Flight Recorder screenshot of the requestResponse test:

[benjchristensen]

The code is currently not production ready. I cut corners to get a pure ReactiveStreams and imperative implementation functioning. There are places where 'merge' would typically be used to manage multiple 'onError' or 'onComplete' signals, but are currently racing each other, or being allowed to occur concurrently. I think all 'onNext' behavior is okay. I also don't trust the cancellation and backpressure (the 'request(n)' semantics).

As we flush out the rest of the functionality and unit tests, I intend to start adding back in composition (such as 'merge') to get the needed correctness, while using these benchmarks as a point of comparison. Unless there is a major functional bug currently that makes these numbers useless, my hope is that the rough edges right now can be polished without significantly affecting these numbers.

[benjchristensen]

Old ... moved on to new perf issues after fixing other ones and adding more functionality.