IBM BS029ML Self Help Guide - Page 164

Important: It might at first seem counter-intuitive to refrain from increasing the number of maximum database connections; however, we recommend that a small pool be evaluated first and then, if necessary, increased up to a ceiling of no more than 45 connections maximum. Better performance is generally achieved if the value for the datasource connection pool size is set lower than the value for the Web container connection pool. Adopting this approach fits well with the paradigm that the WebSphere queuing mechanism is designed to converge towards the back end, where resources are deemed more expensive. Of course, you should ensure that the total number of maximum connections specified across all WebSphere Portal Server cluster members does not exceed the available number connections offered by your selected database. For DB2, this is the MaxAppls parameter, and for Oracle, the number of processes defined in the ora.init file. The default Prepared Statement Cache setting size on the datasources is generally too small for WebSphere Portal Server. Consider increasing this value, as a larger cache will accommodate more entries and thus prevent useful entries from being discarded to make way for new cache entries. Further analysis can also be determined with Tivoli Performance Viewer, where Prepared Statement Cache discards are an indication of an inadequately sized cache. Caution should nevertheless be exercised, as a larger Prepared Statement Cache will place a greater demand on the Java heap. A Prepared Statement Cache offers a significant performance improvement to any application that uses the same SQL statement more than once. The same SQL statement implies that the structure of the statement is the same, but that parameter data (the values specified on a where criteria or as update or insert values) can vary. Within WebSphere Application Server, a Prepared Statement is a precompiled SQL statement that is stored in a prepared statement object. This object is used to efficiently execute the given SQL statement multiple times. Other options relating to connection pooling For the timeout on requests waiting for new connections, the timeout is currently measured only on the request waiting at the head of the queue, so if the queue is 10 deep, the 10th request will wait for 10 timeout periods before being timed out. Experience suggests that as soon as any queue forms, this policy will result in a rapidly increasing queue length. The active pool is not shrunk in times of low demand, so we recommend that a shrinkage policy be considered for conservation of system and back-end resources, and also to make the system less prone to connections becoming stale when pooled over long periods of time. Attention: We strongly recommend that you invest the time and effort in tuning either DB2 or Oracle, as defined in the IBM WebSphere Portal Version 6.0 Tuning Guide. For DB2, we found the modifications immediately beneficial, with a Portal response time improvement near 50%. For users of Tivoli Directory Server (TDS), tuning the underlying DB2 database is equally as important. 5.2.7 WebSphere security tuning When a user logs into WebSphere Portal Server, it is actually the underlying WebSphere Application Server that performs the authentication task (assuming that no authenticating proxy such as Tivoli's WebSEAL or CA SiteMinder are being used). WebSphere Portal Server then goes on to retrieve the security context from WebSphere Application Server and continues the login. Several WebSphere Application Server security parameters are therefore important when considering the overall performance of the Portal. 150 IBM WebSphere Portal V6 Self Help Guide