 | Level: Advanced Holt Adams (rhadams@us.ibm.com), Senior Solution Consultant, IBM jStart
02 Mar 2004 With the introduction of Web services as an open standards integration technology for Enterprise Application Integration (EAI) and Business to Business (B2B) Integration, you can do many things to promote operational efficiencies and thus ensure the successful architecture and deployment of a solution. Continuing from the previous article on Web services-related performance issues, this article will explain other secondary issues that affect Web services performance based on real-world experiences and provide suggestions for how best to architect, develop, and deploy Web services-based solutions.
In the previous issue of the Best Practices for Web services column (see Resources), I explained how service-related issues such as SOAP message parsing, the marshalling/unmarshalling between XML and Objects, and the processing of WS-Security features may affect the overall performance of any particular Web service. In this issue I discuss some of the other issues that may pose a similar hindrance to efficient Web services interaction.
Other considerations that influence performance Your solution will need to address the three major bottlenecks (covered in Part 1) that could potentially contribute between 50% and 75% of the processing times of your Web services invocations. An example of such a service that could be impacted to this degree is a simple inquiry into a well-indexed relation database where the service implementation does minimal processing. When the business logic executed for your services is more complex and interfaced with backend systems, the overall impact to your service response times, due to the three major bottlenecks, may in some cases be insignificant. Now, let's review a few other lesser considerations that will also enhance your solution's performance.
JavaBean versus EJB components You must now choose whether to use JavaBeans or EJB components for your Web service providers. This decision is no different than when you're architecting your other J2EE applications. If your solution doesn't require the J2EE runtime support for transaction, security, and management that's enabled through the use of EJB components and the EJB container, then JavaBeans will suffice and will provide better performance. If you're using EJB components and deploying them locally within the same JVM as the SOAP engine, then ensure that you deploy them such that they are called using pass by reference. By enabling pass by reference, the parameters of the method are not copied to the stack with every remote call, which can be expensive. Enabling pass by reference can improve performance up to 50%, when the SOAP engine (EJB client) and the Web service provider (EJB Server) are installed in the same application server instance, and remote interfaces are used.
Validation of messages by parsers Many parsers can validate the structure of SOAP messages to ensure they are well-formed and adhere to specific XML schemas. This allows the Web service implementation code to be optimized toward the business logic and to be invoked only for valid requests. Unfortunately, a majority of the time, the parser's message validation functions are not enabled due to its impact on performance.
If you're using the Apache Xerces parser, you can enable validate for both DOM and SAX parsing. However, remember that turning on validation will not make Xerces report any errors it uncovers. You'll also have to implement the org.xml.sax.ErrorHandler interface and register your implementation with the parser using the setErrorHandler method.
It's recommended that you not enable message validation through the parser if performance is a high priority, but rather, as good standard programming practice, have the code that processes the parameters validate their values.
Optimizing performance using cache
For Web services that support HTTP (XML Web services and Internet Web Services), you can actually cache the results of their processing for use on future requests. The runtime can save the responses of the Web services and automatically serve them up for popular requests, significantly speeding up processor-intensive service requests. Of course, caching is really only applicable for read-only types of services that perform queries into databases or provide access to relatively static content (such as product catalog, marketing information, historical financial data, and pricing data). Various parts of the SOAP message can be used to uniquely identify the request for caching.
The caching capability is provided by defining caching policies and constructing cache-ids based on the following:
- SOAP Action
- SOAPEnvelope
- Port component
- SOAP operation
- SOAP operation parameters.
The polices include rules and expiration intervals to ensure the validity of the saved information. Components that do not require parsing of the SOAP Envelope will provide the best performance gains. For example, defined in the SOAP specification is the SOAPAction HTTP header in the request, which HTTP proxy servers use to dispatch requests to particular HTTP servers. This header can be used in a cache policy to build IDs without having to parse the SOAP message. The cache-id can then be used to retrieve service response information from the cache to optimize performance.
Retrieval of service bindings from a UDDI registry UDDI registries are used to publish Web services information for dynamic discovery. Late binding of a service's access point is one use of an UDDI registry that is common today. During the client's service invocation, the UDDI registry is queried to obtain the access point (URL) of the service. This approach is often used to enable the use of backup servers in performing fail-over support for improving service availability. Likewise, it affords the service provider the ability to migrate service requests from one system to another for the purpose of maintenance without disrupting the processsing of existing service requests. However, the UDDI query can add significant path length to a request and, if done for every request, can degrade a client's performance. One approach is to front-end the local service proxy created from the service provider's WSDL with a general proxy that queries the UDDI registry and caches the access points for a given period of time. The client application calls the general proxy that calls the service proxy to invoke the service provider.
Figure 1 - Optimizing UDDI inquiries
If the call to the Service proxy fails due to a non-HTTP Status code of 200, then the general proxy queries the UDDI registry again to see if an alternative address is available for use on a follow-up call to the service proxy. This allows the client application code to be simpler, the UDDI registry queries to be minimized, and the client to bind dynamically to the service in order to ensure higher availability with optimal performance.
Performance tuning of Web solutions
In addition to the bottlenecks and considerations already discussed, the majority of other runtime performance issues and resolution of such issues for a Web services solution will be no different than other applications. This is because Web services provides universal interfaces of business functions. The definition of how the interface is described (WSDL), how the interface is published and discovered (UDDI or WSIL), and how it's invoked (SOAP) are unique to Web services, but the actual implementation of the services that executes the business logic is often based on existing infrastructures (such as J2EE, .NET, CICS, IMS).
When JavaBeans, Enterprise JavaBeans, or Message Driven Beans are used for the implementations of Web services in a J2EE environment, the application server needs to be tuned the same way regardless of whether these components are deployed as Web services. For example, each WebSphere Application Server process has several parameters influencing application (think Web service) performance. You can tune applications, Web containers, EJB containers, and the application servers.
By taking a look at the following, considered as the Tuning Parameter Hot List in WebSphere-based solutions, you can understand what issues need to be evaluated for most other Web solutions:
-
Hardware and capacity settings
-
Java virtual machine heap size
-
Application assembly performance checklist
-
Data sources connection pool and prepared statement cache
-
Solaris operating system TCP_TIME_WAIT_INTERVAL
-
Pass by value/Pass by reference
-
IBM HTTP Server access logs
-
HTTP keep alive connections
-
Transaction logs
-
Object Request Broker FragmentSize.
Once your solution is operational, you will need to evaluate much of the above, where you can capture measurements, to allow you to understand the change in your solution's behavior as a result of applied changes. You can view details of these topics at the WebSphere InfoCenter (see Resources).
Summary
Successfully optimizing performance for Web services is part experience, part art, and part discipline in being systematic in your approach to measuring criteria, analyzing information, and making sound adjustments. First, you must make good decisions during your architectural and design phases as described above. Then once you have a solution that is operational, it is an iterative process to fine tune your solution by capturing measurements from simulated loads, adjusting, and measuring again to understand their influence.
IBM has made significant progress in optimizing SOAP parsing. WebSphere Application Server V5.02 provides performance improvements of two to three times across a set of primitive workloads as compared to Apache and the tech preview of Web Services implementations shipped in WebSphere Application Server V5.0. Also, WebSphere's support of JSR 109 and 101 with Document/Literal messaging style includes serializer / de-serializers routines that are based on XML schema data types that provide enhanced performance over SOAP encoding.
Resources
About the author | | |
Holt Adams is currently a senior-level IT Architect supporting the IBM jStart program, working with customers and business partners to adopt emerging technologies such as Web services. After graduating from the University of Tennessee in 1982 with an electrical engineering degree, he joined IBM in Research Triangle Park, N.C. Holt's experience includes hardware and software development of communication and networking products, technical marketing of mobile and wireless solutions, and architecture and integration of Internet-based solutions. For the past three years he has been focused on promoting Web services as an IBM strategic integration technology, working with customers to initially develop proofs of concepts, and, more recently, to develop solutions for production environments. Holt can be reached at rhadams@us.ibm.com. |
Rate this page
| |
