Find the Best Cosmetic Hospitals

Explore trusted cosmetic hospitals and make a confident choice for your transformation.

โ€œInvest in yourself โ€” your confidence is always worth it.โ€

Explore Cosmetic Hospitals

Start your journey today โ€” compare options in one place.

DOTNET: RPC with GRPC and REST and its Performance Impact

Below is a complete, runnable .NET 8 demo where:

  • One server exposes:
    • A REST (JSON) endpoint
    • A gRPC (Protobuf) endpoint
  • One console client:
    • Sends N requests to REST
    • Sends N requests to gRPC
    • Prints total time, average latency, and payload sizes

Youโ€™ll be able to feel the difference.


1. Solution structure

Weโ€™ll build this:

RpcPerfDemo/
  RpcPerfDemo.sln
  RpcPerfDemo.Server/     (ASP.NET Core โ€“ REST + gRPC)
    Program.cs
    Services/
      PerfServiceImpl.cs
    Models/
      RestPerfResponse.cs
    Protos/
      perf.proto
    RpcPerfDemo.Server.csproj
  RpcPerfDemo.Client/     (Console โ€“ benchmark client)
    Program.cs
    RpcPerfDemo.Client.csproj

Target: .NET 8.0 (works with future .NET 10+ too).


2. Step-by-step setup

โœ… Step 0 โ€“ Prerequisites

  • Install .NET 8 SDK dotnet --version Make sure it shows 8.x.x.
  • Ensure dev HTTPS cert is trusted (only needed once): dotnet dev-certs https --trust

โœ… Step 1 โ€“ Create solution + projects

mkdir RpcPerfDemo
cd RpcPerfDemo

# Create solution
dotnet new sln -n RpcPerfDemo

# Create server (web app)
dotnet new web -n RpcPerfDemo.Server

# Create client (console app)
dotnet new console -n RpcPerfDemo.Client

# Add to solution
dotnet sln add RpcPerfDemo.Server/RpcPerfDemo.Server.csproj
dotnet sln add RpcPerfDemo.Client/RpcPerfDemo.Client.csproj
Code language: PHP (php)

โœ… Step 2 โ€“ Add packages

Server packages

cd RpcPerfDemo.Server
dotnet add package Grpc.AspNetCore
dotnet add package Grpc.Tools
dotnet add package Google.Protobuf
cd ..
Code language: CSS (css)

Client packages

cd RpcPerfDemo.Client
dotnet add package Grpc.Net.Client
dotnet add package Grpc.Tools
dotnet add package Google.Protobuf
cd ..
Code language: CSS (css)

โœ… Step 3 โ€“ Define the Protobuf contract

Create folder and file:

mkdir -p RpcPerfDemo.Server/Protos

Create RpcPerfDemo.Server/Protos/perf.proto:

syntax = "proto3";

option csharp_namespace = "RpcPerfDemo.Grpc";

package perf;

// Request for performance test
message PerfRequest {
  int32 id = 1;
  string name = 2;
}

// Response from server
message PerfResponse {
  int32 id = 1;
  string name = 2;
  repeated int32 values = 3;
  int64 processedAtTicks = 4;
}

// gRPC service
service PerfService {
  rpc GetData(PerfRequest) returns (PerfResponse);
}
Code language: JavaScript (javascript)

โœ… Step 4 โ€“ Wire proto into both projects

4.1 Server .csproj

Open RpcPerfDemo.Server/RpcPerfDemo.Server.csproj and make it look like this (keep your PropertyGroup as generated, just ensure these ItemGroups exist):

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Grpc.AspNetCore" Version="*" />
    <PackageReference Include="Grpc.Tools" Version="*">
      <PrivateAssets>All</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Google.Protobuf" Version="*" />
  </ItemGroup>

  <ItemGroup>
    <Protobuf Include="Protos\perf.proto" GrpcServices="Server" />
  </ItemGroup>

</Project>
Code language: HTML, XML (xml)

Version="*" is fine โ€“ the real versions were already resolved by dotnet add package.

4.2 Client .csproj

Open RpcPerfDemo.Client/RpcPerfDemo.Client.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Grpc.Net.Client" Version="*" />
    <PackageReference Include="Grpc.Tools" Version="*">
      <PrivateAssets>All</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Google.Protobuf" Version="*" />
  </ItemGroup>

  <!-- Reuse the same proto for client stubs -->
  <ItemGroup>
    <Protobuf Include="..\RpcPerfDemo.Server\Protos\perf.proto"
              Link="Protos\perf.proto"
              GrpcServices="Client" />
  </ItemGroup>

