WCF Proxies: To Cache or Not to Cache?

RELATED: "WCF and Client Proxies" and "WCF Service Instancing."

This month we ll explore scenarios for managing thelifetime of WCF proxies in different architectural scenarios, and also coverrelated performance improvements released with .NET3.0 SP1.

Calling a WCF service requires clients to construct aproxy which really means constructing a channel factory and, ultimately, astrongly-typed channel for the service endpoint. Building the client s channelstack carries some overhead, which can impact multithreaded applications. Thisincludes Windows Forms or WPF applications that present a user interface, andserver-side applications that consume WCF services, such as ASP.NETpages and other WCF services. In this article I ll explore the appropriateoptimizations for caching the channel factory or the entire channel, dependingon the application architecture. In addition, I ll explain new featuresreleased with .NET 3.0 SP1 that now providesome built-in optimizations.

A Quick Note on .NET 3.0 SP1

.NET 3.0 SP1 was releasedduring the same timeframe as Visual Studio 2008 and .NET3.5 (November 2007). The service pack is actually a prerequisite to .NET3.5 and, thus, is installed with .NET 3.5.You can also apply the service pack to your .NET3.0 installations separately. A few assemblies are updated when the servicepack is applied.

Here s a direct link to .NET3.0 SP1 if you are not installing .NET 3.5.This also provides information on the core changes in the service pack underthe KB Articles link.

There are several improvements in .NET3.0 SP1 among them, optimizations related to WCF proxies and lifetimemanagement of the underlying channel factory. This will be the feature that Idiscuss as part of this article.

Channel Caching Options

Your options for channel caching in any applicationconsist of the following:

When you generate a proxy using SvcUtil, a class isgenerated that implements your service contract and inherits ClientBase.Consider the class shown in Figure 1 that implements the service contractICounterServicePerCall.

[ServiceContract(Namespace="http://www.thatindigogirl.com/ samples/2006/06")]public interface ICounterServicePerCall{  [OperationContract] int IncrementCounter();}public partial class CounterServicePerCallClient :ClientBase< ICounterServicePerCall>, ICounterServicePerCall {...}

Figure 1: Thisclass implements the service contract ICounterServicePerCall.

If you choose to not cache the proxy reference, your codemight look like this if you create a new proxy for each call:

CounterServicePerCallClient proxy = new CounterServicePerCallClient(new NetTcpBinding(),new EndpointAddress("net.tcp://localhost:9000/PerCall"));proxy.IncrementCounter();proxy.Close();

In .NET 3.0 (before SP1),this would create a new channel factory and channel each time. You can manuallyachieve the same result using ChannelFactory instead of the generatedproxy by calling the static CreateChannel method exposed by ChannelFactoryto create a new channel for each call:

ICounterServicePerCall proxy = ChannelFactory.CreateChannel(new NetTcpBinding(), new EndpointAddress("net.tcp:// localhost:9000/PerCall"));proxy.IncrementCounter();((ICommunicationObject)proxy).Close();

In both cases, you could opt to cache the returned proxyor channel reference to achieve channel caching scoping the reference so theapplication can reuse it for multiple calls and possibly multiple threads.

The only way to cache the channel factory separate fromthe channel before SP1 was to use ChannelFactory to create thefactory first, then explicitly use the cached factory to construct a newchannel for each call (see Figure 2).

// scope the channel factory reference for the application's requirementsChannelFactory factory = new ChannelFactory(new NetTcpBinding(),new EndpointAddress("net.tcp://localhost:9000/PerCall")) ;// create the channel for each callICounterServicePerCall proxy = factory.CreateChannel();proxy.IncrementCounter();  ((ICommunicationObject)proxy).Close();// clean up the factory when the application no longer needs it  ((ICommunicationObject)factory).Close();

Figure 2: Prior toSP1 the only way to cache the channel factory separate from the channel was touse ChannelFactory to create the factory, then explicitly use thecached factory to construct a new channel for each call.

Of course, you d have to uniquely scope individual channelfactory references if there are several (to ensure using the correct factory tocreate channels for each endpoint with which you communicate).

.NET 3.0 SP1 introduceda new most recently used (MRU) channel factory cache that is managedautomatically as you use proxies that derive from ClientBase. Thismakes it possible to cache the channel factory while using a generated proxy,without having to write the code to handle caching efforts. In fact, your codecould construct a new proxy instance for each call without caching thereference and when the proxy is constructed again the appropriate channelfactory for the new proxy instance would be used if a match is present in theMRU cache. I ll explore how this works in the next section, but the result issimilar to what you might do if you manually cached the channel factory andused it to construct new channel instances for each call.

Once you have a full grasp of the channel caching optionsavailable, you must think through what is appropriate for your application. Inother words:

To answer these questions, one must always consider theapplication architecture. I ll provide some guidance on this based on Windowsclient- and server-side application scenarios in forthcoming sections.

Channel Factory Caching in SP1

