MCP Server Performance Benchmark v2: 15 Implementations, I/O-Bound Workloads

Abstract

Table of Contents

1. Introduction and Motivation

The MCP ecosystem is growing rapidly. Organizations adopting MCP servers face a widening set of implementation trade-offs: native compilation via GraalVM, reactive vs blocking I/O models within the JVM, alternative JavaScript runtimes, and the impact of real external I/O workloads on framework-level decisions. v2 was designed to surface these trade-offs empirically.

The v1 benchmark drew valid community feedback: no Quarkus, no GraalVM native images, no Virtual Threads, no reactive frameworks, no Micronaut, no Rust, and Python running in a single-worker default configuration. Version 2 is the direct experimental response to those criticisms, expanding from 4 to 15 implementations and replacing synthetic CPU tools with real Redis and HTTP API workloads.

2. Experimental Setup

2.1 From v1 to v2: What Changed

2.2 Test Environment

2.3 Server Implementations

2.4 Benchmark Tools and Workload

Each server implements three identical tools performing I/O-bound operations against a Redis instance and an HTTP API service (100,000 products in-memory):

// k6 Load Profile — v2
export const options = {
    stages: [
        { duration: '10s', target: 50 },  // Ramp-up to 50 VUs
        { duration: '5m', target: 50 },   // Sustained load
        { duration: '10s', target: 0 },   // Ramp-down
    ],
    thresholds: {
        'http_req_failed': ['rate<0.05'],
    },
};
// First 60 seconds excluded from metrics (WARMUP_SECONDS=60)

2.5 Test Methodology

graph LR
    A[Redis Flush] --> B[Redis Seed]
    B --> C[Stop MCP Servers]
    C --> D[Start Target Server]
    D --> E[Health Check]
    E --> F[Warmup 60s]
    F --> G[k6 Run 5min]
    G --> H[Stats Collection]
    H --> I[Consolidate Results]

    style D fill:#1e293b,stroke:#6366f1
    style G fill:#1e293b,stroke:#10b981
                    

Figure 1: Per-server test cycle ensuring isolation and reproducibility

1. Redis Isolation: Flush and re-seed before each server to ensure identical data state across all 15 servers.
2. Server Isolation: Only one MCP server running during each test period, eliminating resource contention.
3. Warmup: 60 seconds of real tool calls excluded from metrics to allow JIT compilation on all code paths (5 init sessions + 9 tool call sessions per server).
4. Sustained Load: 50 VUs, 5 minutes, all 3 tools called in rotation. VU N uses user-(N%1000), providing 50 distinct users.
5. Parallel Stats Collection: Docker stats sampled alongside k6 metrics for CPU and memory.

3. Implementation Details

3.1 Rust (rmcp SDK)

// StreamableHttpServerConfig with json_response patch
StreamableHttpServerConfig {
    stateful_mode: false,
    json_response: true,   // returns application/json directly instead of SSE
    ..Default::default()
}

// New branch in tower.rs (simplified)
if self.config.json_response {
    let cancel = self.config.cancellation_token.child_token();
    match tokio::select! {
        res = receiver.recv() => res,
        _ = cancel.cancelled() => None,
    } {
        Some(message) => {
            let body = serde_json::to_vec(&message)?;
            Ok(Response::builder()
                .header(CONTENT_TYPE, JSON_MIME_TYPE)
                .body(Full::new(Bytes::from(body)).boxed()))
        }
        None => Err(internal_error_response("empty response")(...))
    }
}

Key Characteristics:

• rmcp 0.17.0 (official release) with json_response: true in StreamableHttpServerConfig
• Tokio async runtime with deadpool-redis connection pool (pool size 100)
• Parallel tool handlers via tokio::spawn
• Redis pipeline combines 3 write operations in checkout into a single RTT
• 10.9 MB average RAM (lowest of all 15 servers)
• CV 0.04% (most stable across all 3 runs)

3.2 Quarkus (Vert.x / Mutiny)

quarkus.rest-client.api-service.connection-pool-size=1000
quarkus.rest-client.api-service.keep-alive-enabled=true
quarkus.redis.max-pool-size=100
quarkus.redis.max-pool-waiting=1000

Key Characteristics:

• Reactive Vert.x/Mutiny event loop model, non-blocking I/O throughout
• Lowest CPU usage among all Java frameworks (161.7% avg, vs 200%+ for others)
• 194.5 MB RAM (lowest JVM footprint among JVM Java variants)
• Best latency of all 15 servers: 4.04ms avg, 8.13ms P95, 11.16ms P99

3.3 Go (mcp-go)

var httpClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 100,
        IdleConnTimeout:     90 * time.Second,
    },
    Timeout: 10 * time.Second,
}

Key Characteristics:

• Goroutine-per-request concurrency model with net/http standard library
• 23.9 MB average RAM (second lowest after Rust)
• Static binary, no runtime dependency
• CV 0.19% (third most stable overall)

3.4 Java (Spring MVC, Blocking I/O)

Key Characteristics:

