JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

The following pages have their detailed tips extracted below

• Email summarizing best practices for Promoting Scalable Web Services
• Caching SOAP services
• Quality of service for web services
• Scaling SOAP-based web services.
• Scaling web services
• Webservices SOAP communications overheads

The following detailed tips have been extracted from the raw tips page

http://lists.xml.org/archives/xml-dev/200201/msg00477.html
Email summarizing best practices for Promoting Scalable Web Services (Page last updated January 2002, Added 2002-02-22, Author Roger L. Costello, Publisher Costello). Tips:

• Web services best practices are mainly the same as guidelines for developing other distributed systems.
• Stay away from using XML messaging to do fine-grained RPC, e.g. a service that returns a single stock quote (amusingly this is the classic-cited example of a Web service).
• Do use course-grained RPC, that is, use Web services that "do a lot of work, and return a lot of information".
• When the transport may be slow and/or unreliable, or the processing is complex and/or long-running, consider an asynchronous messaging model.
• Always take the overall system performance into account. Don't optimize until you know where the bottlenecks are, i.e., don't assume that XML's "bloat" or HTTP's limitations are a problem until they are demonstrated in your application.
• Take the frequency of the messaging into account. Replicate data as necessary.
• For aggregation services, try to retrieve data during off-hours in large, course-grained transactions.

http://www.javaworld.com/javaworld/jw-03-2002/jw-0308-soap.html
Caching SOAP services (Page last updated March 2002, Added 2002-03-25, Author Ozakil Azim and Araf Karsh Hamid, Publisher JavaWorld). Tips:

• Repeated SOAP-client calls to access server state can choke a network and degrade the server performance. Cache data on the client whenever possible to avoid requests to the server.
• Ensure the client data remains up to date by using a call to a server service which blocks until data is changed.

http://www-106.ibm.com/developerworks/webservices/library/ws-quality.html
Quality of service for web services (Page last updated January 2002, Added 2002-02-22, Author Anbazhagan Mani, Arun Nagarajan, Publisher IBM). Tips:

• Quality of service requirements for web services are: availability (is it running); accessiblity (can I run it now); integrity/reliability (will it crash while I run/how often); throughput (how many simultaneous requests can I run); latency (response time); regulatory (conformance to standards); security (confidentiality, authentication).
• HTTP is a best-effort delivery service. This means any request could simply be dropped. Web services have to handle this and retry.
• Web service latencies are measured in the tens to thousands of milliseconds.
• Asynchronous messaging can improve throughput, at the cost of latency.
• SOAP overheads include: extracting the SOAP envelope; parsing the contained XML information; XML data cannot be optimized very much; SOAP requires typing information in every SOAP message; binary data gets expanded (by an average of 5-fold) when included in XML, and also requires encoding/decoding.
• Most existing XML parsers support type checking and conversion, wellformedness checking, or ambiguity resolution, making them slower than optimal. Consider using of stripped down XML parser which only pe4rforms essential parsing.
• DOM based parsers are slower than SAX based ones.
• Compress the XML when the CPU overhead required for compression is less than the network latency.
• Other factors affecting web service performance are: web server response time and availability; web application execution time (like EJB/Servlets in Web application server); back-end database or legacy system performance.
• Requests results should be cached where possible.
• Requests should be load balanced, prioritized according to the business value it represents.
• Carry out capacity planning to enable the performance to be maintained in the future.
• Extreme care should be taken to make sure that resources are not locked for long periods of time, to avoid serious scalability problems.
• Measure the performance of your web services by adding code measuring elapsed time to the generated service proxy (and recompiling). [Article gives an example].

http://www-106.ibm.com/developerworks/webservices/library/ws-testsoap/
Scaling SOAP-based web services. (Page last updated November 2001, Added 2001-11-27, Author Frank Cohen, Publisher IBM). Tips:

• Cache the web services description language (WSDL) in a centralized database and periodically check for newer versions.
• Cache schema definitions for scalability.
• Use simple SOAP data types (String, Int, Float, NegativeInteger).
• Each new data type introduces a serializer to convert from the XML value into a Java value and back again, which may cause performance problems.
• SOAP messages move much more data than the average HTTP GET or POST call, adversely impacting network performance.
• Transactional SOAP calls need to cache the state of sessions.
• [Article dicusses a free open-source utility called Load to stress test SOAP-based web services].

http://www.sys-con.com/xml/article2a.cfm?id=229
Scaling web services (Page last updated June 2001, Added 2001-07-20, Author Simeon Simeonov, Publisher XML Developers Journal). Tips:

• Use bigger, better, faster hardware, but there is a limit to the scalability of a single server: most application performance does not scale linearly with increases in the hardware power.
• Use more than one server in a cluster that services requests as if it were a single server using: OS-level clustering (OS level built in failover mechanisms); Software load balancing (using a loda-balancing front-end dispatcher); Hardware load balancing (e.g. DNS round-robin to different servers).
• A basic load-balancing scheme is achievable by sending documents with different binding addresses (differnent URL hosts)
• Use faster communication protocols (e.g. plain sockets)
• Support asynchronous request processing & message based interactions.

http://www.xml.com/pub/a/2002/01/16/deviant.html
Webservices SOAP communications overheads (Page last updated January 2002, Added 2002-02-22, Author Leigh Dodds, Publisher XML). Tips:

• Generating XML produces a large amount of data during communications, but this does not mean that the communication will be the bottleneck.
• Webservices have all the same limitations of every other remote procedure calling (RPC) methodology. Requiring synchronous communications across a WAN is a heavy overhead regardless of the protocol.
• If "Web services" tend to be chatty, with lots of little round trips and a subtle statefulness between individual communications, they will be slow. That's a function of failing to realize that the API call model isn't well-suited to building communicating applications where caller and callee are separated by a medium (networks!) with variable and unconstrained performance characteristics/latency.
• Asynchronous messaging may be required for efficient webservices.