Quality of Service for Web Services-Demystification, Limitations, and Best Practices for Performance
With the proliferation of Web services as a business solution to enterprise application integration, the quality of service (QoS) offered by Web services is becoming the utmost priority for service provider and their partners. Due to the dynamic and unpredictable nature of the Web, providing the acceptable QoS is really a challenging task. In addition to this, the different applications that are collaborating for Web service interaction with different requirements will compete for network resources. The preceding factors will force service providers to understand and achieve Web services QoS. Also, a better QoS for a Web service will bring a competitive advantage over others by being a unique selling point for a service provider.
The Web services QoS requirement mainly refers to the quality, both functional as well as non-functional, aspect of a Web service. This includes performance, reliability, integrity, accessibility, availability, interoperability, and security. In the first part of this article, we covered each of the above QoS aspects from a broad perspective. Now, in each coming article we will look into each of the QoS in detail and will try to come up with solutions and explore best practices to be followed. In this article, we are trying to demystify the "performance" aspect of Web Services.
Web Services Performance
The Web services-QoS stack we proposed is shown in the following figure.
As you can see, the performance block (highlighted in purple) in the figure spans across almost all of the Web service layers on the left. It requires tuning at all layers to get a desired level of performance from Web service. Let us first briefly analyze this quality aspect, for demystifying and to see its limitations, and then work in depth on some of the optimal solutions.
Web Services Performance—Demystifying
The performance of a Web Service is measured in terms of throughput, latency, execution time, and transaction time. Throughput represents the number of Web service requests served at a given time period. Latency is the round-trip time between sending a request and receiving the response. Execution time is the time taken by a Web Service to process its sequence of activities. Transaction time represents the period of time that passes while the Web Service is completing one complete transaction. Higher throughput, lower latency, lower execution and transaction times represent good performing Web Services.
Web Services Performance—Limitations
The overall performance of a Web service depends on application logic, network, and most importantly on underlying messaging and transport protocols such as the SOAP and HTTP it uses. The SOAP protocol is still maturing and harbors a lot of performance and scalability problems. The SOAP protocol uses a multi step process to complete a communication cycle.
The SOAP request begins with the business logic of your application learning the method and parameter to call from a Web Services Description Language (WSDL) document. This whole process is time consuming; it requires various levels of XML parsing and XML validation and hence hits the performance of the Web service.
Apart from these factors, the performance of a Web service becomes crucial if it uses the synchronous one where a consuming application is blocked for the time it gets a response from the Web service.
Web Services Performance—Best Practices and Solutions
Analyzing the above situations, following are some of the useful practices and solutions which we should have in mind while developing and exposing it to outside world. I am dealing with them layer by layer of the Web service stack.
- At the Data Layer:
At data layer of a Web service stack, the Web service is only sending/receiving XML messages through the network. Some of the best practices to be followed to achieve the same are listed below:
- Use of compressed XML for sending the messages over network:
SOAP/XML messages are generally bigger in size than normal GET/POST calls, so we should try to compress the message if the network latency is bigger than CPU overhead for compression. Lots of XML compression tools are available from different vendors such as Oracle XDK and there are many open source tools also there to fit the budget.
- Use of simple data types in SOAP messages as far as possible reduces complexity to great extent. This reduces the processing time and increases maintainability; enhancements are easy to do.
At the logical layer, Web service mainly deals in processing SOAP/XML messages. Being XML intensive at this layer, we should try to optimize XML processing steps. Some of the best practices to be followed to achieve the same are listed below:
- Use of efficient & lightweight parsers:
There are many parsers available on the market, each vying for its performance. But, to get performance we should first analyze our application and its requirement. If the application requires big XML files to be exchanged, a SAX parser would be the best over a DOM parser. A DOM parser actually loads the whole document in memory and thus utilizes a considerable amount of the memory and processor. Instead, a SAX parser is event based, is faster, and does not consume much memory.