While Windows Communication Foundation (WCF) does greatly simplify the ability to roll out a reliable, scalable, and secure communication framework for distributed Windows applications, software developers can run into problems if they are not aware of all of the components involved. In a session on Scalability and Throughput Considerations for WCF at the SD West Show, Michele Bustamante, chief architect, IDesign, Inc. provided an overview of some of the issues that can come up.
She started the presentation by defining the concepts of scalability, throughput and performance. Performance is the overall time to complete a request, which is influenced by server resources and communications overhead. Throughput refers to the number of requests that can be processed per unit of time. Scalability refers to the ability to perform as server power is increased and additional servers are added. In WCF, the most important considerations to these three concepts are the channel overhead, the number of service hops, the hosting model, and load balancing.
Key components of channel overhead are bindings, used to configure different parts of the channel stack. When these components are committed to certain processes, they are not available to others, even though the servers themselves have the overhead to handle tasks. Bustamante noted that, in general, the default settings of WCF work, but when the system begins to crawl, it is important for the software engineer to be aware of which configurations could be changed to improve performance.
Proxies are used to create an equivalent communication channel to call a service and can improve performance between a client and service by reducing the need to set up new channels. But Bustamante said, "Don't forget to close your proxy. If you forget, you will find some interesting results. You will get unexpected behavior and will not know why."
The communications channel will fill with requests that are no longer being used. It is fine if you cache the proxy for a few users, but performance can degrade if you are doing so for thirty. She does suggest caching the credentials if the connection between the application and web server is secure.
In theory you can cache the whole proxy for one user, but that means that the user will always connect to the same back end. Bustamante said this could turn out to have bad scalability effects, depending on the load, for that user.
Another issue is the number of service hops that must be made for a given application and the number of services called by a client request. As the number of requests goes up, these have the potential to overload the number of open communications channels slowing down performance and scalability for all applications.
Some applications, particularly real-time ones cannot withstand more than two service hops. Bustamante recommends taking a for example, vertical slice of the system from client-to-web-service-to-app-service-to-third-party-applications and benchmarking that. Then do another benchmark after you have turned on security and reliability services to see if the request is fast enough, and identify any obvious bottlenecks.
Another issue is the type of server hosting model. In Windows Server 2003, you have a choice of using II6 6 for HTTP services or Windows Service for non-HTTP. Windows Server 2008 gives you an option of using Windows Activation Service (WAS) for all protocols.
Although WAS does add some overhead, it provides better health monitoring of the communication channel, and has the ability to automatically queue up communications settings in a way that they can be resumed if the communications server needs to be rebooted. However, Windows Services does have the advantage that it is compatible with a broader range of legacy systems. Bustamante noted, "If the customers are more concerned with deployment and management and it is not a big deal to restart the system, then Windows Services works."
Another thing to be aware of is the number of processes that can be running at each level of the communications stack. WCF has settings for MaxConcurrentCalls, MaxConcurrentInstances, and MaxConcurrentSessions, which feed application calls through the systems. Bustamante noted that in general, the defaults are adequate for most applications, but the application developer needs to be aware of these numbers when a problem emerges.