• Spring Boot 4 MVC with Tomcat thread pool executor
• Sequential blocking I/O via RestClient and StringRedisTemplate per request
• No CompletableFuture or reactive primitives
• 368.1 MB average RAM (standard Spring Boot JVM footprint)

3.5 Java Virtual Threads (Project Loom)

Key Characteristics:

• spring.threads.virtual.enabled=true (canonical Spring Boot 4 configuration)
• Java 25 selected to include JEP 491 (delivered in Java 24): Virtual Threads can now acquire and release synchronized monitors without pinning the carrier thread. Before this fix, any synchronized block inside the call stack (including Spring internals) would pin the Virtual Thread to its OS carrier thread for the duration, eliminating the concurrency benefit for I/O-bound code.
• Same RestClient and StringRedisTemplate as Java MVC
• 349.7 MB RAM (slightly higher than MVC due to Virtual Thread scheduler metadata)
• Competitive throughput at 3,482 RPS

3.6 Java WebFlux (Reactor / Netty)

Key Characteristics:

• Reactor event loop model, non-blocking I/O throughout
• Competitive average latency (8.89ms avg) but high P99 tail in checkout (47ms)
• 484.6 MB average RAM (highest among JVM variants, due to Netty off-heap buffers)

3.7 Micronaut

Key Characteristics:

• Micronaut MCP Server SDK 0.0.19 (pre-release)
• Compile-time dependency injection and annotation processing
• Netty server (same off-heap memory pattern as WebFlux)
• JVM variant competitive at 3,382 RPS

3.8 GraalVM Native Images: Cross-Stack Analysis

Five server stacks were benchmarked in both JVM and GraalVM native image configurations, revealing consistent trade-off patterns across all stacks.

3.9 Node.js and Bun

// Cluster entry (WEB_CONCURRENCY=4 worker processes)
import cluster from 'cluster';
const WORKERS = parseInt(process.env.WEB_CONCURRENCY || '1');
if (cluster.isPrimary) {
    for (let i = 0; i < WORKERS; i++) cluster.fork();
} else {
    // Per-request McpServer (SDK design constraint — cannot be reused)
    app.post('/mcp', async (req, res) => {
        const server = createMcpServer();
        const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
        await server.connect(transport);
        await transport.handleRequest(req, res, req.body);
    });
}

3.10 Python (FastMCP + uvloop)

# Launch command
# uvicorn main:app --host 0.0.0.0 --port 8082 --workers 4 --loop uvloop

# FastMCP configuration: json_response=True eliminates SSE framing overhead
mcp = FastMCP("BenchmarkPythonServer", stateless_http=True, json_response=True)

# Shared HTTP client (avoids per-request TCP pool creation)
@asynccontextmanager
async def lifespan(app):
    global _http_client
    _http_client = httpx.AsyncClient(timeout=10.0)
    async with mcp.session_manager.run():
        yield
    await _http_client.aclose()

Key Characteristics:

• GIL limits true parallelism within each worker process
• 4 workers x approximately 65 RPS per worker = 259 RPS total
• 258.6 MB average RAM
• The bottleneck is FastMCP session overhead in CPython, not uvicorn or network I/O

4. Results and Analysis

4.1 Overall Performance Metrics

4.2 Latency Analysis

Average latency measurements reveal four distinct performance tiers. The top tier (Rust, Quarkus, Go, Java) operates in the 4-7ms range with I/O-bound workloads. This contrasts sharply with the v1 sub-millisecond averages, which reflected synthetic CPU-bound tools. The v2 numbers represent realistic production latency with actual Redis and HTTP network round-trips.

4.3 Throughput Comparison

Throughput measurements reveal three clear clusters: Rust and Quarkus at 4,700-4,850 RPS, the Java/Go cluster at 3,000-3,620 RPS, and the JS/Python group at 250-880 RPS. The gap between Tier 1 and Tier 4 is approximately 19x (Rust vs Python). Within the Java ecosystem, the 6-way spread from java-webflux-native (2,161 RPS) to quarkus (4,739 RPS) illustrates the significant impact of framework, concurrency model, and compilation strategy.

4.4 Resource Efficiency

4.5 Tool-Specific Performance

Table 5 breaks down average latency (ms, consolidated across 3 runs) per tool, with each panel sorted independently to show which server leads for that specific operation.

4.6 Stability and Reproducibility

All 15 servers achieved a CV (Coefficient of Variation: the ratio of standard deviation to mean, expressed as a percentage) below 2% across the 3 independent runs. A CV below 5% is generally considered excellent for load tests on shared infrastructure. The Redis flush-and-reseed methodology eliminates state drift between servers. The 60-second warmup exclusion eliminates JIT cold-start noise. The result is stable, reproducible rankings suitable for technology selection decisions. P95 latency showed equivalent stability: 13 of 15 servers had a stable P95 trend across runs. Only quarkus-native (+1.06ms) and bun (+2.86ms) showed slight increases. Python was the sole variable entry (range of approximately 30ms across runs), consistent with CPython GIL scheduling variability.

5. Discussion

5.1 Performance Tiers

