Red Creation Technology Blog: 告别JSON瓶颈：使用MessagePack为.NET应用提升13倍性能实战

June 12, 2025

By: Kevin

告别JSON瓶颈：使用MessagePack为.NET应用提升13倍性能实战

问题浮现：高频数据传输下的性能危机
为什么JSON会成为瓶颈？
在JSON内部的优化尝试及其局限性
解决方案：更快更小的MessagePack
迁移实战：从JSON到MessagePack

1. 集成MessagePack库
2. 更新数据模型
3. 封装序列化器
4. 更新数据发送与接收逻辑

惊人的成果：性能对比见真章
总结：一次小改动，一次大飞跃

在开发高性能应用，尤其是涉及到高频数据传输的场景时，序列化格式的选择至关重要。本文将通过一个真实的案例，展示如何将一个.NET材料测试平台的数据传输模块从 JSON 迁移到 MessagePack，并最终实现超过 13倍 的惊人性能提升。

问题浮现：高频数据传输下的性能危机

我们的材料测试平台需要在硬件和数据监控端之间以极高的频率（数百Hz）实时传输复杂的结构化数据（CDataBlock）。最初，我们选用了易于读写的JSON作为序列化格式。然而，在性能分析中，我们发现CPU占用率居高不下，主要瓶颈集中在：

List<T>.set_Capacity()
List<T>.EnsureCapacity()

这清晰地表明，JSON反序列化过程中频繁的内存分配和List<T>扩容操作，导致了严重的性能问题和GC（垃圾回收）压力。对于一个要求低延迟和高吞吐的系统来说，这是不可接受的。

为什么JSON会成为瓶颈？

JSON虽然具有出色的可读性和通用性，但在性能敏感的场景下，其缺点也同样明显：

文本格式的开销：作为文本格式，JSON需要对字符串进行大量解析和转换，这在CPU层面是昂贵的。
体积庞大：JSON包含了大量的冗余字符（如 {}、[]、" 和属性名），导致传输的数据包体积较大，占用了更多网络带宽。
内存分配：反序列化时会创建大量的小对象和字符串，给GC带来了巨大压力，这也是我们最初发现List容量问题的根源。

在JSON内部的优化尝试及其局限性

在决定彻底更换方案之前，我们首先尝试在 System.Text.Json 框架内进行深度优化，希望能压榨出更多性能。我们的尝试包括：

优化配置：使用共享的、预配置的 JsonSerializerOptions 实例。
内存池优化：利用 ArrayPool<T> 来租用和回收用于反序列化的缓冲区，以减少内存分配和GC压力。
使用源生成器 (Source Generators)：这是.NET推荐的高性能方案，它可以在编译时生成无反射的序列化代码。

我们针对这些优化方案进行了测试，但结果并不理想。

 === 默认反序列化结果 ===
 ServoChCount: 2
 ServoData Length: 2
 InCount: 8
 BitIn Length: 8
 ADCount: 5
 ADData Length: 5
 
 === 优化反序列化结果 ===
 ServoChCount: 2
 ServoData Length: 2
 InCount: 8
 BitIn Length: 8
 ADCount: 5
 ADData Length: 5


  已通过 Test_OptimizedDeserialization_CorrectArraySizes [31 ms]
  标准输出消息:
 ✅ 所有数组大小验证通过


测试数据大小: 170.44 KB

=== 实际性能优化测试结果 (测试次数: 500) ===
1. 默认反序列化:
   总时间: 1522ms
   平均时间: 3.04ms/次

2. 优化配置:
   总时间: 1435ms
   平均时间: 2.87ms/次
   性能提升: 1.06x

3. 内存池优化:
   总时间: 1406ms
   平均时间: 2.81ms/次
   性能提升: 1.08x

4. 源生成器:
   总时间: 1423ms
   平均时间: 2.85ms/次
   性能提升: 1.07x

  已通过 Test_RealWorld_DeserializationOptimizations [5 s]
  标准输出消息:
 测试数据大小: 170.44 KB
 
 === 实际性能优化测试结果 (测试次数: 500) ===
 1. 默认反序列化:
    总时间: 1522ms
    平均时间: 3.04ms/次
 
 2. 优化配置:
    总时间: 1435ms
    平均时间: 2.87ms/次
    性能提升: 1.06x
 
 3. 内存池优化:
    总时间: 1406ms
    平均时间: 2.81ms/次
    性能提升: 1.08x
 
 4. 源生成器:
    总时间: 1423ms
    平均时间: 2.85ms/次
    性能提升: 1.07x


  已通过 Abs_Array_ReturnsCorrectResult [1 ms]
  已通过 Abs_Number_ReturnsCorrectResult(-10.6d) [< 1 ms]
  已通过 Abs_Number_ReturnsCorrectResult(10.6d) [< 1 ms]
  已通过 Ceiling_Array_ReturnsCorrectResult [< 1 ms]
  已通过 Ceiling_Number_ReturnsCorrectResult(-10.6d) [< 1 ms]
  已通过 Ceiling_Number_ReturnsCorrectResult(10.6d) [< 1 ms]
  已通过 Floor_Array_ReturnsCorrectResult [< 1 ms]
  已通过 Floor_Number_ReturnsCorrectResult(-10.6d) [< 1 ms]
  已通过 Floor_Number_ReturnsCorrectResult(10.6d) [< 1 ms]
  已通过 GetDBSignalVars [< 1 ms]
  已通过 Round_Array_ReturnsCorrectResult [< 1 ms]
  已通过 Round_Number_ReturnsCorrectResult(4.3d) [< 1 ms]
  已通过 Round_Number_ReturnsCorrectResult(4.8d) [< 1 ms]
  已通过 Round_Number_ReturnsCorrectResult(-4.3d) [< 1 ms]
  已通过 Round_Number_ReturnsCorrectResult(-4.8d) [< 1 ms]
  已通过 Sign_Array_ReturnsCorrectResult [< 1 ms]
  已通过 Sign_Number_ReturnsCorrectResult(-10.6d) [< 1 ms]
  已通过 Sign_Number_ReturnsCorrectResult(0) [< 1 ms]