</Project>
Code language: HTML, XML (xml)

โœ… Step 5 โ€“ Implement the server (REST + gRPC)

5.1 REST model

Create folder:

mkdir -p RpcPerfDemo.Server/Models

Create RpcPerfDemo.Server/Models/RestPerfResponse.cs:

namespace RpcPerfDemo.Server.Models;

public class RestPerfResponse
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public List<int> Values { get; set; } = new();
    public long ProcessedAtTicks { get; set; }
}
Code language: JavaScript (javascript)

5.2 gRPC service implementation

Create folder:

mkdir -p RpcPerfDemo.Server/Services

Create RpcPerfDemo.Server/Services/PerfServiceImpl.cs:

using Grpc.Core;
using RpcPerfDemo.Grpc;

namespace RpcPerfDemo.Server.Services;

public class PerfServiceImpl : PerfService.PerfServiceBase
{
    public override Task<PerfResponse> GetData(PerfRequest request, ServerCallContext context)
    {
        // Simulate some CPU work
        var values = Enumerable.Range(0, 200).ToList();

        var response = new PerfResponse
        {
            Id = request.Id,
            Name = request.Name,
            ProcessedAtTicks = DateTime.UtcNow.Ticks
        };
        response.Values.AddRange(values);

        return Task.FromResult(response);
    }
}
Code language: HTML, XML (xml)

5.3 Minimal API + gRPC configuration

Replace RpcPerfDemo.Server/Program.cs with:

using RpcPerfDemo.Server.Models;
using RpcPerfDemo.Server.Services;

var builder = WebApplication.CreateBuilder(args);

// Add gRPC services
builder.Services.AddGrpc();

var app = builder.Build();

// Map REST endpoint
app.MapGet("/rest/perf", () =>
{
    // Simulate some work, similar to gRPC
    var values = Enumerable.Range(0, 200).ToList();

    var response = new RestPerfResponse
    {
        Id = 1,
        Name = "REST-JSON",
        Values = values,
        ProcessedAtTicks = DateTime.UtcNow.Ticks
    };

    return Results.Ok(response);
});

// Map gRPC endpoint
app.MapGrpcService<PerfServiceImpl>();

// Optional health check endpoint
app.MapGet("/", () => "RPC Performance Demo Server (REST + gRPC)");

app.Run();
Code language: PHP (php)

ASP.NET Core will host both REST and gRPC on the same app and ports.


โœ… Step 6 โ€“ Implement the benchmark client

Replace RpcPerfDemo.Client/Program.cs with:


3. Build and run

โœ… Step 7 โ€“ Build everything

From the solution root (RpcPerfDemo):

dotnet build

You should see Build succeeded.


โœ… Step 8 โ€“ Run the server

From the solution root:

dotnet run --project RpcPerfDemo.Server
Code language: CSS (css)

Youโ€™ll see output similar to:

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5000
Code language: JavaScript (javascript)
  • Confirm https://localhost:5001 is there.
  • If it prints a different HTTPS port, either:
    • Change ServerAddress constant in the client, or
    • Set ASPNETCORE_URLS: set ASPNETCORE_URLS=https://localhost:5001;http://localhost:5000 # Windows export ASPNETCORE_URLS="https://localhost:5001;http://localhost:5000" # Linux/macOS
    and re-run the server.

Leave the server running.

You can quickly test the REST endpoint in a browser:

  • Visit: https://localhost:5001/rest/perf
    You should see JSON like:
{
  "id": 1,
  "name": "REST-JSON",
  "values": [...],
  "processedAtTicks": 638000000000000000
}
Code language: JSON / JSON with Comments (json)

โœ… Step 9 โ€“ Run the client benchmark

In a new terminal, from solution root:

dotnet run --project RpcPerfDemo.Client
Code language: CSS (css)

You should see something like:

=== RPC Performance Demo: REST vs gRPC ===
Server address: https://localhost:5001
Total requests per style: 1000

Warming up REST endpoint...
Sample REST JSON payload size: 2350 bytes
Running REST benchmark...
REST total time: 950.32 ms for 1000 requests
REST avg per request: 0.9503 ms

Warming up gRPC endpoint...
Sample gRPC Protobuf payload size: 640 bytes
Running gRPC benchmark...
gRPC total time: 480.15 ms for 1000 requests
gRPC avg per request: 0.4802 ms

Done.
Code language: JavaScript (javascript)

(Exact numbers will vary by machine.)


4. How to interpret the results

Youโ€™ll get two kinds of insights:

1๏ธโƒฃ Payload size

