Performance best practices for Web services

Performance is always a concern with Web services- there are better ways to designing a performant distributed system than sticking it behind a HTTP port and throwing verbose XML messages at it.

Lately I've been exploring some mechanisms to address performance issues for Web services. Most of these approaches target bottlenecks at the lower level SOAP layer, rather than at the design level. I've looked at some articles and technical papers that present metrics and guidelines. From them I've distilled the following performance best practices:

Design your Web service interface to minimize the network traffic. A 'coarse-grained' API is better, as you minimize the number of requests a client has to make to get information. [1][6]
Large SOAP messages are a performance bottleneck due to time spent parsing them. Keep your payload size as small as possible [1]
Complex SOAP message are a performance bottleneck due to time spent serializing/deserializing messages. Keep your payload complexity low. However, payload complexity and payload size are often design tradeoffs. [1]
SOAP intermediaries (gateways, proxies) should minimize parsing of messages.[1]
Better XML parsing techniques. [3] For most applications, event driven parsers (SAX style) are more performant than DOM style parsers.[1][6]
Document/Literal style SOAP messages are smaller and less complex than RPC/SOAP message. [1][5]
Security has performance costs. Not all SOAP traffic needs to be secure. The performance costs of an end-to-end security (i.e. WS-Security) is, in most cases, higher than a transport level security mechanism like SSL. [1]
Caching is a way to improve performance for processor-intensive services, though this is applicable only for read-only type of services. [2]
Many of the performance best practices for web applications will apply here too (using EJBs v/s JavaBeans, passing-by-reference of EJB components, Hardware and capacity settings, JVM setting etc.) [2]
Persistent connections are good for performance in case of a large number of messages of small payload size. For larger messages, this has less of an effect [3]. HTTP keep-alive is way [2] to request that a HTTP connection persist, though this is a default in HTTP/1.1.
Streaming connections are good for performance in case of a large payload size. HTTP 'chunked encoding' is a kind of streaming, and is supported by HTTP/1.1. [3][6]
Binary encoding of some payload elements should be considered. [3]

However, all said and done, remember the reasons for which you are choosing Web services - interoperability across heterogeneous environments- and not for performance!

来源 http://www.soaprpc.com/archives/000020.html