序列化性能差的可能解决方案答案

【问题标题】：Possible Solutions to Poor Serialization Performance序列化性能差的可能解决方案
【发布时间】：2010-12-02 01:03:20
【问题描述】：

我最近使用进程外会话状态对 ASP.NET 应用程序进行了一些性能测试和分析 - 在网络场上使用会话状态时这是必要的，以便可以在任何网络服务器上检索状态，例如如果后续 HTTP 请求由于会话不“粘”或原始服务器已关闭等而到达不同的服务器。

令我惊讶的是，当我以满负荷运行 Web 服务器并分析 CPU 使用率时，大约 99% 的 CPU 时间都用于序列化和反序列化会话状态。随后我们实现了一个定制的“缓存”状态服务器；这总是序列化状态，但也将状态保留在内存中，因此如果您使用粘性会话，则大多数时间都不必反序列化状态。这将服务器吞吐量提高了 2 倍；但是，序列化仍占 CPU 时间的 98% 或更多。

通过在序列化之前“修剪”会话状态中的对象之间不必要的对象引用，我们进一步提高了速度 - 在反序列化时手动修复引用。这将速度提高了 10-20% 左右。这里的原因是，一些性能损失是由于内置的序列化必须遍历对象指针的图，这变成了具有更多指针的更复杂的任务。

继续调查，我们为我们的一些类编写了定制的序列化例程，而不是依赖 .Net 的内置序列化。我们发现，性能大大提高了，提高了大约 50 倍。似乎大部分 CPU 负载是由内置的 .Net 序列化引起的，而由于依赖于使用反射来遍历对象指针/图形并提取字段数据，这反过来又很慢。

将我们的性能提高 50 倍非常诱人，从而大大降低了 Web 服务器硬件要求（功率要求降低了一个较小但仍然很重要的因素）。目前的选项是：

1) 编写自定义序列化。这是由于任务的复杂性及其产生的维护开销造成的问题，也就是说，对类状态的任何更改都需要对序列化/反序列化例程进行更改。

2) 一些第三方解决方案。也许某些产品会在构建时自动生成状态保存/加载代码，从而无需使用反射。

我很想知道是否有人知道第三方解决方案，或者遇到过这个问题，因为我在互联网搜索中没有找到任何提及。

更新：有些人提出了一种介于默认内置序列化和纯定制序列化例程之间的中间解决方案。这个想法是您为影响性能最大的类实现自定义序列化，例如覆盖 ISerializable。这是一种有趣且有前途的方法；但是，我仍然认为可以完全替代内置序列化，而无需编写和维护任何自定义代码——这不能在运行时完成，因为查询对象和访问私有数据需要反射。但理论上可以对已构建的程序集进行后处理并注入新方法作为额外的构建步骤。一些分析器使用这种方法在由 C# 编译器构建后将分析代码注入到程序集中。此外，我 /think/ 我在某处读到 .Net 框架支持将方法注入类 - 因此可能会处理所有与 IL 相关的问题。

【问题讨论】：

很确定您所说的注入方法是使用部分类。我认为原则是如果同一个命名空间中的两个类具有相同的名称并且一个被标记为部分。生成一个 dll，并结合两个类的方法和属性。

标签： .net asp.net performance serialization reflection

【解决方案1】：

不幸的是，我只知道选项 1 和 tbh 可能会开始变得非常痛苦。

但它只做你想做的事，所以它会尽可能快。

祝你好运。

【讨论】：

我接受这个作为答案，因为我们发现所有其他解决方案至少比编写自定义代码慢 10 倍。

【解决方案2】：

另一种选择是在服务器端回发未触及的所有控件上积极禁用 ViewState。

【讨论】：

大部分状态来自我们自己的类，但是是的，会有来自内置标准 ASP.NET 控件的状态，所以这绝对值得关注。谢谢。

【解决方案3】：

您可以通过实现ISerializable 来部分自定义您的序列化。如果您为最严重的违规者这样做，您不会增加太多维护，但仍会获得一些加速。

【讨论】：

我想补充一点，在我们最近的测试中，我们发现这并没有提高性能。看来性能损失来自遍历对象图的代码 - 实际的数据处理不是慢一点！

【解决方案4】：

有第三方解决方案：

Simon Hewitt 的优秀开源库，见Optimizing Serialization in .NET - part 2。

我是 using it in my application 并获得了类似的加速像你一样，20-40 次。

它消除了导致减速，但对于列表，它只支持一些本机类型。因此，对于您自己类型的 Genreric.List，需要某处或其他地方的显式代码。例如。显式循环或更聪明的东西可以自动完成。无论如何它是很简单，不应该成为巨大的障碍好处。

【讨论】：

谢谢，这里有很多有趣的信息。乍一看，它似乎位于使用内置（慢速）和纯定制序列化之间。它搭载了内置序列化，其他答案之一也提出了这一建议。

【解决方案5】：

我们遇到了类似的问题，并设计了几种提高性能的方法。我们在 Persistore 内存映射产品（当前为 beta）中使用了其中的一些。在我们的例子中，我们可以简单地“就地”访问持久化数据，因为它始终位于内存映射堆中。

但是，一个“技巧”是将会话状态数据（如果可能）定义为 marshalable 类/结构并使用 .NET 编组支持“序列化”，这确实非常快，但是不会处理“对象”图。

我们还支持基于二进制序列化的特殊持久性，但我们也提取和持久化元数据，以便托管代码可以在运行时设置/获取内存持久数据中的字段，而无需反序列化整个对象，这在一些设置（例如证券和股票价格更新等）。我们最新的测试版支持跨网络的 LINQ 匿名类型序列化，据我所知，这是第一次。

无论如何，我们希望有一些新的测试版客户正在推动 ASP.NET 和 Web 性能问题，我们最新的测试版非常令人印象深刻（但要到下周才能准备好）。

如果有人好奇，请联系我们以获取有关产品的最新信息。

休·莫兰

PS：网站已经过时，产品远远超出了那里的描述。

【讨论】：