Benchmarks: Apache Camel vs Cameleer

Measured with the same routes on separate cloud machines, Cameleer starts in milliseconds instead of about a second, uses a fraction of Apache Camel's memory, and moves more messages per second on the same CPUs, in routing, REST APIs, Kafka, PostgreSQL and batch jobs.

This is the full report behind the Apache Camel vs Cameleer comparison. It compares three runtimes on the same routes:

• Cameleer 0.4.0, the native Rust binary;
• Apache Camel on the JVM: Camel 4.23.0 on Java 21, the way most Camel runs today;
• Apache Camel on Quarkus, native: Camel 4.22.1 compiled ahead of time with Quarkus 3.40.0 and Mandrel, the fastest-starting way to run Camel.

Every number below is generated from the raw results in benchmarks/results/ by scripts/cloud-bench/summarize.py; none is typed by hand. Each figure is the mean of two runs on two identical servers.

Results

Throughput (higher is better)

Latency, p99 (lower is better)

Memory and CPU

Startup

What the results show

• Startup. Cameleer has its routes running in a few milliseconds. Apache Camel on the JVM takes about a second; compiled natively with Quarkus it takes tens of milliseconds.
• Memory. Cameleer runs these routes in tens of megabytes. Camel on the JVM uses hundreds; native Camel sits in between.
• Throughput. Cameleer handles more messages per second than Camel on the JVM in every scenario, and more than native Camel by a wider margin: native Camel has no JIT compiler, so it trades throughput for startup.
• Latency. Cameleer's p99 latency is lower in every scenario but one. In HTTP into Kafka it is slightly higher than Camel on the JVM (8.6 ms against 7.8 ms) while serving 1.7 times the requests: Cameleer batches the sends of concurrent requests, which raises the slowest requests' wait a little.

The scenarios

The routes are defined once per runtime from one specification: crates/cameleer-bench/src/scenarios.rs and realworld.rs for Cameleer, Bench.java for Apache Camel (the Quarkus build compiles the same class from benchmarks/camel-quarkus).

How we tested

Machines. Three DigitalOcean CPU-optimized droplets (c-4) in region blr1: 4 dedicated vCPUs (Intel Xeon Platinum 8168 at 2.7 GHz), 8 GB RAM, Ubuntu 24.04, on one private network. Two of them are servers that take turns running each runtime; the third runs the HTTP load generator, Apache Kafka 4.3.2 (KRaft, one broker, 4 partitions per topic) and PostgreSQL 16. All three get the same kernel settings (scripts/cloud-bench/setup-node.sh).

Runtimes. Temurin 21.0.13 for Apache Camel 4.23.0, with no JVM flags. Camel Quarkus 3.40.0 (Apache Camel 4.22.1) compiled with Mandrel 25.0.4.1. Cameleer 0.4.0 built with Rust 1.99.1 in release mode. Every download is pinned and checksum-verified.

Method.

• Each scenario runs in a fresh process: 15 s of warmup, then five timed 5-second iterations.
• The two servers swap roles halfway, so every runtime runs on both machines and each figure is the mean of the two. Only one runtime runs at a time.
• The HTTP scenarios use 64 concurrent keep-alive connections from the load machine; the load generator (loadgen.rs) is the same for every runtime and sends a different order id with every request.
• Default settings everywhere: no GC or thread-pool tuning on either side, and the same PostgreSQL pool size (16; HikariCP on the JVM, Agroal on Quarkus).
• Peak memory and CPU of each server process come from /usr/bin/time; startup is the time from spawning the process to its READY line, median of five.

Reproduce it. A run costs about one US dollar of cloud time:

export DO_TOKEN_FILE=~/do-token.txt     # a DigitalOcean API token
scripts/cloud-bench/droplets.sh up      # three c-4 droplets
scripts/cloud-bench/run.sh all          # build, fill Kafka, run every scenario
scripts/cloud-bench/droplets.sh down    # delete the droplets

See scripts/cloud-bench/README.md.

Results that need context

• Kafka stream processing waits for every record's acknowledgement (acks=all) before the next one, on every runtime: that is the default behaviour of both Camel's and Cameleer's Kafka producer. The ratio is fair; the absolute numbers are far below what Kafka can do with batching or asynchronous sends.
• HTTP is measured with one load machine of the same size as the server. It drives every runtime the same way, but the absolute requests per second are not a ceiling.
• Apache Camel on Quarkus runs Camel 4.22.1, one minor version behind the JVM side, because that is what the latest Camel Quarkus release ships.

Bugs this benchmark found and fixed

Running real workloads on separate machines found three problems in Cameleer, fixed before the numbers above were taken. Each fix has a regression test.

• HTTP keep-alive. The HTTP server had 32 worker threads and closed keep-alive connections when all were busy, so more than 32 concurrent clients reconnected on every request. The default is now 200 workers, started on demand.
• Kafka producer. Concurrent sends waited in line one record at a time. They are now batched into one produce request per broker, as Kafka's own producer does.
• PostgreSQL pool. poolSize only limited idle connections, so a burst opened extra connections. It is now a hard maximum, like HikariCP's, with callers waiting up to poolTimeout.

FaaS cold start and size

Startup and size of the cameleer command itself, measured with cameleer-bench coldstart (spawn to the Routes startup log line, 40 runs, medians) on Linux x86-64 (WSL2 Ubuntu 24.04 on a Ryzen 5 5600X):

Container images (linux/amd64, distroless, compressed): about 20 MB with every component, 14.5 MB with FEATURES=cloud, 12.5 MB with FEATURES=core. In AWS's provided:al2023 image with the Lambda Runtime Interface Emulator, init took 3.5–5.2 ms and warm invocations 0.7–1.3 ms. The detailed measurements, the Windows numbers and the tuning history are in benchmarks/local.md and benchmarks/analysis.md; the build options are in build features.

Found a problem?

If a number here doesn't match what you measure, please open an issue with your setup and results, or fork the repository, fix the harness, and open a pull request.