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:

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.

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.