我应该如何决定 Tridion 核心服务绑定的配额？答案

【问题标题】：How should I decide the quotas for the Tridion core service binding?我应该如何决定 Tridion 核心服务绑定的配额？
【发布时间】：2012-04-16 12:11:29
【问题描述】：

我正在使用 System.ServiceModel.WsHttpBinding 连接到 Tridion 核心服务。该服务将仅由经过身份验证的用户使用，并且可能仅由我控制的代码使用。我必须为以下选择值

MaxBufferPoolSize（默认 524,288 字节）
MaxReceivedMessageSize（默认 65,536 字节）
ReaderQuotas.MaxArrayLength（默认 16384 字节）
ReaderQuotas.MaxBytesPerRead（默认 4096 字节）
ReaderQuotas.MaxNameTableCharCount（默认 16384 字节）
ReaderQuotas.MaxStringContentLength（默认 8192 字节）

我看到的使用核心服务的代码示例总是将其中至少一些设置为大于默认值的值，例如 4Mb。这是因为使用其他值（例如默认值）时的已知问题吗？

MaxBufferPoolSize 可以让您防止过多的垃圾收集。这仅仅是监控 GC 并在此基础上进行调整的问题吗？

MaxReceivedMessageSize、MaxArrayLength 和 MaxBytesPerRead 是用来防御 Dos 攻击的，所以在我的场景中，也许我可以通过增加这些来提高吞吐量。一个很大的数字会有帮助吗？

MaxNameTableCharCount 似乎可以防止您可能不想不受控制地增长的东西不受控制地增长，所以也许保留默认值是一件好事。

有关 MaxStringContentLength 的文档没有指定如果超出配额会发生什么。大概 ReadContentAsString 会以某种方式失败，所以也许这个值应该很大。

那么 - 我应该将这些值保留为默认值吗？这会给我带来麻烦吗？我应该将它们增加到较大的值吗？这会有助于提高吞吐量等，还是更有可能导致其他问题？

【问题讨论】：

阅读了一些答案，我现在觉得调整这些设置似乎是如此必要（至少对于生产工作），也许零配置实现（即仅代码）可能是一个反模式。想法？

标签： wcf tridion

【解决方案1】：

一般规则是使这些值尽可能小，刚好足以让您的代码工作。如果您看一下 CoreService.dll 附带的默认配置，它会增加一些值。

例如，如果您希望获得大型 XML 列表（或搜索结果） - 您应该增加 MaxReceivedMessageSize。请记住，您可以使用过滤器的BaseColumns 属性来控制列表的大小。

如果您更喜欢使用 GetList、GetSystemWideList 和 GetSearchResults 方法而不是它们的 XML 对应方法，您可能必须将 ReaderQuotas.MaxArrayLength 与 MaxReceivedMessageSize 一起增加。但请注意，大型数组将存储在内存中。

在达到限制之前，我不确定您是否要增加这些值中的任何一个。 WCF 非常适合将您指向您必须调整的参数。

【讨论】：

虽然我同意让事情尽可能小，并且很容易从错误消息中读取您必须增加的大小，但对于大多数客户来说，扩展程序停止工作是相当不可接受的突然。这让我选择了最大设置，因为我目前没有关于某些响应的预期大小的信息。
CMS 系统的问题是很难预测作者所写的内容有多大。例如，如果您需要修改和保存带有富文本字段的组件，则不知道它会有多大。所以我倾向于选择频谱高端的值..
那么你是说没有“正确”的答案吗？如果是这样，您将如何为自己的场景确定一个好的答案。对于这些值中的哪一个，您会使用非默认值作为起点，它会是什么？
@DominicCronin 关于这个主题有一些不错的文章，例如：lucvknet.blogspot.com/2010/09/when-wcf-blows-whistle-part1.html 和 stackoverflow.com/questions/835114/…。但是，如果我们可以假设我们的 CoreService 是一个安全服务并且几乎不会发生 ddos 攻击，那么我看到的增加这些值的唯一缺点是接收大量消息时会增加内存消耗
确实，这个问题是根据典型的核心服务实现来描述的，其中服务不会对 Internet 开放。

【解决方案2】：

恐怕这不是您问题的真正答案...但是，根据我的经验，我将值增加到超过建议的默认值。正如你已经建议的那样，我使用了 4MB。这是因为我在与核心服务通信时遇到了错误。它们与超出分配大小的请求/响应大小有关。

此外，在核心服务事务性的情况下，我看到了更多此类异常。使用事务时，请求/响应的大小似乎增加了很多。就我而言，我在一个大事务中创建了一批组件。如果一个组件创建失败，我会回滚整个事务。

希望这会有所帮助。

【讨论】：

谢谢米海。了解例外情况会很有帮助，因为这可能表明超出了哪个配额/设置。
同意。我会考虑复制它们。我不记得他们了。
我注意到的一件事是，在安装扩展后，某个响应的大小可能会有所不同，这很可能与 AppData 的使用有关（例如，Community Builder 会给您一个相当大的响应）。因此，尽管我同意将这些设置尽可能小的一般规则，但不幸的是，我们并不清楚某些项目的响应的实际大小。因此，为了防止将来出现错误，您可能希望将它们设置得尽可能大。

【解决方案3】：

我最近一直在试验核心服务，并发现在尝试使用以下代码打开大型 TBB（C# 片段）时出现 XmlReader 异常：

using(var client = new CoreService.CoreService2010Client())
{
    var item = client.Read(tcmId,new ReadOptions());

    //More code
}

System.Xml.XmlException：读取 XML 数据时已超出最大字符串内容长度配额 (8192)。这个配额可能是通过更改 MaxStringContentLength 属性增加创建 XML 阅读器时使用的 XmlDictionaryReaderQuotas 对象。第 1 行，位置 9201。

正如消息中所说，我必须提高 ReaderQuotas.MaxStringContentLength 才能解决此问题。因此，如果您正在使用任何内容大于 8KB 的 Building Block，则预计会出现此错误。

【讨论】：