WebLogic Server Performance and Tuning
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The following sections provide tips on how to get the best performance from JDBC applications:
A straightforward and easy way to boost performance of JDBC in WebLogic Server applications is to set the value of Initial Capacity
equal to the value for Maximum Capacity
when configuring connection pools in your data source.
Creating a database connection is a relatively expensive process in any environment. Typically, a connection pool starts with a small number of connections. As client demand for more connections grow, there may not be enough in the pool to satisfy the requests. WebLogic Server creates additional connections and adds them to the pool until the maximum pool size is reached.
One way to avoid connection creation delays for clients using the server is to initialize all connections at server startup, rather than on-demand as clients need them. Set the initial number of connections equal to the maximum number of connections in the Connection Pool tab of your data source configuration. See JDBC Data Source: Configuration: Connection Pool in the Administration Console Online Help. You will still need to determine the optimal value for the Maximum Capacity
as part of your pre-production performance testing.
Another simple way to boost JDBC application performance avoid wasting resources. Here are some situations where you can avoid wasting JDBC related resources:
When Test Connections on Reserve
is enabled, the server instance checks a database connection prior to returning the connection to a client. This helps reduce the risk of passing invalid connections to clients.
However, it is a fairly expensive operation. Typically, a server instance performs the test by executing a full-fledged SQL query with each connection prior to returning it. If the SQL query fails, the connection is destroyed and a new one is created in its place. A new and optional performance tunable has been provided in WLS 9.0 within this "test connection on reserve" feature. The new optional performance tunable in 9.0 allows WLS to skip this SQL-query test within a configured time window of a prior successful client use (default is 10 seconds). When a connection is returned to the pool by a client, the connection is timestamped by WLS. WLS will then skip the SQL-query test if this particular connection is returned to a client within the time window. Once the time window expires, WLS will execute the SQL-query test. This feature can provide significant performance boosts for busy systems using "test connection on reserve".
When you use a prepared statement or callable statement in an application or EJB, there is considerable processing overhead for the communication between the application server and the database server and on the database server itself. To minimize the processing costs, WebLogic Server can cache prepared and callable statements used in your applications. When an application or EJB calls any of the statements stored in the cache, WebLogic Server reuses the statement stored in the cache. Reusing prepared and callable statements reduces CPU usage on the database server, improving performance for the current statement and leaving CPU cycles for other tasks. For more details, see Increasing Performance with the Statement Cache in Configuring and Managing WebLogic JDBC.
Using the statement cache can dramatically increase performance, but you must consider its limitations before you decide to use it. For more details, see Usage Restrictions for the Statement Cache in Configuring and Managing WebLogic JDBC.
Most performance gains or losses in a database application is not determined by the application language, but by how the application is designed. The number and location of clients, size and structure of DBMS tables and indexes, and the number and types of queries all affect application performance. For Detailed information on how to design a database application, see Designing Your Application for Best Performance in Programming WebLogic JDBC.
![]() ![]() |
![]() |
![]() |