gRPC With. Net Performance Created: 26 Mar 2026 Updated: 26 Mar 2026

gRPC Performance: Why You Should Reuse a gRPC Channel

1. What Is a gRPC Channel?

When your application (the client) wants to call a remote function on another application (the server), it first needs to establish a communication path between the two. In gRPC, this communication path is called a channel.

Think of a gRPC channel like a phone call. Before you can speak to someone, you need to dial their number, wait for them to pick up, and exchange some pleasantries to confirm you are both ready to talk. Only then can real conversation happen. The channel is exactly that: the established, ready-to-use connection between client and server.

In .NET, the channel is represented by the GrpcChannel class from the Grpc.Net.Client namespace:

using Grpc.Net.Client;

var channel = GrpcChannel.ForAddress("https://localhost:5001");

Once the channel is open, you can create a gRPC client from it and start making calls:

var client = new Greeter.GreeterClient(channel);
var reply = await client.SayHelloAsync(new HelloRequest { Name = "Alice" });

2. What Happens When You Open a Channel?

Opening a channel is not free. Under the hood, several expensive steps happen:

  1. A socket is opened — The operating system allocates a network socket, which is a low-level resource used for communication.
  2. A TCP connection is established — TCP is the reliable transport protocol used to send bytes across the internet. Establishing it requires multiple round trips (the "TCP handshake").
  3. TLS is negotiated — Because gRPC uses HTTP/2, it typically runs over HTTPS. TLS (Transport Layer Security) is a cryptographic protocol that ensures your data is private and tamper-proof. Negotiating it requires more round trips.
  4. An HTTP/2 connection is started — HTTP/2 is the protocol that gRPC messages travel over. Setting it up also requires handshaking.

All of these steps involve sending packets back and forth between the client and server over the network. Even on a fast local network, this takes time — typically several milliseconds. Over a real internet connection, it can be tens or even hundreds of milliseconds.

Real-world analogy: Imagine you need to ask your colleague 1,000 questions. You have two options: (A) walk to their desk once, sit down, and ask all 1,000 questions in one sitting, or (B) walk to their desk, ask one question, go back to your seat, walk again for the next question, and repeat 1,000 times. Option B is obviously ridiculous — but that's exactly what happens when you create a new channel for every gRPC call.

3. The Costly Mistake: Creating a New Channel Every Time

Beginners often write code like this:

// BAD — do NOT do this
for (int i = 0; i < 1000; i++)
{
using var channel = GrpcChannel.ForAddress("https://localhost:5001");
var client = new Monitor.MonitorClient(channel);
var response = await client.GetPerformanceAsync(new PerformanceStatusRequest
{
ClientName = $"client {i + 1}"
});
Console.WriteLine(response.CpuPercentageUsage);
}

What is happening here? For every single call in the loop:

  1. A new socket is opened
  2. A new TCP connection is established
  3. TLS is negotiated again from scratch
  4. HTTP/2 is re-initialized
  5. Then the actual gRPC call happens
  6. Then the channel is disposed (connection closed)

This is enormously wasteful. Instead of spending time doing useful work, most of the time is spent on connection setup and teardown. In practice, this can make your application 2x to 10x slower than it needs to be.

4. Channel vs. Client: What Should You Reuse?

This is a very common point of confusion. gRPC in .NET has two objects you work with:

  1. GrpcChannel — The actual network connection. This is the expensive object. You must reuse this.
  2. Monitor.MonitorClient (or any generated client class) — A thin wrapper around the channel. It provides strongly-typed C# methods that correspond to your .proto RPC definitions. This is cheap to create.

The generated client does not do any heavy network work itself. All the heavy lifting — managing the connection, sending bytes, receiving bytes — is done by the underlying GrpcChannel. The client is just a convenient API layer on top of the channel.

This means:

  1. ✅ Safe to create a new client object per call — it's cheap and thread-safe to do so.
  2. ❌ Do NOT create a new channel per call — it's expensive and defeats the purpose of gRPC.

5. Bad Example: New Channel Per Call

Let's look at a complete, runnable bad example. Imagine you have a gRPC server with a Monitor service and you want to call it 100 times from an API endpoint.

// BAD EXAMPLE — PerformanceController.cs
[HttpGet("initialized-client/{count}")]
public async Task<ResponseModel> GetPerformanceFromNewClient(int count)
{
var stopWatch = Stopwatch.StartNew();
var response = new ResponseModel();
var serverUrl = "https://localhost:5001";

for (var i = 0; i < count; i++)
{
// A brand new channel (TCP + TLS + HTTP/2) created every iteration
using var channel = GrpcChannel.ForAddress(serverUrl);
var client = new Monitor.MonitorClient(channel);

var grpcResponse = await client.GetPerformanceAsync(new PerformanceStatusRequest
{
ClientName = $"client {i + 1}"
});

response.PerformanceStatuses.Add(new ResponseModel.PerformanceStatusModel
{
CpuPercentageUsage = grpcResponse.CpuPercentageUsage,
MemoryUsage = grpcResponse.MemoryUsage,
ProcessesRunning = grpcResponse.ProcessesRunning,
ActiveConnections = grpcResponse.ActiveConnections
});
}

response.RequestProcessingTime = stopWatch.ElapsedMilliseconds;
return response;
}

