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 http://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 (6)

  1. Randolpho says:

    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!

  2. idotandy says:

    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.

  3. Randhir says:

    Hi Wenlong,

    There's one possible correction in your code in the CallWithPool() method. I think you intend to write the line:

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

    as

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

    Isn't it true that since you are not closing any proxy while adding/returning to the pool, all of them will be in Opened state?

    Thanks for the great insights you share, as always.

    -Randhir

  4. Randhir says:

    Cross that. My bad, I missed the NOT here.

  5. GoMaddy says:

    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

Skip to main content