✅ 数组大小验证通过

测试数据大小: 8.81 KB

=== 性能对比测试结果 (测试次数: 1000) ===
1. 默认反序列化:
   总时间: 188ms
   平均时间: 0.188ms/次

2. 优化配置:
   总时间: 147ms
   平均时间: 0.147ms/次
   性能提升: 1.28x

3. 内存池优化:
   总时间: 141ms
   平均时间: 0.141ms/次
   性能提升: 1.33x

4. 源生成器:
   总时间: 135ms
   平均时间: 0.135ms/次
   性能提升: 1.39x

🏆 最佳方案: 源生成器

NUnit Adapter 4.0.0.0: Test execution complete
  已通过 Sign_Number_ReturnsCorrectResult(10.6d) [< 1 ms]
  已通过 Truncate_Array_ReturnsCorrectResult [< 1 ms]
  已通过 Truncate_Number_ReturnsCorrectResult(-10.6d) [< 1 ms]
  已通过 Truncate_Number_ReturnsCorrectResult(10.6d) [< 1 ms]
  已通过 Test_ArraySizesAreCorrect [89 ms]
  标准输出消息:
 ✅ 数组大小验证通过


  已通过 Test_JsonDeserializationPerformance [620 ms]
  标准输出消息:
 测试数据大小: 8.81 KB
 
 === 性能对比测试结果 (测试次数: 1000) ===
 1. 默认反序列化:
    总时间: 188ms
    平均时间: 0.188ms/次
 
 2. 优化配置:
    总时间: 147ms
    平均时间: 0.147ms/次
    性能提升: 1.28x
 
 3. 内存池优化:
    总时间: 141ms
    平均时间: 0.141ms/次
    性能提升: 1.33x
 
 4. 源生成器:
    总时间: 135ms
    平均时间: 0.135ms/次
    性能提升: 1.39x
 
 🏆 最佳方案: 源生成器

JSON 内部优化测试结果 (反序列化耗时):
1. 默认实现: 3.04ms/次
2. 优化配置: 2.87ms/次 (性能提升 1.06倍)
3. 内存池优化: 2.81ms/次 (性能提升 1.08倍)
4. 源生成器: 2.85ms/次 (性能提升 1.07倍)

从测试结果可以看出，即使是采用了源生成器这样的“大杀器”，性能提升也不足10%。这证明了问题的根源在于JSON这种文本格式本身，单纯在实现层面进行优化已无法带来质的飞跃。

解决方案：更快更小的MessagePack

既然在JSON框架内的优化收效甚微，我们决定从根本上改变方案，引入二进制序列化格式 MessagePack。它被誉为“像JSON，但更快更小”（It's like JSON, but fast and small）。

MessagePack的核心优势在于：

二进制格式：数据被编码为紧凑的二进制流，无需复杂的文本解析，处理速度极快。
体积小巧：相比JSON，MessagePack序列化后的数据体积大幅减小，能有效降低网络I/O开销。
高效内存利用：二进制格式的处理方式更为直接，可以显著减少对象分配和内存拷贝，从而降低GC压力。

迁移实战：从JSON到MessagePack

整个迁移过程非常直接，主要分为以下几个步骤：

1. 集成MessagePack库

首先，在我们的核心库项目（FuncLibs.csproj）中添加对MessagePack的引用。

<PackageReference Include="MessagePack" Version="3.1.3" />

2. 更新数据模型

接下来，为需要序列化的数据类（如 CDataBlock, CData 等）添加MessagePack的特性。这非常简单，只需添加 [MessagePackObject] 和 [Key(n)]。

// using MessagePack;

[MessagePackObject]
public class CDataBlock
{
    [Key(0)]
    public SingleChDatas[]? ServoData { set; get; }
    [Key(1)]
    public SingleChDatas[]? TempData { set; get; }
    // ... 其他属性
    [Key(6)]
    public int ServoChCount { set; get; }
}

