3

本质上,我有一个非常大的列表,其中包含相对较大的字典。

所以基本上,我有一个非常大的内存集合。

然后我手动将此集合序列化为 XML,并通过 http 发送。不用说,XML 太大了,有时太大了,我什至在尝试发送它之前就得到了 OutOfMemory 异常。

在 .NET 中,我将如何计算潜在的内存使用量。例如,在这种情况下,我必须通过一次仅处理少量 Collection 将 XML 分解成块。

如何有效地即时计算每个“块”的大小。我不想选择一个任意数字,例如“一次处理 100 个项目”,我想知道每个块应该有多大,以逐案为基础。

干杯

更新

尽管@Jacob 为这个特定问题提供了最佳解决方案,但该应用程序的概念结构本身存在缺陷。

实际上,解决方案是执行消息的一部分,以便在使用集合时计算消息的潜在大小。

然后,您一个接一个地发送每个可接受大小的单元。

但这只是一个技巧。真正的解决方案是要么找到一种不传递大消息的方法,要么完全使用完全不同的协议。

如果你想使用 SOAP,这里有一篇关于这个主题的有趣帖子,但是我决定找到一种方法来绕过发送如此多的数据。

4

4 回答 4

6

为什么不直接流式传输数据,以便即时转换为 XML,避免内存中存在巨大的 XML 文件?

于 2009-06-17T23:43:52.193 回答
2

我认为您可能比其他任何事情都更容易遇到概念问题。“计算潜在内存使用量”与“有效计算每个块的大小”不一致。真正使您的内存使用达到可以预测足够块大小的准确程度的唯一方法是实际进行转换。

听起来最好的方法可能是逐步解决这个问题——基本上是那些建议使用流对象的人所说的。如果您不能利用实际的流式传输,您可能希望构建您的序列化,以便一次处理一个概念单元(即列表中的一个项目及其伴随的字典子项)。

于 2009-06-18T00:15:19.620 回答
1

你怎么寄?您应该通过可以进行流式传输的 WCF 来执行此操作。它还可以通过配置让您选择是使用 XML 还是二进制文件,或者其他什么。

于 2009-06-17T23:58:45.440 回答
0

如果发送有问题,接收不也有问题吗?你听起来像是在尝试解决一半的问题。XML 是大数据的一大禁忌。

于 2009-12-10T09:00:42.703 回答