A Sample for WCF Client Proxy Pooling

Introduction

Ideally we should not need to pool WCF client proxies as I mentioned in my previous blog entry. From some customer feedback, however, I got to know that reusing proxies is not ideal because:

· There may be some unknown contention cost when one proxy is used by multiple threads.

· There is some concern about associating contextual data to a proxy when the proxy is reused at the same time by multiple threads.

So people would generally think about implementing a proxy pool in their systems. As pointed out in my previous blog entry, you need to be aware of the following when you want to implement a proxy pool:

· You need to implement the right synchronization logic for managing the proxies.

· You need to make sure the proxies are used equally. Sometimes, you may want to implement a round-robin pattern for the proxies.

· You need to handle exceptions and retries for the pool.

· The pool size needs to be limited and configurable.

· You may need to be able to create proxies even if when no proxy is available from the pool.

Here are some common ways to implement a pool in my mind:

· Load-balancing model: Whenever you want to send a request, you would pick a proxy from the pool (in a round-robin pattern) and use it to handle the request. The proxy can be used by multiple threads concurrently.

· Take-return-create model: You take the proxy from the pool so that other threads cannot get the same one. After using it, you return it back to the pool. When the pool is empty, you would create a new proxy. When the pool is full when you return it back, you just discard the proxy.

· Take-return-wait model: Similar as above. The difference is that, when the total number of proxies being used reaches the size of the pool and all proxies are being used (i.e., the pool is empty), the thread would wait until a proxy is returned back to the pool.

I will show a sample to implement the second approach “take-return-create model”. It is easy to implement and it solves performance issues nicely. As what I have written in my other blog entries, the sample code and the ideas in this blog imply no warranties and confer no rights and they are provided AS-IS.

The Pool<T> Class

The generic Pool<T> class that I used in the sample implements the simple Take-Return logic. It is actually the one that is taken from the internal calls System.ServiceModel.Pool<T>. You can disassembly the source from System.ServiceModel.dll with the .NET Reflector. Here is the source:

class Pool<T> where T : class

{

    T[] items;

    int count;

    public Pool(int maxCount)

    {

        items = new T[maxCount];

    }

    public int Count

    {

        get { return count; }

    }

    public T Take()

    {

        if (count > 0)

        {

            T item = items[--count];

            items[count] = null;

            return item;

        }

        else

        {

            return null;

        }

    }

    public bool Return(T item)

    {

        if (count < items.Length)

        {

            items[count++] = item;

            return true;

        }

        else

        {

            return false;

        }

    }

    public void Clear()

    {

        for (int i = 0; i < count; i++)

            items[i] = null;

        count = 0;

    }

}

The logic is very simple. It uses an array-based simple stack to manage the items. Note that the class does not provide thread-safe logic. So we have to add that logic when we use it.

The Pooling Logic

Once we have the pool, we can implement the pooling logic. Here I follow the best practice of closing a proxy as mentioned in the MSDN article https://msdn2.microsoft.com/en-us/library/aa355056.aspx. Here is the code:

void CallWithPool(string message)

{

    MyHelloServiceProxy proxy = null;

    // Trying to take the proxy from the pool

    lock (pool)

    {

        proxy = pool.Take();

    }

    // Remove bad proxies (Faulted etc). Note that checking the proxy state has

    // some performance cost here as it accesses the Transparent proxy of the

    // channel.

    if (proxy != null && proxy.State != CommunicationState.Opened)

    {

        proxy.Abort();

        proxy = null;

    }

    // Create the proxy if not found from the pool.

    if (proxy == null)

    {

        Console.WriteLine("Creating new proxy.");

        proxy = CreateProxy();

    }

    try

    {

        // Call the service with the proxy

        proxy.Hello(message);

    }

    catch (Exception)

    {

        // You need to better handle the exception in real production

        // environments.

        proxy.Abort();

        throw;

    }

    // Trying to put the proxy back to the pool

    bool shouldClose = false;

    lock (pool)

    {

        shouldClose = !pool.Return(proxy);

    }

    // Close the proxy if it's not put back into pool

    if (shouldClose)

    {

        try

        {

            proxy.Close();

        }

        catch (Exception)

        {

            proxy.Abort();

   throw;

        }

    }

}

Comparisons

In the sample, I also implemented the other two approaches for comparison purpose:

· Per call: Creating/disposing proxies per call

· Singleton: Using singleton proxies

Data shows that the performance between pooling and singleton is quite close. When BasicHttpBinding with default settings is used, the “per call” approach has comparable performance as the other two. However, when WSHttpBinding is used, you would see much slower results when “per call” model because of the high cost in re-constructing security sessions when each proxy is created.

Configuration Setting Helper

Now that I have provided all the details, why don’t I be a good person to the end? One thing that we have not mentioned is about configuring the pool size. In the sample, I also provided a simple configuration section <channelPoolSettings> that is implemented by the type “ChannelPoolSettingsSection” . In this way, you can easily change the setting from the configuration without touching the code. This can be easily converted to ASP.NET web.config setting. To make the configuration work, you need to register the section handler as following:

<configSections>

  <section name="channelPoolSettings" type="WCF.Performance.Samples.ChannelPoolSettingsSection, TestChannelPoolClient" />

</configSections>

Here is the sample configuration:

<configuration>

  <channelPoolSettings poolSize="8"/>

</configuration>

You can find the sample code attached.

 

TestChannelPool.zip

Comments

• Anonymous
  November 13, 2007
  PingBack from http://msdnrss.thecoderblogs.com/2007/11/14/a-sample-for-wcf-client-proxy-pooling/

• Anonymous
  November 26, 2007
  I've recently stumbled on your blog as I researched WCF. So first, let me say thanks! Good stuff. I was wondering if maybe you could discuss in another post the pros and cons of reusing a proxy, especially in, say, a middle-tier scenario. For example: suppose you have a WCF web service (IIS hosted) that will in turn call another web service. When should that web service attempt to reuse the proxy for the other web service? Obviously this will depend on the InstanceContextMode, and I'm guessing that a PerCall would mean don't bother with proxy reuse, but I was hoping to get your expert opinion on the matter. Thanks!

• Anonymous
  March 11, 2009
  Would you recommend using the proxy pool if my client is an ASP.NET application and the binding I'm using is netTcp with security mode of Transport (Windows)? Also, what should be the proper InstanceContextMode of the service? Thanks in advance, Ido.

• Anonymous
  October 12, 2010
  The comment has been removed

• Anonymous
  October 12, 2010
  Cross that. My bad, I missed the NOT here.

• Anonymous
  February 11, 2014
  Hi Wenlong,    Is there a chance where the Channel object returned by ChannelFactory.CreateChannel( ) can change in between. I am seeing this behavior. Please let me know if you have encountered this.   More details here : stackoverflow.com/.../wcf-client-pool-caching-channel Thanks, Maddy