grpc_bench VS eCAL

SayHello, GetUser, and Sum differ only by payload size. Sum is the simplest one - (int, int) -> int, GetUser is (long) -> User (medium payload), and SayHello uses exactly the same payload as this test: https://github.com/LesnyRumcajs/grpc_bench/tree/master/dotnet_grpc_bench

This is correct. The problem is not with the benchmark itself but with the implementation. If you look at the result, you can see that even with 6 "allowed" CPUs, the vertx server utilizes less than 100%. Apparently, the current vertx implementation (the one implemented in https://github.com/LesnyRumcajs/grpc_bench/tree/master/java_vertx_grpc_bench) is single-threaded or has some other limitation.

Another iteration of grpc_bench!

Because it's fast and runs on Windows, Linux, and MacOS

In general though, akka/pekko-streams are known to be one of the fastest implementations out there. Their grpc client for example even beats languages like Rust (see https://www.lightbend.com/blog/akka-grpc-update-delivers-1200-percent-performance-improvement and https://github.com/LesnyRumcajs/grpc_bench/wiki/2022-03-15-bench-results).

The whole point I was making is at least up until 8 months ago (at best, I can't commend on the stability/maturity/performance of shardcake) Akka was the only mature library/ecosystem solving this problem with also a very strong focus on performance (for example still to this day, akka/pekko-grpc is generally one of the fastest grpc implementations I am aware of, its even beating rust if you have at least 2 cores (see https://github.com/LesnyRumcajs/grpc_bench/wiki/2022-03-15-bench-results)

It would be interesting to create a new java benchmark with your implementation.

Also worth checking out the gRPC benchmarks: https://github.com/LesnyRumcajs/grpc_bench/discussions/284

dotnet is up there with Rust.

New version (5.94) of the high performance interprocess / interhost communication framework eCAL is available. eCAL supports different transport layer like shared memory for interprocess and udp multicast for interhost communication. It does not force the user to use a specific serialization format but supports some of the standards like google protobuf, capnproto or flatbuffers. The API is wrapped to C, C++, Python, C#, Rust and Go (the last two I never tested ;-)). Here you can find all the documentation. Check out the great applications for monitoring, record and replay. eCAL is Apache 2 licensed, repository hosted here. Have fun :-)

I you just need a fast publish / subscribe framework for windows you can give eCAL a try. The setup is done in less a minute and their is no dependency hell. Just to mention it as alternative. Documentation here

I would concider using eCAL since it blasts everything out of the water in terms of performance and comes with some handy tooling for inspection of messages in-travel.

Source on GitHub: https://github.com/continental/ecal

Check out eCal.

This really makes me want to try https://github.com/continental/ecal with https://github.com/google/flatbuffers to see how they compare. I also know that gpc for cpp at least stops functioning by about 4 MB of request size. Which I find stupid. What if I want to send uncompressed bitmaps!

Congratulations. Well done. eCAL will update as soon as possible to the new release. The new custom header and the n:m pub/sub support are really welcome new features.

Here is their counter callback example: https://github.com/continental/ecal/blob/master/samples/cpp/counter/counter_rec_cb/src/counter_rec_cb.cpp