The new channel caching feature released with .NET3.0 SP1 is transparent to developers in the sense that channel factory cachingin the MRU cache is handled automatically by ClientBase. You constructyour proxy, which derives from ClientBase in the usual way. Duringconstruction, ClientBase checks to see if a channel factory hasalready been cached for the endpoint you are calling. If so, it will use thatchannel factory to construct the inner channel for the proxy. If not, it willconstruct a new channel factory for that endpoint, cache it for future use,then construct the inner channel for the proxy.

That s the high-level perspective, but there are someimportant details to consider in this process:

There are several constructors supplied by ClientBase(see Figure 3).

// non-duplex constructorsprotected ClientBase();protected ClientBase(string endpointConfigurationName);protected ClientBase(Binding binding, EndpointAddress remoteAddress);protected ClientBase(string endpointConfigurationName, EndpointAddress remoteAddress);protected ClientBase(string endpointConfigurationName, string remoteAddress);// duplex constructorsprotected ClientBase(InstanceContext callbackInstance);protected ClientBase(InstanceContext callbackInstance, string endpointConfigurationName);protected ClientBase(InstanceContext callbackInstance, Binding binding,EndpointAddress remoteAddress);protected ClientBase(InstanceContext callbackInstance, string endpointConfigurationName, EndpointAddress remoteAddress);protected ClientBase(InstanceContext callbackInstance, string endpointConfigurationName, string remoteAddress);

Figure 3: Constructorssupplied by ClientBase.

Parameters to these constructors are used to either cachea new channel factory or find an existing channel factory reference.Constructor parameters used to cache the channel factory are:endpointConfigurationName, remoteAddress, and callbackInstance (the latter beingrelevant to DuplexClientBase proxies only). Constructors that accept aBinding parameter type cannot be used to cache the channel factory so if youconstruct your bindings programmatically, you can t take advantage of the MRUcache.

Aside from constructor choice affecting the use of the MRUcache, accessing certain properties of the ClientBase reference willalso cause a matching MRU cache entry to be released. To be specific, removalof the matching MRU cache entry takes place if you access the ChannelFactory,ClientCredentials, or Endpoint properties of the proxy reference.

Channel factory references in the MRU cache are considereda unique match to a particular proxy reference based on the following:

Because the use of the MRU cache is transparent to thedeveloper, there is very little reason to not leverage it when you can particularlyfor Windows client applications. However, there are definitely some scenarioswhere this approach for channel factory caching is not practical or evenpossible. The next sections will look at some application scenarios andrecommended approaches.

Windows Clients and Channel Caching

Windows clients built with Windows Forms or WPF typicallycreate a proxy and cache it for the lifetime of the application. Figure 4illustrates a client application that communicates with two services, Service Aand Service B. Two proxies are constructed when the application begins; each isused for the lifetime of the application to communicate with their respectiveservice endpoints. Because the services use PerCall instancing, each call fromthe client gets its own service instance, but a single channel factory andchannel are constructed at the client to invoke service operations.

Figure 4: Channel caching for thelifetime of a Windows application.

Figure 4 assumes that you are caching the proxy reference thatincludes both the channel factory and channel. This would be equivalent tousing ChannelFactory and caching the channel reference fromCreateChannel.

If the channel has a transport session (named pipes, TCP,or HTTP with reliable sessions or secure sessions), it is possible for thechannel to become faulted, possibly from a timeout or an uncaught exception. Inthis case, a new channel must be created at the client. With SP1, if the proxyis constructed with parameter values that match a channel factory in the MRUcache (see Figure 5), the overhead of recreating the client channel is reduced.

Figure 5: Leveraging the MRU cacheto construct a new proxy.

If the client application is multithreaded, channelcaching is an absolute necessity, particularly if each thread is updating userinterface components. If each thread constructs a new proxy to communicate withservices, UI updates can become unbearably slow. If there are enough UIthreads, even the MRU cache is not sufficient to improve this perception to endusers. In this case, channel caching is the best possible solution where allthreads share the same proxy or channel reference, as shown in Figure 6.Certainly, if something causes the channel to fault, the presence of the MRUcache is still useful for optimizing channel recreation.

Figure 6: Multiple threads sharingthe same proxy reference.

Remember that in the presence of a transport session, evenPerCall services must be set for ConcurrencyMode.Multiple to allow a singleproxy to send multiple concurrent requests to the same channel.

There is at least one clear case where a Windows clientapplication will not be able to leverage the MRU caching feature to optimizechannel recreation. Because accessing the ClientCredentials property removesthe matching MRU cache entry for the proxy, clients that supply credentialscollected at run time will never use the MRU cache. For example, the followingcode sets UserName credentials a typical requirement of Internet-facing WCFservices:

CounterServicePerCallClient proxy = newCounterServicePerCallClient("netTcp2", new   EndpointAddress("net.tcp://localhost:9000/PerCall"));proxy.ClientCredentials.UserName.UserName = "user";proxy.ClientCredentials.UserName.Password = "password";proxy.IncrementCounter();proxy.Close();

As soon as the ClientCredentials property is accessed,previously cached MRU entries for the same configuration name and address areremoved from the cache. Fortunately, Windows clients benefit the most fromchannel caching. The MRU cache, although useful in the case where channelrecreation is necessary, will not make a significant difference unless thechannel is consistently faulted across multiple client threads that rely on thechannel.