From log:

  • REST JSON payload size โ€“ e.g. 2350 bytes
  • gRPC Protobuf payload size โ€“ e.g. 640 bytes

๐Ÿ‘‰ This shows gRPC messages are much smaller, even for the same data (id, name, 200 ints, timestamp).

Smaller payloads โ†’ less bandwidth โ†’ better performance, especially over slow networks.


2๏ธโƒฃ Latency per request

Youโ€™ll see:

  • REST total time and REST avg per request
  • gRPC total time and gRPC avg per request

Typically:

  • gRPC average per request will be lower
  • Total time for N requests will also be lower

On localhost the difference may be modest, but:

  • Add more iterations (Iterations = 10000)
  • Or run on separate machines
  • Or add more data in values (e.g. Enumerable.Range(0, 2000))

โ†’ youโ€™ll see gRPC scaling better.


5. What you just experienced

  • Same server, same business logic size, same data.
  • REST vs gRPC differ only in:
    • Data format (JSON vs Protobuf)
    • Protocol (HTTP/1.1 vs HTTP/2)
  • Your measurements showed:
    • gRPC = smaller payloads
    • gRPC = lower average latency & total time

This is exactly the impact you care about for:

  • High-throughput microservices
  • Telemetry, streaming, real-time APIs
  • Cloud Run โ†’ EKS migration with full gRPC support

Find Trusted Cardiac Hospitals

Compare heart hospitals by city and services โ€” all in one place.

Explore Hospitals
I'm Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms. I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.

Related Posts

OWASP Dependency-Check โ€” 1-Hour Quick Demo Lab

Level: Beginner / Basic DevSecOpsDuration: 60 minutesFormat: Instructor-led hands-on demoFocus: Install โ†’ scan a real project โ†’ read findings โ†’ understand CVE/CVSS โ†’ generate reports โ†’ demonstrate a simple security gate…

Read More

OWASP Dependency-Checkย – Hands-On Lab Manual

OWASP Dependency-Check 13.0.0 Basic-to-Essentials Hands-On Lab Manual Audience: Beginners and engineers with basic DevOps/DevSecOps knowledgeTutorial verified/researched on: 2026-10-03OWASP Dependency-Check version: 13.0.0Minimum Java supported by Dependency-Check: Java 11Recommended lab Java runtime: Java 17…

Read More

Manufacturing automation: Is it worth investing in the field of manufacturing automation?

An investment in manufacturing automation can pay off. (Photo: Generated with the help of AI) Manufacturing automation has developed from a solution mainly associated with large factories…

Read More

How to Choose a Virtual Machine for Development and Production Workloads

Virtual machines remain a practical building block for development, testing, staging, production services, and infrastructure automation. The challenge is not simply choosing the largest instance available. It…

Read More

System Mechanic vs Advanced SystemCare for Small Teams Without an MDM

If you’re keeping a handful of Windows workstations or test machines healthy without a device-management platform, iolo’s System Mechanic is the better choice over IObit’s Advanced SystemCare…

Read More

How to Plan Infrastructure for a Community Project

Every thriving community project sits on top of infrastructure nobody notices, right up until it breaks. The forum. The server. The backups. The dull plumbing that holds…

Read More
Subscribe
Notify of
guest
2 Comments
Newest
Oldest Most Voted
Skylar Bennett
Skylar Bennett
9 months ago

This blog provides a clear comparison of gRPC and REST in .NET applications, helping readers understand how communication choices can impact performance, scalability, and system design. The explanation of protocol behavior, serialization, and network efficiency offers valuable insight for architects and developers working on distributed systems. By focusing on practical performance considerations rather than theory alone, the article makes it easier to choose the right approach based on real use cases. Overall, it is a helpful resource for teams aiming to build efficient, reliable, and well-designed service-to-service communication in modern .NET environments.

Jason Mitchell
Jason Mitchell
10 months ago

This article provides a clear, insightful comparison between gRPC and REST in the .NET world, especially highlighting how gRPCโ€™s binary protocol and strong typing can dramatically reduce latency and improve throughput compared to traditional REST/JSON calls. The discussion around serialization overhead, connection reuse, and how gRPC integrates with .NETโ€™s async ecosystem makes it evident why many performance-sensitive applications โ€” microservices, real-time systems, or high-volume APIs โ€” benefit from gRPCโ€™s efficiency. The examples and performance impact analysis help readers make realistic decisions about when to choose gRPC over REST, depending on their use-case. Overall โ€” a very practical and informative guide for any .NET team deciding between RPC and REST approaches.

2
0
Would love your thoughts, please comment.x
()
x