Modifying Web Service Performance
Once you have identified slow code, the next step is to address those issues. One popular technique for addressing how data is passed between the application and the web service is to carefully monitor and optimize the amount of data transmitted in each SOAP call.
In this circumstance, one change you can consider is whether your code should be "chatty" or "chunky." As the names imply, chatty calls are those that occur often and pass little data, while chunky calls occur less frequently but do more work when they do occur. While at first glance it might appear that large calls to the service are more efficient, that's not necessarily true. A chatty interface passing less complex data more often may turn out to be less computationally expensive because its marshalling isn't as complex.
How do you determine whether or not you should use chatty or chunky calls to your service? There's no easy way that applies to all circumstances; it depends on the amount of data and frequency of calls. The best action is to prototype both the type of interface and the performance profile. By investing a little time early in the development phase, you can ensure you made the right performance choice and do not have to go back and make substantial changes after you deliver a working application.
That's not to say that you might not have to go back and make adjustments to your calls once the application is done. For example, you may find that in certain web services features, chunky calls are more efficient because of the overall volume of calls. Prototyping your data and calls ahead of time, however, helps you better determine the optimum amount of data to exchange with your web services in individual transactions.
Another common problem is certain .NET services can be computationally expensive. At first glance, it may appear you have little control over what the .NET Framework does, however, the framework is rich in features and there are often multiple ways of obtaining the services you need. Alternatively, the framework calls you to do more work than you actually need. You won't know any of this unless you have complete profiling information on child behavior from your own methods.
Taking the Uncertainty Out of SOA Performance
Web services represent the potential to reuse code components features across multiple applications simultaneously. The loosely coupled model and XML/SOAP communications standard is simple to understand and implement, but the performance implications are not yet well understood. In particular, it's unclear how a web service used simultaneously by multiple applications will respond to such asynchronous requests.
This uncertainty is magnified when an SOA is considered. Multiple interacting web services, with one or more servicing multiple client applications, may have performance issues that simply can't be detected while developing individual components in isolation. You have to look at the SOA and its applications as a complete system, rather than a set of parts.
You're going to be feeling your way in building and testing the performance of web services. That makes it important to profile these services, both by themselves and within the context of the entire application or applications, to determine where slow code and bottlenecks may reside. In doing so, you can address those issues by changing the calls to or within the web service, modifying expensive database calls, simplifying complex code paths or using other techniques.
Courtesy of Compuware.
