How should I decide the quotas for the Tridion core service binding?

Question

I am connecting to the Tridion core service using a System.ServiceModel.WsHttpBinding. The service will only be used by authenticated users, and probably only by code which I control. I have to choose values for the following

MaxBufferPoolSize (default 524,288 bytes)
MaxReceivedMessageSize (default 65,536 bytes)
ReaderQuotas.MaxArrayLength (default 16384 bytes)
ReaderQuotas.MaxBytesPerRead (default 4096 bytes)
ReaderQuotas.MaxNameTableCharCount (default 16384 bytes)
ReaderQuotas.MaxStringContentLength (default 8192 bytes)

The code examples I have seen for using the core service invariably set at least some of these to values larger than the defaults, for example 4Mb. Is this because of known problems when other values, such as the defaults, are used?

MaxBufferPoolSize is there to allow you to prevent excessive garbage collections. Is this simply a matter of monitoring GCs and tuning based on that?

MaxReceivedMessageSize, MaxArrayLength and MaxBytesPerRead are there to defend against Dos attacks, so in my scenario, perhaps I can improve throughput by increasing these. Would a really large number help?

MaxNameTableCharCount seems to be there to prevent uncontrolled growth of something you might not want to grow uncontrolledly, so perhaps leaving the default would be a good thing.

The documentation on MaxStringContentLength doesn't specify what happens if you exceed the quota. Presumably ReadContentAsString will fail in some way, so perhaps this value should be large.

So - should I leave these values at their defaults? Will that cause me problems? Should I increase them to large values? Will that help with throughput etc., or is it more likely to cause other problems?

Reading through some of the answers, I now get the feeling that tuning these settings seems to be so necessary (at least for production work) that perhaps zero-config implementations (i.e. code only) might be an anti-pattern. Thoughts? — Dominic Cronin, Apr 19 '12 at 18:34

score 7 · Accepted Answer · answered Apr 13 '12 at 12:08

7

The general rule is to have these values as small as possible, just enough for you code to work. If you will take a look at default config that is shipped with CoreService.dll, it has some of the values increased.

For example, if you expect to get large XML lists (or search results) - you should increase MaxReceivedMessageSize. Keep in mind that you have control over the size of the list you will get using BaseColumns property of a filter.

If you prefer to use GetList, GetSystemWideList and GetSearchResults methods over their XML counterparts, you will probably have to increase ReaderQuotas.MaxArrayLength together with MaxReceivedMessageSize. But please note, that large arrays will be stored in memory.

I'm not sure you want to increase any of these values until you will hit the limit. WCF is quite good with pointing you to the parameter you have to adjust.

answered Apr 13 '12 at 12:08

Andrey Marchuk

13,301
2
36
52

While I agree to keep things as small as possible and that its quite easy to read from an error message which size you must increase, it is rather unacceptable for most customers that an extension stops to work all of the sudden. Which makes me choose for the maximum settings as I currently have no information of what the expected size of certain responses can be. – Bart Koopman Apr 13 '12 at 13:18
The problem with CMS systems is that it is quite hard to predict how large the content will be that authors write. If you need to modify and save a component with a rich text field, for example, there is no telling how big it will be. So I tend to choose values on the high end of the spectrum.. – Quirijn Apr 13 '12 at 20:30
So are you saying that there's no "correct" answer? If so, how would you go about the process of determining a good answer for your own scenario. For which of these values would you use a non-default value as your starting point, and what would it be? – Dominic Cronin Apr 17 '12 at 15:53
1

@DominicCronin There are some nice articles on the subject, like: http://lucvknet.blogspot.com/2010/09/when-wcf-blows-whistle-part1.html and http://stackoverflow.com/questions/835114/wcf-readerquotas-settings-drawbacks. But, if we can assume that our CoreService is a secure service and there will harldy ever be a ddos attack, the only drawback I see with increasing these values is increased memory consumption when receiving huge messages – Andrey Marchuk Apr 18 '12 at 06:34
Indeed, the problem is framed in terms of a typical core service implementation, where the service would not be open to the Internet. – Dominic Cronin Apr 18 '12 at 14:57

score 6 · Answer 2 · answered Apr 02 '12 at 20:33

6

I'm afraid this is not really an answer to your questions... But, from my experience, I increased the values to more than the defaults suggested. I used 4MB as you already suggested. This was namely because I was experiencing error while communicating with the Core Service. They were related to the request/response sizes exceeding the allotted sizes.

Moreover, in the case of Core Service transactionality, I saw more of these exceptions. It seems that the sizes of request/responses increase quite a bit when using transactions. In my case, I was creating a batch of Components in one big transaction. If one Component failed to create, I would roll-back the whole transaction.

Hope this helps.

answered Apr 02 '12 at 20:33

Mihai Cădariu

2,407
14
17

Thanks Mihai. It would be helpful to know what the exceptions were, as that might indicate which quota/setting was being exceeded. – Dominic Cronin Apr 02 '12 at 20:35
Agreed. I'll look into reproducing them. I don't remember them by heart. – Mihai Cădariu Apr 02 '12 at 20:39
one thing I noticed is that the size of a certain response can differ after installing an extension, most likely related to the use of AppData (Community Builder for instance will give you a considerably larger response). So while I agree to the general rule of setting these as small as possible, unfortunately we don't have clarity on the actual size of what the response can be for certain items. Thus to prevent errors in the future you might probably want to set them as large as possible. – Bart Koopman Apr 13 '12 at 13:15

score 4 · Answer 3 · answered Apr 17 '12 at 16:06

I've been experimenting with the Core Service recently and have seen an XmlReader exception occur when trying to open a large TBB (C# fragment) using the following code:

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

    //More code
}

System.Xml.XmlException: The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 1, position 9201.

As it says in the message, I had to up the ReaderQuotas.MaxStringContentLength to fix this. So if you're working with any Building Blocks that have content bigger than 8KB expect this error.

How should I decide the quotas for the Tridion core service binding?

3 Answers3

Linked