[MessagePackObject]
public class CData
{
    [Key(0)]
    public short ActiveCtrl { set; get; }
    [Key(1)]
    public double Command { set; get; }
    // ... 其他属性
}

3. 封装序列化器

为了方便统一管理，我们创建了一个静态的 MessagePackSerializer 帮助类，并配置了LZ4压缩以进一步优化数据体积。

// /FuncLibs/MessagePackSerializer.cs
public static class MessagePackSerializer
{
    // 配置高性能选项，并启用LZ4压缩
    private static readonly MessagePackSerializerOptions _options =
        MessagePackSerializerOptions.Standard
            .WithResolver(CompositeResolver.Create(...))
            .WithCompression(MessagePackCompression.Lz4BlockArray);

    public static byte[] Serialize<T>(T data)
    {
        return MessagePack.MessagePackSerializer.Serialize(data, _options);
    }

    public static T Deserialize<T>(byte[] data)
    {
        return MessagePack.MessagePackSerializer.Deserialize<T>(data, _options);
    }
}

4. 更新数据发送与接收逻辑

最后，我们修改了数据发送和接收端的代码，将其从处理JSON字符串改为处理MessagePack的二进制字节数组。

发送端修改 (HardwareConnector/EventHandlers.cs)：

// --- 修改前 ---
// var s = JsonSerializer.Serialize(FilterCDataBlockByCount(DataBlock), _jsonOptions);
// msg.Append(s);

// +++ 修改后 +++
// 使用MessagePack进行高性能序列化，输出二进制数据
var filteredData = FilterCDataBlockByCount(DataBlock);
var messagePackBytes = Consts.MessagePackSerializer.Serialize(filteredData);
msg.Append(messagePackBytes);

接收端修改 (SignalVar/Examples.cs)：

// --- 修改前 ---
// var msg = sub.ReceiveFrameString();
// var block = JsonSerializer.Deserialize<CDataBlock>(msg, options);

// +++ 修改后 +++
var msg = sub.ReceiveFrameBytes(); // 接收二进制数据而不是字符串
var block = Consts.MessagePackSerializer.Deserialize<CDataBlock>(msg);

惊人的成果：性能对比见真章

为了验证优化的效果，我们创建了详细的性能对比测试（SerializationPerformanceTest.cs）。测试结果令人振奋，各项指标均有大幅提升。

测试环境: .NET 6, macOS, CDataBlock 包含多个嵌套数组，模拟真实业务数据。
测试数据大小:
JSON: 553 KB
MessagePack: 91 KB (压缩率 83.6%！)

=== 序列化性能对比测试 (迭代次数: 1000) ===
测试数据复杂度:
  - ServoData: 8 通道 x 100 数据点 x 8 传感器
  - TempData: 6 通道 x 50 数据点 x 4 传感器
  - ADData: 16 通道 x 200 数据点
  - BitIn/Out: 32/32 位

📊 性能测试结果:

🔄 序列化性能:
  JSON:        11078ms (平均: 11.078ms/次)
  MessagePack: 733ms (平均: 0.733ms/次)
  性能提升:    15.11x

🔄 反序列化性能:
  JSON:        12846ms (平均: 12.846ms/次)
  MessagePack: 1005ms (平均: 1.005ms/次)
  性能提升:    12.78x

📦 数据大小对比:
  JSON:        566,351 bytes (553.08 KB)
  MessagePack: 92,813 bytes (90.64 KB)
  压缩比:      0.16 (MessagePack占JSON的16.4%)
  节省空间:    473,538 bytes (83.6%)

🏆 总体性能提升: 13.77x
🎉 MessagePack比JSON总体快了 92.7%

以下是优化前后的详细性能对比数据：

性能指标	JSON (原始)	MessagePack (优化后)	性能提升
序列化平均耗时	11.08 ms	0.73 ms	15.11 倍
反序列化平均耗时	12.85 ms	1.01 ms	12.78 倍
数据大小	553 KB	91 KB	压缩 83.6%
内存使用	基准	节省 16.0%	显著降低
总体性能	基准	比JSON快 92.7%	13.77 倍

从结果可以看出，MessagePack不仅在序列化和反序列化速度上分别带来了 15.11倍 和 12.78倍 的提升，还将数据体积压缩了惊人的 83.6%。这直接解决了我们最初遇到的CPU瓶颈和内存问题。

总结：一次小改动，一次大飞跃

通过将序列化方案从JSON迁移到MessagePack，我们以极小的代码改动成本，换来了系统性能的巨大飞跃。这次优化不仅彻底解决了高频数据传输下的性能瓶颈，还大幅降低了网络带宽和内存消耗。

如果你的.NET应用也面临类似的性能挑战，特别是在微服务、物联网(IoT)或实时通信等场景下，那么将MessagePack纳入你的技术栈，无疑是一项高回报率的明智之选。🚀

Tags: performance

« 告别GC：优化数据结构, .NET高性能扁平化重构实战某系统的二十关键设计决定 »