5.2 Trade-offs Analysis

5.3 Consistency and Reliability

The CV below 2% for all 15 servers is exceptional for a benchmark running on a shared cloud VM. The Redis reset methodology eliminates state drift. The warmup exclusion eliminates JIT noise. Rankings are stable and can be used with confidence. The only notable anomaly is Python's P95 variability across runs (335-387ms), attributable to GC pressure variation in the CPython runtime rather than network or Redis inconsistency.

6. Recommendations

6.1 Production Deployment Guidance

6.2 Use Case Decision Matrix

Figure 2: MCP Server Selection Guide — primary choice and alternatives by deployment scenario. See Table 10 for the full use case matrix.

7. Conclusion

This experimental analysis expanded the MCP server benchmark from 4 to 15 implementations, replacing synthetic CPU tools with real Redis and HTTP API workloads. The expansion revealed performance characteristics that were invisible in v1: the critical impact of connection pool configuration (Quarkus 0 RPS without tuning), the JVM vs native image throughput-memory trade-off under I/O load, the significance of runtime choice within the JavaScript ecosystem (Bun 2.2x Node.js), and the realistic production ceiling of optimized Python (259 RPS with 4 workers and uvloop).

The 39.9 million requests processed with 0% errors across all 15 servers validate the methodology's reproducibility. The CV below 2% for every server confirms that the rankings are stable. The data provides a reliable empirical basis for MCP server technology selection decisions.

Key Finding: In I/O-bound workloads representative of production MCP deployments, Rust and Quarkus lead the field at 4,845 and 4,739 RPS respectively, with Quarkus holding the best latency at 4.04ms average and 8.13ms P95. Go remains the optimal choice for teams prioritizing operational simplicity and resource efficiency. The study confirms that GraalVM native images reduce memory at the cost of throughput in sustained I/O workloads, with Quarkus-native as the best-positioned exception.

Summary of Findings:

• Performance tiers are clearly separated: Rust/Quarkus at 4,700-4,850 RPS, Go/Java cluster at 3,000-3,620 RPS, JS/Python at 250-880 RPS.
• Native images consistently reduce memory (27-81%) at a 20-36% throughput cost under sustained high load. At low request rates, this throughput regression is not observable. Quarkus-native offers the best trade-off at high load.
• Classic blocking I/O (Spring MVC) outperforms reactive (WebFlux) at 50 VUs in this I/O-bound workload.
• Bun delivers 2.2x the throughput of Node.js on identical code, making it the clear choice when the JavaScript ecosystem is required.
• All 15 servers achieved 0% errors and CV below 2% across 39.9 million requests, validating the methodology's reproducibility.

Future Work: Higher concurrency levels (100-200 VUs) to identify saturation points. Persistent session benchmarks. Multi-instance Kubernetes deployments with session affinity. Rust Rust with native compilation using rmcp v0.17.0.

8. References and Resources

1. MCP Streamable HTTP Specification (2025). Model Context Protocol: Streamable HTTP Transport. https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
2. Mendes, T. (2026). rmcp SDK PR #683: json_response support for stateless HTTP transport. https://github.com/modelcontextprotocol/rust-sdk/pull/683
3. Quarkus Team. (2025). Quarkus REST Client Reactive: Configuration Reference. https://quarkus.io/guides/rest-client-reactive
4. OpenJDK. (2023). JEP 444: Virtual Threads. https://openjdk.org/jeps/444
5. Oracle. (2025). GraalVM Native Image Documentation. https://www.graalvm.org/latest/reference-manual/native-image/
6. FastMCP Contributors. (2025). FastMCP: Running a FastMCP Server. https://gofastmcp.com/deployment/running-server
7. Grafana Labs. (2025). k6 Load Testing Documentation. https://k6.io/docs/
8. deadpool-redis contributors. (2025). deadpool-redis crate documentation. https://docs.rs/deadpool-redis
9. Bun Team. (2025). Bun JavaScript Runtime. https://bun.sh

9. Appendix

9.1 Raw Data and Complete Results

All raw benchmark data, including detailed results from all three runs, per-tool latency breakdowns, Docker stats logs, and k6 output files are available in the project repository:

9.2 Server Implementations

Complete source code for all 15 MCP server implementations:

• rust-server/: rmcp 0.17.0 implementation with json_response: true
• quarkus-server/: Quarkus MCP server (JVM and native Dockerfiles)
• go-server/: mcp-go implementation
• java-server/: Spring Boot MVC implementation
• java-vt-server/: Spring Boot Virtual Threads implementation
• java-webflux-server/: Spring Boot WebFlux implementation
• micronaut-server/: Micronaut MCP server (JVM and native Dockerfiles)
• nodejs-server/: Node.js Express implementation
• python-server/: FastMCP + Starlette implementation

9.3 Benchmark Suite

• benchmark/benchmark.js: k6 load testing script
• benchmark/run_benchmark.sh: automated benchmark orchestration
• benchmark/collect_stats.py: Docker stats collection
• benchmark/consolidate.py: results aggregation