pekko VS grpc_bench

Pekko is open source, has the same API. So there's no problem there.

Understandable considering the size of Pekko and how much time is passed, I would recommend asking any questions/concerns on either the Pekko mailing list https://lists.apache.org/[email protected] or on Github discussions https://github.com/apache/incubator-pekko/discussions.

Another big reason behind the "struggle" is we have done further improvements. For example the first release of Pekko will support all Scala versions from 2.12 up to 3.3.0 LTS (which was just released a couple of days ago). This also includes Pekko's modules which means we had to either add back in Scala 2.12 support or Scala 3 support. Yet another example would be https://github.com/apache/incubator-pekko/pull/281 which allowed us to drop scala-java8-compat dependency for Scala 2.13 or higher. So while these improvements aren't technically necessary, they have a large impact on Pekko going forward, i.e. the scala-java8-compat change means that we can drop Scala 2.12 at any point in time without breaking users.

Apache Pekko is the open source fork of Akka. I know they can use more hands right now - https://github.com/apache/incubator-pekko/issues

There is an option missing: Considering switching to pekko when it's ready: https://github.com/apache/incubator-pekko

- In 2022, Lightbend changed the Akka licence, made it proprietary and very expensive at large scale

Software that starts out as more "pure", non-corporate open-source can still turn the tables on you and charge large licensing fees later. But at least if it's open source from the start, it can be forked, e.g. for Akka, there's this Apache fork that was started after Akka changed its licence: https://github.com/apache/incubator-pekko . This is the key open source protection, and it's true for both corporate and non-corporate projects.

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.