返回服务上的大数据

Posted 2023-03-11

【中文标题】返回服务上的大数据

【英文标题】：Return large data on service

【发布时间】：2012-08-06 00:52:42

【问题描述】：

我有一个返回大量对象列表的方法。当我返回一些对象（10）时，一切都很好。问题是当我尝试返回 100 个对象时。列表之所以这么大，是因为列表中的对象里面还有其他对象，所以我基本上是返回一棵树。

无论如何我都在使用命名管道，这是我正在使用的 enpoint 的配置：

<netNamedPipeBinding>
      <binding name="NetNamedPipeBinding_ISymbolFileParser" 
                      closeTimeout="00:10:00"
                      openTimeout="00:10:00" 
                      receiveTimeout="00:10:00" 
                      sendTimeout="00:10:00"
                      transactionFlow="false" 
                      transferMode="Buffered" 
                      transactionProtocol="OleTransactions"
                      hostNameComparisonMode="StrongWildcard"
                      maxBufferPoolSize="2147483647"
                      maxBufferSize="2147483647" 
                      maxConnections="10" 
                      maxReceivedMessageSize="2147483647"
                     >
              <readerQuotas 
                   maxDepth="32" 
                   maxStringContentLength="2147483647" 
                   maxArrayLength="2147483647"
                   maxBytesPerRead="4096" 
                   maxNameTableCharCount="2147483647" />                    
      </binding>
</netNamedPipeBinding>

当我通过 results.Take(10).ToArray(); 限制对象的数量时，一切都很好。当我返回 100 个对象时，我得到了异常：

---

我为解决问题所做的事情：

我将配置文件中的数字增加到2147483647 我没有返回对象列表，而是在服务上序列化了我自己的列表，然后创建了一个 Test 方法，该方法将返回 byte[] 而不是列表。然后在客户端上，我将 byte[] 反序列化为一个列表，这样就可以了！因此，到目前为止，我有一个解决方案，最坏的情况是我必须序列化我的 serlf 对象并反序列化它。

我还想借此机会询问我是否应该使用不同的绑定。我听说共享内存是最快的，但我不知道如何在 wcf 上使用它。因为我在使用命名管道的同一台机器之间进行通信。

【问题讨论】：

如果您担心列表变得越来越大，或者换句话说，列表占用的内存太高，为什么不尝试其他数据结构

【参考方案1】：

看起来像序列化问题，尝试通过 endpointBehaviors 和 serviceBehaviors 中的行为增加dataContractSerializer maxItemsInObjectGraph。

同样的问题here

【讨论】：

+1 一个特别讨厌的问题 - 确实非常原始，但需要几个小时才能弄清楚