To improve channel recreation performance you can createthe channel factory directly using ChannelFactory, set theClientCredentials property, and create your own caching mechanism for thefactory in the event channel recreation is required. The following codeillustrates how to set credentials on the ChannelFactory reference:

ChannelFactory factory = newChannelFactory(new NetTcpBinding(),new EndpointAddress("net.tcp://localhost:9000/PerCall")) ;factory.Credentials.UserName.UserName = "user";factory.Credentials.UserName.Password = "password"; 

Figure 7 summarizes the typical usage of each cachingoption for Windows clients.

Figure 7: Windowsclient channel caching options and typical usage.

Server-side Clients and Channel Caching

Server-side clients are a much different animal fromWindows applications when it comes to practical options for caching channelfactories and channels. Figure 8 illustrates the architecture where multipleconcurrent threads from an ASP.NETapplication or WCF service hosted in the Web server tier call a WCF servicehosted in the application server tier.

Figure 8: Server-side clientsconsuming a WCF service from multiple concurrent threads.

This scenario is different from the Windows clientscenario in the following ways:

The characteristics of the server-side scenario limit yourpractical options for channel caching.

Caching a proxy or channel reference is simply not anoption if you want to load balance calls from the Web server tier to the applicationserver tier unless the protocol used is HTTP without sessions(BasicHttpBinding). The typical protocol between Web and application servers isTCP (NetTcpBinding), which reduces thislikelihood. If you cache the channel, server affinity is established whichcan crush your scalability goals for the application as a whole, even if it seemsto improve performance when you test with only a few concurrent users.

Caching the channel factory can be a viable option toimprove performance, while still allowing the application to distribute callsto load-balanced servers because a new channel is created for each thread.Caching the channel factory in a server-side scenario cannot likely leveragethe MRU cache supplied by ClientBase for two reasons: bindingconfigurations are likely to be pulled from a common database entry tofacilitate server-farm deployments, and credentials are likely to be set at runtime on the proxy for each call.

Using ChannelFactory you can still achievechannel factory caching with your own custom MRU cache. This still implies animportant restriction: calls to the same service endpoint that share thechannel factory must also share the same credentials. That means you can t passdifferent credentials for each thread calling application services from the Webserver tier. One scenario where this is not an issue is if you use the samecertificate or Windows credential to authenticate to downstream services. Inthis case, if you need to pass information about the authenticated user, youcan use custom headers rather than a security token.

In most cases, server-side clients simply pay the price ofconstructing a new channel for each call, without any caching benefits. Thissatisfies the need to scale out and provide the required credentials for eachcall using appropriate security tokens instead of the custom header workaround.Performance may be slower if compared side-by-side with each caching approach,but the benefits of horizontal scaling outweigh this concern. In most cases amultithreaded server application can withstand two to three WCF service callswithout caching the channel factory or channel and still achieve performancebenchmarks required by the application for the individual call. The overhead ofthe WCF plumbing is usually shadowed by the overhead of the applicationfunctionality. You should always benchmark your applications to establish anacceptable average time to complete each call. Figure 9 summarizes the typicalusage of each caching option for server-side clients.

Figure 9:Server-side client channel caching options and typical usage.

Conclusion

After reading this article you should have a betterunderstanding of not only the possible channel caching options available toyou, but what is practical to apply in Windows client and server-side clientscenarios. While the MRU cache is a useful new feature, there are still caseswhere raw ChannelFactory caching will be necessary. In addition, don tbe overly concerned if you can t cache your channel factory or channel inserver-side scenarios, because the goal should be overall scalability in thatcase. It is when a user interface is involved, as with Windows clients, thatcaching becomes much more necessary to perceived performance in particularwith multithreaded clients.

Download the samplesfor this article at http://www.dasblonde.net/downloads/aspprojuly08.zip.

Michele LerouxBustamante is Chief Architect of IDesign Inc., Microsoft Regional Directorfor San Diego, and Microsoft MVP for Connected Systems. At IDesign Micheleprovides training, mentoring, and high-end architecture consulting servicesfocusing on Web services, scalable and secure architecture design for .NET,federated security scenarios, Web services, and interoperability andglobalization architecture. She is a member of the International .NETSpeakers Association (INETA), a frequent conference presenter, conference chairfor SD West, and is frequently published in several major technology journals.Michele also is on the board of directors for IASA (International Associationof Software Architects), and a Program Advisor to UCSD Extension. Her latestbook is Learning WCF (O Reilly 2007);see her book blog at http://www.thatindigogirl.com.Reach her at mailto:[email protected], orvisit http://www.idesign.net and her mainblog at http://www.dasblonde.net.

Additional Resources

Wenlong Dong has a fantastic blog entry with additionaldetails about the MRU cache: http://blogs.msdn.com/wenlong/archive/2007/10/27/performance-improvement-of-wcf-client-proxy-creation-and-best-practices.aspx

Learning WCF (O Reilly,2007): http://www.thatindigogirl.com(get all the book code here!)

Michele s blog: http://www.dasblonde.net

IDesign: http://www.idesign.net