Monthly Archives: October 2010

ANUG Solr/Lucene presentation

Aarhus .NET user groupI am on the train to Copenhagen after a successful presentation of Solr/Lucene at the Aarhus .NET user group.

The presentation went very well judging by the number of questions during the almost 2½ hour long presentation and the feedback afterwards. Love it – thanks 🙂

The presentation and code samples can be downloaded below:

Please do contact me if you have any further questions – I’ll love to help out.

WCF Timeouts

The last two articles about WCF Throttling part 1 and part 2 would not be complete without looking at WCF timeouts. Any potentially lengthy operation must have a timeout or the system might end up waiting indefinitely – this is remarkably prevalent when working across any network connection (Yes, LAN connections too).

Timeouts are not directly related to throttling properties, but effect the way the service (or client) performance under load. Timeout properties can be perceived as an annoyance when sending larger messages or dealing with slow connections or services. The frustration increase as the naming of the properties can be deceiving. Read on… and I’ll explain 🙂

Below are the binding properties that all throw TimeoutExceptions if any of setting thresholds are exceeded:

  • OpenTimeout (TimeSpan) – the interval of time provided for an open operation to complete including security handshakes (WS-Trust, WS-Secure Conversation etc.). The default is 00:01:00.
  • CloseTimeout (TimeSpan) – the interval of time provided for a close operation to complete. The default is 00:01:00.
  • SendTimeout (TimeSpan) – the interval of time provided for an entire operation to complete. This includes both sending of message and receiving reply! The default is 00:01:00.
  • ReceiveTimeout (TimeSpan) – the interval of time that a connection can remain inactive, during which no application messages are received, before it is dropped. The default is 00:10:00.
    • This setting is only used on the server-side and has no effect on client-side.
    • When using Reliable Sessions remember to set the InactivityTimeout property on the reliableSession element to the same value as the ReceiveTimeout property, as both inactivity timers has to be satisfied.

Example of configuration file:

<system.serviceModel>
  <bindings>
    <netTcpBinding>
      <binding name="netTcpBindingConfig"
               openTimeout="00:01:00"
               closeTimeout="00:01:00"
               sendTimeout="00:01:00"
               receiveTimeout="00:10:00">
        <reliableSession enabled="true"
                         inactivityTimeout="00:10:00" />
      </binding>
    </netTcpBinding>
  </bindings>
</system.serviceModel>

WCF Throttling – Part 2

In the WCF Throttling – Part 1 article the service throttling behavior was introduced.

There are other throttling features in WCF that are designed to protect the service from request flooding.

These WCF throttling feature are configured on the binding, service behaviors and endpoint behaviors.

Binding properties:

  • MaxConnections (int) – specifies the maximum number of outbound and inbound connections the service creates and accepts respectively. Default value is 10 connections. This setting only applies for statefull TCP connections like netTcpBinding and not stateless HTTP protocols like basicHttpBinding, wsHttpBinding or webHttpBinding.
  • MaxReceivedMessageSize (long) – the maximum size of a message (including headers), that can be received on a channel. The sender of a message exceeding this limit will receive a fault and the receiver will drop the message. The default value is 65,536 bytes (64K).

There are two additional properties on the binding that one might mistakenly think is request throttling properties. These are the MaxBufferPoolSize and MaxBufferSize properties and they control WCF memory Buffer Manager.

Note: remember to set the MaxReceivedMessageSize and MaxBufferSize properties to the same value if using TransferMode.Buffered or an ArgumentException will be thrown at runtime with the message “For TransferMode.Buffered, MaxReceivedMessageSize and MaxBufferSize must be the same value.”