The problem is the using var channel = GrpcChannel.ForAddress(serverUrl) line inside the loop. Every iteration opens and closes a full network connection. With 1,000 calls, this took approximately 25 seconds in tests.

6. Good Example: Reuse the Channel

The fix is straightforward: create the channel once and reuse it for all calls. Here is a proper wrapper class that does this:

// GrpcPerformanceClient.cs
using System;
using System.Threading.Tasks;
using Grpc.Net.Client;
using Performance;

namespace ApiGateway
{
public interface IGrpcPerformanceClient
{
Task<ResponseModel.PerformanceStatusModel> GetPerformanceStatus(string clientName);
}

internal class GrpcPerformanceClient : IGrpcPerformanceClient, IDisposable
{
private readonly GrpcChannel channel;

// Channel is created ONCE when the wrapper is instantiated
public GrpcPerformanceClient(string serverUrl)
{
channel = GrpcChannel.ForAddress(serverUrl);
}

public async Task<ResponseModel.PerformanceStatusModel> GetPerformanceStatus(string clientName)
{
// A new client is created per call — this is fine, it is cheap
var client = new Monitor.MonitorClient(channel);

var response = await client.GetPerformanceAsync(new PerformanceStatusRequest
{
ClientName = clientName
});

return new ResponseModel.PerformanceStatusModel
{
CpuPercentageUsage = response.CpuPercentageUsage,
MemoryUsage = response.MemoryUsage,
ProcessesRunning = response.ProcessesRunning,
ActiveConnections = response.ActiveConnections
};
}

// Channel is disposed when the wrapper itself is disposed
public void Dispose()
{
channel.Dispose();
}
}
}

And the controller endpoint that uses this wrapper:

// BAD EXAMPLE replaced with GOOD EXAMPLE — same controller
[HttpGet("client-wrapper/{count}")]
public async Task<ResponseModel> GetPerformanceFromClientWrapper(int count)
{
var stopWatch = Stopwatch.StartNew();
var response = new ResponseModel();

for (var i = 0; i < count; i++)
{
// The channel is already open — only the actual gRPC call is made here
var grpcResponse = await clientWrapper.GetPerformanceStatus($"client {i + 1}");
response.PerformanceStatuses.Add(grpcResponse);
}

response.RequestProcessingTime = stopWatch.ElapsedMilliseconds;
return response;
}

With 1,000 calls, this version took approximately 15 seconds — 40% faster than the bad example, just by keeping the channel open.

7. Best Practice: Register as Singleton

In a real ASP.NET Core application, the correct way to manage the channel lifetime is to register your wrapper class as a singleton in the dependency injection container. A singleton lives for the entire lifetime of the application, which means the channel is created once at startup and reused by every request.

// Program.cs (or Startup.cs — ConfigureServices method)
builder.Services.AddSingleton<IGrpcPerformanceClient>(provider =>
new GrpcPerformanceClient(builder.Configuration["ServerUrl"]));

Now any controller or service that needs to make gRPC calls simply asks for IGrpcPerformanceClient via constructor injection, and the framework provides the same singleton instance every time:

public class PerformanceController : ControllerBase
{
private readonly IGrpcPerformanceClient clientWrapper;

public PerformanceController(IGrpcPerformanceClient clientWrapper)
{
this.clientWrapper = clientWrapper;
}

// ... endpoints
}
Why singleton? Because a transient registration (default for services) would create a new wrapper instance — and therefore a new channel — for every HTTP request that comes in. That is nearly as bad as creating a new channel per gRPC call.

8. Performance Comparison

Here is a summary of the three approaches and their measured performance when making 1,000 sequential gRPC calls:

ApproachChannel Reused?Time (1,000 calls)
New channel per call (initialized-client)No~25 seconds
Framework factory client (AddGrpcClient)Yes, but framework-controlled~50 seconds
Custom wrapper with shared channel (client-wrapper)Yes, fully controlled~15 seconds

The surprising result is that the framework-provided factory client (registered via AddGrpcClient) actually performed worst, despite reusing a channel. The likely reason is that the framework applies additional configuration and overhead that is not optimized for high-frequency sequential calls.

The lesson is: when performance matters, control your own channel creation. Do not blindly trust the framework to do it optimally for your specific use case.

9. Summary

  1. A gRPC channel is an established network connection (socket + TCP + TLS + HTTP/2). It is expensive to create.
  2. Creating a new channel per call forces all that expensive setup to happen on every single call. This is a major performance mistake.
  3. The gRPC client object (e.g., Monitor.MonitorClient) is just a thin wrapper. It is safe and cheap to create per call. The channel underneath is what matters.
  4. Reuse the channel by storing it as a singleton — either in a custom wrapper class or by ensuring your service that holds it is registered as a singleton in ASP.NET Core's DI container.
  5. Even though AddGrpcClient is convenient, it may not give you the best performance. For maximum control and speed, wrap the channel yourself.


Share this lesson:

Details

Category
gRPC With. Net
Sub: Performance
View All Courses Back to Lessons

Navigation

Progress 7 / 15
Start 47% Complete
Referencing Other Proto Files — A Beginner's Guide gRPC Performance: How to Not Get Held Up by the Concurrent Stream Limit
Statistics
5 Lessons in Performance
3 SubCategories in gRPC With. Net
15 Total Lessons in gRPC With. Net