Deep Thought

Exercise Rest vs Grpc Loadtesting

4 min read

Exercise: Comparing REST and gRPC Performance with Benchmark.NET and k6

Goal of the exercise

The goal of this exercise is to systematically explore and understand the performance characteristics of REST vs gRPC in different scenarios.

By the end of this exercise, you should be able to answer questions such as:

  • In which situations does gRPC outperform REST, and why?
  • When is REST “good enough”, or even competitive?
  • How do payload shape and size influence performance?
  • How do serialization formats, protocols, and network effects impact latency, throughput, and bandwidth usage?
  • How do results differ between micro-benchmarks and load tests?

This exercise is intentionally open-ended: there is no single “correct” result. What matters is how you design your tests, how you measure, and how you interpret the data.

Starting point

You have already:

  • Implemented your first gRPC service
  • Written a C# client
  • Used Benchmark.NET to compare REST vs gRPC calls

In this exercise, you will extend this work into a more thorough performance investigation.

Part 1 – Design and implement test endpoints

Extend your server so that it exposes functionally equivalent endpoints via:

  • REST (HTTP/JSON)
  • gRPC (Protocol Buffers)

You should implement at least the following categories of endpoints:

  1. Simple / minimal endpoint

    • Very small request and response
    • Example: two numbers in, one number out

  2. Wide messages (many properties)

    • Messages with many scalar fields
    • Mix of integers, floating-point numbers, booleans, strings

  3. Nested / hierarchical messages

    • Objects containing objects
    • Lists of objects inside objects
    • Aim for realistic data models (e.g. orders, customers, measurements)

  4. Large payloads

    • Large arrays or collections
    • Focus on payload size and serialization cost rather than CPU-heavy logic

The business logic should stay intentionally simple. The focus is on data transfer and serialization, not algorithmic complexity.

Part 2 – Benchmark.NET (micro-benchmarks)

Use Benchmark.NET in a C# client to measure:

  • Mean execution time
  • Percentiles (p90, p95 if applicable)
  • Allocations (if relevant)

Design your benchmarks carefully:

  • Compare REST and gRPC calls for the same logical operation
  • Warm up the client properly
  • Avoid unnecessary work inside the benchmark method

Think about:

  • What exactly is being measured?
  • Is the benchmark dominated by serialization, networking, or framework overhead?
  • How stable are the results between runs?

Part 3 – Load testing with k6

Perform load tests using k6.

You are expected to:

  • Learn how to use k6 by reading the official documentation - start with Install k6
  • Design test scripts that exercise your endpoints under load
  • Decide how many virtual users (VUs), duration, and scenarios make sense

Do not treat this as a copy-paste task. Part of the exercise is figuring out:

  • How to model load
  • How to separate endpoints into scenarios
  • How to collect and interpret k6 metrics

Part 4 – Test environments

Required

  • Run all tests on one machine (client and server on localhost)

Optional (bonus / advanced)

  • Run the server on a separate machine or VM
  • Run the client from your local machine
  • Compare results between:
    • localhost tests
    • networked tests

Observe how network latency and bandwidth change the picture.

Important hints (read carefully)

  • Always use Release builds for server and client when measuring performance
    (Debug builds invalidate performance results)

  • Keep your machine as idle as possible during tests

  • Document:

    • CPU model
    • Number of cores
    • RAM
    • OS
    • .NET runtime version
    • Any relevant framework or library versions

  • Run benchmarks multiple times to check result stability

  • Be critical of “too good to be true” numbers

Part 5 – Report

You must compile a written report (Markdown or PDF).

The report should include:

  1. Introduction

    • What you wanted to find out
    • Why REST vs gRPC is an interesting comparison

  2. Test setup

    • Hardware and software environment
    • Server and client architecture
    • Description of endpoints
    • Tools used (Benchmark.NET, k6)

  3. Measurement methodology

    • How did you measure?
    • What exactly was measured?
    • What did you not measure?

  4. Results

    • Tables and/or charts
    • Separate results for:
      • Simple endpoints
      • Wide messages
      • Nested messages
      • Large payloads
    • Benchmark.NET vs k6 results

  5. Interpretation

    • Where does gRPC shine?
    • Where does REST perform similarly?
    • How does payload shape influence results?
    • Differences between localhost and networked tests

  6. Conclusion

    • Key takeaways
    • Practical recommendations
    • Open questions or ideas for further testing

Evaluation criteria

You will be evaluated on:

  • Quality of test design
  • Correctness and fairness of comparisons
  • Depth of analysis and interpretation
  • Clarity and structure of the report
  • Ability to reason about performance results

Raw numbers alone are not enough.
What matters most is whether you can explain why you see the results you see.

Final note

There is no “winner protocol” in this exercise.

Your task is to discover trade-offs, understand them, and explain them clearly.

Think like an engineer, not like a benchmark marketing slide.

Graph View

Backlinks