为何我的gRPC比Minimal API慢数倍？求排查优化方案

一、Minimal API 未实现真正流式输出的原因及修复 #

你的UI端等待全量加载后才打印，核心问题在于ReadFromJsonAsync<IAsyncEnumerable<Sales>>并非真正的流式反序列化——该方法会先缓冲整个HTTP响应内容，再一次性反序列化为IAsyncEnumerable，导致客户端必须等所有数据传输完成才能开始处理。

后端代码修复 #

要让Minimal API真正流式输出，需明确使用System.Text.Json的异步流式序列化能力，修改后端MapGet的实现：

app.MapGet("/test", async (HttpContext context) =>
{
    context.Response.ContentType = "application/json";
    await JsonSerializer.SerializeAsync(context.Response.Body, MakeHttpCall(), new JsonSerializerOptions
    {
        WriteIndented = false // 关闭缩进提升性能
    });
});

UI端代码修复 #

客户端需要直接读取响应流，并用JsonSerializer.DeserializeAsyncEnumerable实现流式反序列化：

using HttpClient client = new();
using HttpResponseMessage response = await client.GetAsync(
    "http://localhost:5247/test",
    HttpCompletionOption.ResponseHeadersRead
).ConfigureAwait(false);

response.EnsureSuccessStatusCode();
await using var stream = await response.Content.ReadAsStreamAsync().ConfigureAwait(false);

var count = 0;
var watch = System.Diagnostics.Stopwatch.StartNew();

await foreach (var each in JsonSerializer.DeserializeAsyncEnumerable<Sales>(stream))
{
    if (each == null) continue;
    Console.WriteLine($"New Order Receieved from {each.Country}-{each.Region}, Order ID = {each.TotalRevenue}");
    count++;
}

watch.Stop();
Console.WriteLine($"Processed {count} items in {watch.Elapsed.TotalSeconds:F2} seconds");

二、gRPC 性能低于预期的排查方向 #

gRPC理论上在流式场景下性能优于普通HTTP API，你的情况大概率是代码或配置问题，可从以下几点排查：

1. 确认gRPC是否启用HTTP/2 #

gRPC依赖HTTP/2实现高效流式传输，若服务器或客户端未配置HTTP/2，会降级为HTTP/1.1，导致性能暴跌：

• 服务器端：.NET 6中gRPC默认启用HTTP/2，但需确保Kestrel配置中未强制禁用：

  // Program.cs 中的Kestrel配置示例
  builder.WebHost.ConfigureKestrel(options =>
  {
      options.ListenAnyIP(5001, o => o.UseHttps().Protocols(HttpProtocols.Http2));
  });
  

• 客户端：确保gRPC客户端使用支持HTTP/2的通道，比如：

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

2. 检查gRPC流式实现是否正确 #

• 确认你的gRPC服务是服务器流式RPC（定义中用stream修饰返回值）：

  rpc StreamSales (EmptyRequest) returns (stream SalesResponse);
  

• 服务器端需逐个发送消息，而非批量缓存后一次性发送。若你的gRPC代码中存在将多个SalesResponse缓存到集合再返回的逻辑，会完全丧失流式优势。

3. 序列化方式与消息大小 #

• gRPC默认使用Protobuf序列化，若错误配置为JSON序列化，性能会大幅下降。检查.proto文件是否正确定义了消息类型，且客户端/服务器未强制使用JSON。
• 若单条Sales数据过大，可考虑拆分或启用gRPC的消息压缩：

  // 客户端启用压缩
  var channel = GrpcChannel.ForAddress("https://localhost:5001", new GrpcChannelOptions
  {
      CompressionProviders = new[] { new GzipCompressionProvider(CompressionLevel.Optimal) }
  });
  

4. 性能测试的公平性 #

• 确保两次测试的硬件、网络环境一致（比如本地测试时关闭其他占用资源的程序）。
• 检查gRPC测试中是否包含额外的逻辑（比如日志、拦截器），这些会增加耗时。

三、额外优化建议 #

• 对于Minimal API的流式场景，可考虑使用application/x-ndjson（换行分隔JSON）格式，解析效率更高，客户端可逐行读取反序列化。
• gRPC流式传输时，若单条数据过小，可考虑批量发送（比如每100条打包成一个Protobuf消息），减少HTTP/2的头部开销，提升整体性能。

内容的提问来源于stack exchange，提问作者AntiMatter