Performance

One of the most important of the “abilities” is performance. The Web Service needs to be able to return results back to the user as fast as possible. Most of the time, there will be simple things you can do to improve speed. Occasionally, you will have situations where the Web Service call will take several minutes or even hours to complete. In this section, we will look at the simple cases and then the hard case of long-lived calls.

First, let's take a look at some simple gains you can get through improvements to your own hardware. The first thing you should do is identify which Web Methods tied to the Web Service get called the most. Identify the Web Methods that make up 80 percent of the calls to the Web Service. Then, look at them for the following characteristics:

• Input/Output (I/O) Bound— Determine if the Web Method mostly accesses the disk. Examples include a simple lookup in a database or reading a file off the hard drive.

• Computation Intensive— Determine how much the Web Method taxes the CPU. If the Web Method does a lot of math, image manipulation, general analysis, or fires a complex SQL query, you have a computation intensive Web Method.

• Memory Hog— Okay, this is not a great name, but you get the idea. If the Web Method uses lots of memory to perform its job, you have a memory hog.

Hardware solutions to these three items come pretty easily. For each, I will discuss what you can do with hardware and software to improve speed. These tactics are not secrets, by any means. Rather, this discussion is a reminder about some of the best practices. A particular Web Method may have all three items as issues, although that is unlikely for the majority of cases. After you identify which combination of these three exist, you can apply some hardware remedies.

I/O Bound

An I/O bound Web Method will benefit the most from faster hard drives. Look at how fast the drive spins as well as seek times. Also, keeping the hard drive defragmented will make it easier for the disk to deliver all the information in one burst.

In addition to buying faster hard drives, you can also look at how you gather the information from the disk. For example, it may be faster to do all of your data reads and writes in one spot in the code—that is, do all your reads at one time. When writes happen, save them for one burst as well. Most programs do not read and write to more than one or two files. By doing the reads and writes in a batch, you increase the likelihood that the drive's heads are near where your data lives. If the drive does not have to seek a location on the disk, your reads will happen faster.

Why would the head move? If the routine is doing sporadic reads, other processes may get a slice of processor time and need to go to another location on disk. If your reads happen sporadically, the head may have moved by the time you get control back. You also can take advantage of any buffering the operating system may be doing for you. Even if you only read one byte at a time, the operating system is reading data back in larger chunks.

Computation Intensive

A computation-intensive task will benefit from a combination of a faster CPU and memory bus. The faster the data can get to and from the processor, the faster the computation will complete. Of course, if the operation is not manipulating data but is simply crunching numbers, a faster memory bus will have no benefits.

To speed things up as a programmer, look at using some simple best practices. For example, you can allocate all of your memory in one batch and avoid creating objects in any loops. Allocating the objects all at once increases the likelihood that they are near each other in memory. When they get transferred from memory over to the CPU, you increase the likelihood that those objects live on the same page of memory. You can also unravel loops, use methods that are faster, and so on.

Find some way to profile your code and identify the bottlenecks. If you are profiling the method, you can either time the method yourself or use profiling tools. To time the method yourself, just note the time down to the millisecond, execute the method, and check the time again. Then, write the difference out using either the Trace or Debug objects. When you identify the slower methods, you can use the same technique to profile blocks of code within the method. After some checks, you will know what parts of the code you need to examine and make faster.

Memory Hog

As far as hardware goes, all you can do for an application that needs a lot of memory is give it more memory. Memory prices have fallen sharply in recent years, making it easier to throw memory at the problem.

Sometimes, more memory is not the solution. In that case, look at how you are allocating memory. If you think you are doing a good job, you can always tell the garbage collector to clean up. You may need to do this when the Web Service gets to be so popular that the service is grabbing memory faster than the garbage collector can manage. When you are running a .NET-based application, CPU utilization becomes something that you really want to watch. If that CPU does not have some spare cycles, the garbage collector may only run in crisis situations. This can severely affect performance. What can you do?

First, look and see if the code calls new too much. You may be able to reuse objects occasionally. Some of the code may overdo things as well.

Second, conduct a code review (this is a good idea for I/O-bound and computation-intensive services as well). By having others look at your code, you should be able to avoid some problems. Those extra eyes will identify potential problems, such as memory bloat. Also, if the Web Method is doing its job correctly, you will be able to update the specifications on the hardware so that it will be able to perform well with the Web Service.

Long-Lived Web Method Calls

Some Web Method calls can take a long time to complete. When a given call takes a minute or longer to return, what should you do? Forcing synchronous execution means that you would have to keep the communication channel open for the duration of the processing. This is not the best approach. Instead, you want to provide some method of asynchronous processing. The method that you use will depend on what types of demands you can place on clients. The following are just a few of the options available to you:

• Return the results to a Web Service provided on the client.

• Return a unique ID that the client can use to poll for results.

• Have the client provide a place for the results to be delivered, such as an e-mail address or MSMQ location.

When are these different options good ideas?

If you can require clients to provide their own Web Service that complies with a WSDL that you define, you can return the results to the client asynchronously when the call completes. The advantage of this approach is that the client can act on the information as soon as it arrives, and they do not have to poll to get the results. This may also be an option when you provide the client and the main Web Service.

If the client cannot run a Web Service, you will want to look at polling or delivery to a non-Web Service endpoint. The client may not be able to run a Web Service for any number of reasons—device constraints, deployment difficulties, or security concerns. If any of these items occur, you will want to look at alternatives. One alternative is to return a GUID to the user. Then, when the Web Service completes, it can store the result and associate it with the GUID. The client will periodically poll the server asking if the request is done. The server will return a status value of either “ready” or “keep waiting.” As soon as the server has completed, the client will then request the actual data and the server can remove the result from its stores.

You could also provide a drop point for the data when it is ready. Because the result will come back as XML, this XML can be delivered to a predetermined location as well. The client simply needs to tell the server where to put the data, and to make sure that the server has access to it. Good things to use are e-mail, secured FTP directories, and file shares if the Web Service and client are on the same, secure network. When depositing the file to a filename, the client should decide what the file will be named. Alternatively, the Web Service could send back as a return value the name it will be giving the file. [GUID].xml will always be a safe thing to name the file because GUIDs are globally unique. (“Globally unique” is in the name, right?) If it makes sense, the returned file does not even need to contain XML. Inside the WSDL, you could indicate the MIME type of the returned item instead.

Polling and sending the XML results are the approaches that place the lowest demands on the client in terms of services it needs to run. The flip side is that the client program may be the hardest to write. Conversely, requiring a Web Server to listen for responses places extra demands on the client in terms of capability and security. The client's Web Server does open the client up for possible attacks, especially if it is on the public Internet. You can limit the potential for attack by limiting access to the client to the server machine only.