Bottlenecks in performance of Web services

Bottlenecks in performance of Web services
Web services can encounter performance bottlenecks due to the limitations of the underlying messaging and transport protocols. The reliance on common widely accepted protocols such as HTTP and SOAP, however, make them a permanent burden that must be shouldered. Thus it is important to understand the workings of these limitations.

HTTP

HTTP is a best-effort delivery service. It is a stateless data-forwarding mechanism which tends to create two major problems:

• There is no guarantee of packets being delivered to the destination.
• There is no guarantee of the order of the arriving packets.

If there is no bandwidth available, the packets are simply discarded. Bandwidth is clearly a bottleneck, as users and amounts of data running over the network increase. Traditionally, many applications assume zero latency and infinite bandwidth. Also traditionally, applications use synchronous messaging. Synchronous messaging is fine when you run an application on your own computers; components communicate with latencies measured in microseconds. However, with Web services, they communicate across the Internet, which means latencies are measured in tens, hundreds, or even thousands of milliseconds.

Although newly designed protocols like Reliable HTTP (HTTPR), Blocks Extensible Exchange Protocol (BEEP), and Direct Internet Message Encapsulation (DIME) can be used, widespread adoption of these new protocols for Web service transport like HTTPR and BEEP will take some time. Hence, application designers making use of Web services should understand performance issues of Web service such as latency, and availability while designing their systems. Some of the ways to improve Web service performance are given below.

Use of asynchronous message queues
Applications which rely on remote Web services can use message queuing to improve reliability, but at the cost of response time. Applications and Web services within an enterprise can use message queuing like Java Messaging Service (JMS) or IBM MQSeries for Web Service invocations. Enterprise messaging provides a reliable, flexible service for the asynchronous exchange of critical data throughout an enterprise. Message queues provide two major advantages:

1. It is asynchronous: A messaging service provider can deliver messages to the requestor as they arrive and the requestor does not have to request messages in order to receive them.
2. It is reliable: A messaging service can ensure that a message is delivered once and only once.

In the future, Publish & Subscribe messaging systems over the Internet such as the Utility Services package from alphaWorks , can be used for Web service invocations (see Resources).

Private WANs and Web service networks
Use of private WANs/extranets and Web services networks can be a suitable option for businesses depending on Web services which are mission-critical. These private networks provide low network latency, low congestion, guaranteed delivery, and non-repudiation. However, in some cases it could be costly to have a private network.

SOAP and performance

SOAP is the defacto wire protocol for Web services. SOAP performance is degraded because of the following:

• Extracting the SOAP envelope from the SOAP packet is time-expensive.
• Parsing the contained XML information in the SOAP envelope using a XML parser is also time-expensive.
• There is not much optimization possible with XML data.
• SOAP encoding rules make it mandatory to include typing information in all the SOAP messages sent and received.
• Encoding binary data in a form acceptable to XML results in overhead of additional bytes added as a result of the encoding as well as processor overhead performing the encoding/decoding.

The XML processor must be loaded, instantiated, and fed with the XML data. Then the method call argument information must be discovered. This involves a lot of overhead as XML processors grow to support more XML features.

The role of the XML parser in SOAP performance

Most existing XML parsers are too expensive in terms of code size, processing time, and memory foot print because these parsers have to support a number of features like type checking and conversion, wellformedness checking, or ambiguity resolution. All these make XML parsers require more computing resources. Some applications can consider using of stripped down version of XML parser which have a small code size and memory foot print.

Also, most of the current SOAP implementations are Document Object Model (DOM) based. DOM parsers are inherently slow to parse the messages. SAX-based SOAP implementations can be used to increase throughput, reduce memory overhead, and improve scalability.

Compressing XML

SOAP uses XML as its payload. And if we consider thousands of SOAP messages being transmitted over the Web, the network bandwidth is being pushed to its limit. XML's way of representing data usually results in a substantially larger size than representing the same data in binary, which is on average 400% larger. This increase of the message size creates a critical problem when data has to be transmitted quickly, which effectively results in increase of the data transmission time. Some application designs should consider techniques for compact and efficient representation. One of the ways to achieve this can be to compress the XML -- especially when the CPU overhead required for compression is less than the network latency.

Other factors affecting Web service performance

There are still more factors that can affect Web service performance that are outside the control of the Web service application, such as:

• Web server response time and availability.
• Original application execution time like EJB/Servlets in Web application server.
• Back-end database or legacy system performance.