Как мне выбрать квоты для привязки основной службы Tridion?

Я подключаюсь к основной службе Tridion с помощью System.ServiceModel.WsHttpBinding. Служба будет использоваться только аутентифицированными пользователями и, вероятно, только кодом, который я контролирую. Мне нужно выбрать значения для следующих

Примеры кода, которые я видел для использования основной службы, неизменно устанавливают по крайней мере некоторые из них в значения, превышающие значения по умолчанию, например 4 Мб. Это из-за известных проблем, когда используются другие значения, такие как значения по умолчанию?

MaxBufferPoolSize позволяет предотвратить чрезмерную сборку мусора. Это просто вопрос мониторинга GC и настройки на основе этого?

MaxReceivedMessageSize, MaxArrayLength и MaxBytesPerRead предназначены для защиты от атак Dos, поэтому, по моему сценарию, я могу улучшить пропускную способность, увеличив их. Помогло бы действительно большое число?

MaxNameTableCharCount, похоже, существует, чтобы предотвратить неконтролируемый рост того, что вы, возможно, не захотите расти бесконтрольно, так что, возможно, оставив по умолчанию было бы хорошо.

В документации по MaxStringContentLength не указано, что произойдет, если вы превысите квоту. Предположительно, ReadContentAsString каким-то образом сработает, поэтому, возможно, это значение должно быть большим.

Итак - следует ли оставить эти значения по умолчанию? Это вызовет у меня проблемы? Должен ли я увеличить их до больших значений? Будет ли это помогать с пропускной способностью и т.д., Или это может вызвать другие проблемы?

ОТВЕТЫ

Ответ 1

Общее правило заключается в том, чтобы эти значения были как можно меньше, что достаточно для того, чтобы ваш код работал. Если вы посмотрите на конфигурацию по умолчанию, поставляемую с CoreService.dll, некоторые из них будут увеличены.

Например, если вы ожидаете получить большие списки XML (или результаты поиска), вы должны увеличить MaxReceivedMessageSize. Имейте в виду, что вы контролируете размер списка, который вы получите, используя свойство BaseColumns фильтра.

Если вы предпочитаете использовать методы GetList, GetSystemWideList и GetSearchResults поверх своих XML-копий, вам, вероятно, придется увеличить ReaderQuotas.MaxArrayLength вместе с MaxReceivedMessageSize. Но учтите, что большие массивы будут сохранены в памяти.

Я не уверен, что вы хотите увеличить любое из этих значений, пока не достигнете предела. WCF неплохо указывает на параметр, который вы должны настроить.

Ответ 2

Я боюсь, это на самом деле не ответ на ваши вопросы... Но, по моему опыту, я увеличил значения до большего, чем предлагаемые по умолчанию. Я использовал 4MB, как вы уже сказали. Это произошло потому, что я испытывал ошибку при общении с Core Service. Они были связаны с размерами запроса/ответа, превышающими выделенные размеры.

Кроме того, в случае транзакционной транзакции Core Service я видел больше этих исключений. По-видимому, размеры запросов/ответов при использовании транзакций значительно увеличиваются. В моем случае я создал партию Компонентов в одной большой транзакции. Если один компонент не смог создать, я откатил бы всю транзакцию.

Надеюсь, что это поможет.

Ответ 3

Я недавно экспериментировал с Core Service и видел исключение XmlReader при попытке открыть большой TBB (фрагмент С#), используя следующий код:

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

    //More code
}

System.Xml.XmlException: максимальная длина длины длины строки (8192) превышена при чтении данных XML. Эта квота может быть увеличено путем изменения свойства MaxStringContentLength на Объект XmlDictionaryReaderQuotas, используемый при создании XML-ридера. Строка 1, позиция 9201.

Как говорится в сообщении, мне пришлось обновить ReaderQuotas.MaxStringContentLength, чтобы исправить это. Поэтому, если вы работаете с любыми Building Blocks, у которых есть контент размером более 8 КБ, ожидайте эту ошибку.