Benchmarks

Introduction Does wrapping a blocking Pulsar consumer in Flux.generate give you backpressure? Does adding backpressure cost you throughput? The first answer is no — wrapping blocking calls in Reactor operators creates something that looks reactive but behaves like a fire hose. The second answer is also no: a properly implemented reactive pipeline is dramatically faster than both alternatives. Our JMH benchmark shows the reactive approach hitting 6.29 million messages/sec — 27x faster than the Flux-wrapped approach (232k msg/sec) and 24,800x faster than plain blocking (253 msg/sec). The reactive pipeline is faster because it does less work per message: no thread blocking, no Mono.fromCallable allocation, no boundedElastic scheduling overhead. ...

Introduction Part 1 compared the architectural foundations of Kafka and Pulsar — storage models, subscription types, multi-tenancy, and client design. That was theory. This post puts those differences under load. We will run the same workloads against both brokers on identical hardware, using a reactive benchmark framework built with Project Reactor. The goal is not to crown a winner — it is to see where architectural decisions become measurable. Specifically, we will look at: ...