Scalability

Scalability can mean a lot of things to many people. For the purposes of this discussion, we will define scalability as the ability to adapt to increases in client requests. Ideally, we will set things up such that on a certain hardware configuration we can handle X requests per second. If we need more capacity, adding a second box will be all we need to do to handle somewhere between 1.8 * X requests/second and 2 * X requests/second. What can you do to be able to handle this kind of scalability? You do a lot of the same things that you would do to make a Web site more scalable:

• Make the Web Service stateless.

• Use a Web Farm to deploy the Web Service.

• Use components that can scale with you.

• Use your head.

That last item, use your head, is the most important item to follow. Every decision you make can potentially help or hinder scalability. Just ask yourself, “Will this decision make it difficult to have two machines running the same application?” If the answer is Yes, figure out how to accomplish the task another way. For example, always use stored procedures when accessing the database. A stored procedure executes faster and returns the data quickly. Use disconnected datasets. By programming SQL Server (or some other database) to return the data to you as a disconnected dataset, you spend less time in the database and allow other users to do their work. Use this same kind of thinking whenever you have to access a shared resource. Now, let's look at the first three items.

Stateless Web Service and Using a Web Farm

A Web Farm is a collection of servers to which a load balancing mechanism, such as a router, can send requests. To take advantage of this load balancing, your Web Service should not maintain any internal state between Web Service calls. When you maintain state, you hamper the ability of the client to use machines deployed in a Web Farm. When the server maintains state, this adds the requirement that the Web Service calls themselves are sticky. A sticky relationship means that the load balancing mechanism routes the client to some server and then routes all future requests from that client to the same server. If one server bunches up on requests, the benefits of the Web Farm decrease. What do you do if a need for state management exists on a per-client basis?

If state information is required between invocations, the state data should be maintained on the server and stored within SQL Server. ASP.NET allows for the storage of state data across a Web Farm. Using this feature is covered in Chapter 9, “Stateful Services.”

Scalable Components

If you use other, pre-existing components, make sure that they can also scale. If they can, you are in luck, and you do not have to do any extra work. However, if those components do not scale, what can you do? This question is important. In an effort to reuse existing code, many developers do not think about the scalability of that code. If you must use an existing, poorly-scaling component, there are ways to use it and not hurt your Web Service. It may make sense to place the objects into a COM+ application or library to take advantage of the COM+ object pooling and other capabilities. Do this if startup costs for the object are expensive. If the object can handle only a small number of concurrent connections, consider wrapping the access to that code via Microsoft Message Queue (MSMQ). The MSMQ approach allows you to be responsive to the client while queuing up completion of the requests. A request in a queue will not slow down the Web Service. The worst thing that happens when you use MSMQ is that the client may not be able to get the response immediately.