Binding properties for the readerQuotas element – used by XmlReader under the hood:

  • MaxArrayLength (int) – the maximum allowed array length of data received from a client. The default is 16,384 (16K).
  • MaxBytesPerRead (int) – the maximum allowed bytes returned per read for the XmlReader. The default is 4,096 (4K).
  • MaxDepth (int) – the maximum XML nested node depth. The default is 32.
  • MaxNameTableCharCount (int) – the maximum characters allowed in a table name. This is the maximum length of an XML element or attributes identifier including XML namespace. The default is 16,384 (16K).
  • MaxStringContentLength (int) – the maximum characters allowed in XML element or attribute content. The default is 8,192 (8K).

The DataContractSerializer is by default used to serialize and deserialize messages as it is much faster the XMLSerializer, but with less features. The DataContractSerializer has a single property that can be configures at the endpoint or service behavior:

  • MaxItemsInObjectGraph (int) – maximum number of items in an object graph to serialize or deserialize. The default is 65,536 (64K).

Resist the temptation of settings any of these properties to Int.MaxValue and the likes, because determining the correct values are difficult. Throttle the service, so some clients gets served instead of risk boggling down the service with request flooding, resulting in no clients get served.

You will become the service hero in your organization by throttling instead of letting the service run wild 🙂

Example of configuration file:

<system.serviceModel>
  <behaviors>
    <endpointBehaviors>
      <behavior name="endpointBehavior">
        <dataContractSerializer maxItemsInObjectGraph="65536"/>
      </behavior>
    </endpointBehaviors>
    <serviceBehaviors>
      <behavior name="serviceBehaviors">
        <dataContractSerializer maxItemsInObjectGraph="65536"/>
      </behavior>
    </serviceBehaviors>
  </behaviors>
  <bindings>
    <netTcpBinding>
      <binding name="netTcpBindingConfig"
                maxReceivedMessageSize="65536"
                maxConnections="10">
        <readerQuotas maxArrayLength="16384"
                      maxBytesPerRead="4096"
                      maxDepth="32"
                      maxStringContentLength="8192"
                      maxNameTableCharCount="16384"/>
      </binding>
    </netTcpBinding>
  </bindings>
</system.serviceModel>

WCF Throttling – Part 1

The default throttling settings in WCF has always been very conservative. There where configured conservatively to diminish the risk of request flooding. Without throttling settings a large number of requests will make the service unresponsive by consuming all resources trying to respond to all requests simultaneously.

Because of the very conservative settings many developers have run into what seems like WCF performance problems, but was actually incorrectly configured throttling settings.

WCF throttling is a service behavior configuration and each setting has effect dependent on the InstanceContextMode and ConcurrencyMode settings.

  • maxConcurrentCalls (int) – the maximum number of concurrent messages processing
  • maxConcurrentInstances (int) – the maximum number of concurrent InstanceContext (service type instances) objects processing
  • maxConcurrentSessions (int) – the maximum number of concurrent sessions processing

These throttling settings can be configured in code via the ServiceThrottlingBehavior in the System.ServiceModel.Description namespace or though configuration like below:

<system.serviceModel>
    <serviceBehaviors>
      <behavior name="throttlingServiceBehavior">
        <serviceThrottling maxConcurrentCalls="16"
                           maxConcurrentInstances="160"
                           maxConcurrentSessions="10"/>
      </behavior>
    </serviceBehaviors>
</system.serviceModel>

The default values in .Net 3.0/3.5 are:

  • maxConcurrentCalls = 16
  • maxConcurrentSessions = 10
  • maxConcurrentInstances = maxConcurrentCalls + maxConcurrentSessions

The default has changed in .Net 4.0 as the .Net 3.0/3.5 default values were too conservative and the increase in server resources – especially the number of cores available. The default values for .Net 4.0 are:

  • maxConcurrentCalls = 16 * Environment.ProcessorCount
  • maxConcurrentSessions = 100 * Environment.ProcessorCount
  • maxConcurrentInstances = maxConcurrentCalls + maxConcurrentSessions

The Environment.ProcessorCount property is misleading as the value is the number of cores (Hyper-Threading counts double). In my development laptop with four Hyper-Threading cores looks like this: