IBM BS029ML Self Help Guide - Page 156

Registry Service loads and caches a small number of objects that are regularly accessed in the engine. This improves performance; however, the trade off is that the cached objects are possibly stale compared to their database counterparts. This applies particularly in a cluster environment. If the age of those objects causes a problem, try reducing the refresh rate for the respective entities. For a complete list of the Portal Services provided with WebSphere Portal Server V6.0.x, and a description of the many parameters that can be tuned with regards to each service, consult the WebSphere Portal Server Version 6.0 Information Center. To provide performance and deployment options, some Portal Services, such as search and document conversion, can be executed remotely. The Portal Search service can now reside on a separate machine or as part of a Portal cluster. The remote search service can be utilized either through the SOAP protocol or through EJB. This allows Portal users to search Portal content with the remote search service, but it also allows other search engines to tap into the remote search engine to search portal content. Document conversion is another service that can be deployed remotely. Document Conversion Services is integrated with Portal Document Manager and IBM Common Mail portlet. Documents received as attachments to e-mail can be viewed in the browser even if the application that created the document is not installed. Document Conversion Services also allows documents to be searched by content. Document Conversion Services supports many of the most widely used applications and converts them to HTML and XML. To better balance processing power, Document Conversion Services can be delegated to a remote server. In this case, the service is accessed simply with HTTP, rather than SOAP or EJB. Since WebSphere Portal Server was designed with a Services-Oriented Architecture in mind, we have been able to continually add new services, which can be used by IBM, our customers and our partners to build more powerful Portlets and Portal applications. When customer requirements demand that the service be available outside the Portal framework, we can leverage WebSphere Application Server's support for J2EE and Web Services standards to execute remote services. 5.2 Optimization Performance is a critical part of any WebSphere Portal Server based solution. In this section, we look at the major parameters responsible for performance tuning WebSphere Portal Server. Important: No amount of tuning will resolve a performance problem attributed to a badly written Java application. Many customers neglect this important fact and waste a considerable amount of time and effort tweaking around with the WebSphere Portal Server parameters in the hope that a configurational change may resolve matters. Remember, the 20:80 rule: Only a 20% improvement can normally be gained from tuning improvements, while roughly an 80% gain is attributed to development. Therefore, we strongly recommend following the IBM Recommended Best Practices during development. 5.2.1 Knowing where to start Those familiar with WebSphere Portal Server will be aware that the product is actually deployed as a J2EE Enterprise Application on top of WebSphere Application Server (or WebSphere Process Server with certain restrictions). It is for this very reason that the recommended starting point for implementing a WebSphere Portal Server performance tuning exercise actually involves tuning the underlying WebSphere Application Server instance. 142 IBM WebSphere Portal V6 Self Help Guide