Tuning Guide for BEA WebLogic Server on HP NonStop Servers 528917-002 Author: Santosh Menon November 17, 2005
TABLE OF CONTENTS 1.0 Introduction ......................................................................................................................................... 3 2.0 Background Information ....................................................................................................................... 3 2.1 Connection Management ................................................................................................................. 4 2.2 The Need for Connection Pooling ..........
1.0 Introduction The purpose of this paper is to discuss configuration guidelines, development best practices, and tuning information for BEA WebLogic Server for HP NonStop™ servers.
2.1 Connection Management A key area of resource usage in multi-tier enterprise applications is the definition and management of connections between applications and databases. One simple type of connection is a one-to-one mapping between an application and a database. An application requests a database connection from the relevant database driver and executes various statements using the connection. When finished, the application releases the connection.
// // Once the DataSource is registered in the JNDI namespace an // application can lookup the Datasource and use it // try { Context ctx = new InitialContext(); DataSource ds = (DataSource) ctx.lookup(“jdbc/warehouseDS”); Connection dbconn = ds.getConnection(username, password); // Execute db statements using the connection dbconn.close(); } catch (Exception e) { //handle exceptions } In the preceding code fragments, the Connection object represents a physical connection to the database.
1. The application server is configured with information about the JDBC driver ConnectionPoolDataSource. 2. On startup, the application server pre-creates the DataSource for each configured database in the application server. 3. The server gets a set of PooledConnection objects from the ConnectionPoolDataSource and caches them. Each PooledConnection object represents a physical database connection. This is done as per the configuration for each DataSource. 4.
1 getConnection JDBC Application 4 Return the logical connection to caller Application uses the 5 connection to do DB work 2 Choose a free Pooled Connection (create if necessary) Application Server Pooled Connection Object Cache 8 Mark PooledConnection as free for later reuse 6 Application closes the connection 7 3 Driver notifies application server so that the Pooled Connection can be reused for future connection requests Get a logical connection from the pooled Connection JDBC Driver When t
When XADataSources are used, WebLogic Server gets the XAConnection objects from the JDBC driver and acquires the associated logical Connection object from the XAConnection and caches them both. The WebLogic Server needs the XAConnection object to perform transactional work using the XA facilities and it uses the logical Connection object to wrap and pass onto the application on demand. The following diagram outlines the WebLogic Server Connection pooling Model.
2.5 JDBC Statement Pooling JDBC 3.0 introduced the concept of statement pooling, where a JDBC Statement object is tightly coupled with the underlying physical DB Connection. A statement prepared for one connection cannot be used with another connection. Note that statement pooling applies only to PreparedStatement objects. It is recommended that all applications use PreparedStatements to prepare and execute SQL statements. JDBC drivers implement statement pooling as follows: 1.
When using the Java socket multiplexer (identified by –Dweblogic.nativeIOEnabled = false), the default queue also determines the number of threads that can do socket reading work for a WebLogic Server instance, which is specified as a percentage of the total number of threads configured in the default execute queue.
pool can be an instance of class java.sql.Driver (for JDBC/MX, this is the com.tandem.sqlmx.SQLMXDriver) or an instance of javax.sql.XADataSource (for example, com.hp.nsk.xares.WLSTxSQLMXDataSource). The former is hereafter referred to as the non-XA driver and the latter as the XA driver.
3.3 Configuring a Connection Pool with the XA Driver The alternative to creating a connection pool with the non-XA JDBC/MX Driver name is to create it with the XAaware driver. The Connection pool can then be used to create transactional Datasources that can be used in global transactions involving multiple resources such as JMS. The XADataSource name for SQL/MX (instance of javax.sql.XADataSource) is com.hp.nsk.xares.WLSTxSQLMXDataSource.
WebLogic Server will involve the transactional Datasources in its distributed transactions9. To do this, the underlying JDBC resource should be XA aware. When a transactional Datasource is configured based on a non-XA aware driver, WebLogic Server will provide the XA emulation. It is not generally advisable to use this because: • Only one non-XA aware Datasource (with XA emulation from WebLogic) can participate in a global transaction. • The XA-aware driver com.hp.nsk.xares.
The following is a simple matrix showing the various combinations of connection pooling: WebLogic Server Connection Pool and DataSource Types Connection Pooling Statement Pooling Usage Considerations Non-XA connection Pool with non-transaction Datasource Use WebLogic Server connection pooling. Use default JDBC connection pooling. Disable WebLogic Server Statement caching. Enable JDBC driver statement pooling. XA connection pool with transactional Datasource Use WebLogic Server connection pooling.
MaxCapacity="4" Name="sqlmxPool” StatementCacheSize="0" Properties="maxStatements=100" ShrinkPeriodMinutes="30" ShrinkingEnabled="false" SqlStmtMaxParamLength="10" SqlStmtParamLoggingEnabled="false" SqlStmtProfilingEnabled="false" SupportsLocalTransaction="true" Targets="joecluster" TestConnectionsOnRelease="false" TestConnectionsOnReserve="false" URL="jdbc:sqlmx:"/> Sample JDBC Connection Pool Element extracted from a configuration using the XA driver:
While it is not recommended, the number of native socket readers can also be throttled. Specify the system property –Dweblogic.PosixSocketReaders= where is the number of socket readers desired. The default is three (3), which is ideal for most configurations. While the Java multiplexer is not recommended in the 8.1 SP3 release (and will perform poorly), it can be used. To use the Java socket multiplexer, explicitly disable the native socket multiplexer (by setting the system property Dweblogic.
if (numReaders > numSockets) timeout = SocketReaderTimeoutMaxMillis else Timeout = numReaders * 60000 / numSockets if (timeout < SocketReaderTimeoutMinMillis) timeout = SockerReaderTimeoutMinMillis if (timeout > SocketReaderTimeoutMaxMillis) timeout = SockerReaderTimeoutMaxMillis SocketReaderTimeoutMinMillis and SocketReaderTimeoutMaxMillis are by default set to 100 and 500, respectively, but can be overridden in the Server element.
All WebLogic Server instances of one WebLogic Server cluster (and only those instances) should use the same key. It can be set to the WebLogic Server cluster name itself, but is subject to Guardian filename rules (8-character maximum length, with the first character an alphabetical character).
The size of the QIO segment is determined by the configured physical memory on the system. For a system configured with 4GB of physical memory, 512 MB of QIO segment is used. In addition, 512 MB of the process address space is reserved for QIO segment, if the process is also a QIO client. To overcome the problem of losing address space to QIO, the QIO segment can be configured to be moved to the KSEG212 region.
WebServer is a multi-threaded server but the Plug-in is a single-threaded server. In either case, the serverclasses are typically configured to have enough headroom to handle peak usage scenarios. Under peak usage, the number of instances (and hence the QIO resource consumption by the resources) can exhaust the QIO segment space and lead to application processing failures and potentially processor halts. 3.
Examples of well-known ports are the HTTP port (80), HTTPS port (443), TELNET (23), and SMTP (25). • Registered Ports are those from 1024 through 49151. Registered Ports are listed by the IANA and on most systems can be used by ordinary user processes or programs executed by ordinary users. Examples of registered ports are the TIP port (3160) and X windows system (6000-6063). • Dynamic and/or Private Ports are those from 49152 through 65535. These are also called the ephemeral ports.
3.17 Reducing the Minimum Listen Queue Size and Acknowledgement Delay Interval By default, the listen queue sizes for the TCP/IP V6 stack is set to128 and the acknowledgement delay interval is set to 20 milliseconds. Here is an extract from the SCF command output that shows this. The TCP6SAM process name is $ZZTCP by default. 1-> info mon $ZZTCP.#ZPTM0,detail TCPIPV6 Detailed Info MON \HOST.$ZZTCP.#ZPTM0 *TCP Send Space......... 61440D *TCP Receive Space...... 61440D *UDP Send Space.........
3.18 Logical Network Partitioning One important difference between the classic TCP/IP stack and the TCP/IP V6 stack is that in the TCP/IP V6 stack there is only one manager process ($ZZTCP, typically) with which all interfaces are associated. In classic TCP/IP, multiple TCP/IP processes can be configured each with its own set of interfaces.
While an administrative server can also be configured to host applications, it is recommended that the application server in a domain (which has other managed servers besides the administrative server) be used for administrative requirements only. During steady state, the involvement of the administrative server is less, but in a production application, the administrative server provides the monitoring of the WebLogic Server domain.
$SYSTEM.SYSTEM.ZSYSCFG KMS.SWAPFILE = 0 $SWAP01.SWAP1.CPU00 KMS.SWAPFILE = 1 $SWAP01.SWAP1.CPU01 KMS.SWAPFILE = 0 $SWAP01.SWAP2.CPU00 KMS.SWAPFILE = 1 $SWAP01.SWAP2.CPU01 KMS.SWAPFILE = 0 $SWAP01.SWAP3.CPU00 KMS.SWAPFILE = 1 $SWAP01.SWAP3.CPU01 KMS.SWAPFILE = 2 $SWAP23.SWAP1.CPU02 KMS.SWAPFILE = 3 $SWAP23.SWAP1.CPU03 KMS.SWAPFILE = 2 $SWAP23.SWAP2.CPU02 KMS.SWAPFILE = 3 $SWAP23.SWAP2.CPU03 KMS.SWAPFILE = 2 $SWAP23.SWAP3.CPU02 KMS.SWAPFILE = 3 $SWAP23.SWAP3.CPU03 KMS.SWAPFILE = 4 $SWAP45.SWAP1.CPU04 KMS.
low memory situations and force Garbage collection on a server. The following attributes of the server element (configured in the Servers->Configuration->Memory Tab in the WebLogic Server Console are used for controlling the thresholds. The attributes under this tab control how often WebLogic Server samples JVM memory and what is the threshold at which WebLogic Server will force a Garbage collection.
BEA describes WebLogic Server performance tuning in the WebLogic Service Performance Tuning page available at http://edocs.bea.com/wls/docs81/perform/index.html. HP recommends a default minimum and maximum of 256 MB for the Java heap. The maximum for the Java heap can be 256 MB or greater depending on need.
Instead, it only copies existing jars to the .wlnotdelete directory (and this can be limited by the procedure described above). Other files that are created are ejb cache files. It was seen that deployment from an extracted directory was almost 50 % faster. 6.2 JMS Considerations JMS lets you store persistent messages in either a disk-based file (called a JMS file store) or in a JDBC-accessible database (called a JMS JDBC store).
© 2005 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.
