2 Top Performance Areas

By identifying top performance areas, you can tune Oracle Fusion Middleware for optimal performance.

• Identifying Top Performance Areas
  One of the most challenging aspects of performance tuning is knowing where to begin. Therefore, it is important to identify the top performance areas for Oracle Fusion Middleware.
• Securing Sufficient Hardware Resources
  Manage the performance of Oracle Fusion Middleware applications to ensure tthere is sufficient CPU, memory, and network resources to support the user and application requirements for installation.
• Tuning the Operating System
  Each operating system has native tools and utilities that can be useful for monitoring and tuning purposes.
• Tuning Java Virtual Machines (JVMs)
  How you tune your Java virtual machine (JVM) greatly affects the performance of Oracle Fusion Middleware and your applications.
• Tuning the WebLogic Server
  Tune the WebLogic Server to match your application needs.
• Tuning Database Parameters
  To achieve optimal performance for applications that use the Oracle database, the database tables you access must be designed with performance in mind. Monitoring and tuning the database ensures that you get the best performance from your applications.
• Reusing Database Connections
  It is important to tune the connection pool attributes in the JDBC data sources in your WebLogic Server domain correctly to improve application and system performance.
• Enabling Data Source Statement Caching
  Statement caching improves performance by caching executable statements that are used repeatedly.
• Controlling Concurrency
  Limiting concurrency at multiple layers of the system to match specific usage needs can greatly improve performance.
• Setting Logging Levels
  The amount of information that is logged can have a significant impact on the performance.

Identifying Top Performance Areas

One of the most challenging aspects of performance tuning is knowing where to begin. Therefore, it is important to identify the top performance areas for Oracle Fusion Middleware.

Table 2-1 provides a list of common performance considerations for Oracle Fusion Middleware. While the list is a useful tool in starting your performance tuning, it is not meant to be a comprehensive list of areas to tune. You must monitor and track specific performance issues within your application to understand where tuning can improve performance. See Monitoring.

Table 2-1 Top Performance Areas for Oracle Fusion Middleware

Performance Area	Description and Reference
Hardware Resources	Ensure that your hardware resources meet or exceed the resource requirements to maximize performance. See Securing Sufficient Hardware Resources for information on how to determine if your hardware resources are sufficient.
Operating System	Each operating system has native tools and utilities that can be useful for monitoring purposes. See Tuning the Operating System.
Java Virtual Machines (JVMs)	Follow the best practices and practical tips to tune the JVM. It also helps improve the performance of a Java EE application, including heap size and JVM garbage collection options. See Tuning Java Virtual Machines (JVMs).
Database	For applications that access a database, ensure that your database is properly configured to support requirements of the application. See Tuning Database Parameters.
WebLogic Server	If your Oracle Fusion Middleware applications are using WebLogic Server, see Tuning the WebLogic Server.
Database Connections	Pooling the connections so they are reused is an important tuning consideration. See Reusing Database Connections.
Data Source Statement Caching	For applications that use a database, you can lower the performance impact of repeated statement parsing and creation by configuring statement caching properly. See Enabling Data Source Statement Caching.
Oracle HTTP Server	Tune the Oracle HTTP Server directives to set the level of concurrency by specifying the number of HTTP connections. See Controlling Concurrency.
Concurrency	Control concurrency with Oracle Fusion Middleware components. See Controlling Concurrency.
Logging Levels	Logging levels are thresholds that a system administrator sets to control how much information is logged. Set the logging levels appropriately as it impacts the performance by the amount of information that applications log. See Setting Logging Levels.

Securing Sufficient Hardware Resources

Manage the performance of Oracle Fusion Middleware applications to ensure tthere is sufficient CPU, memory, and network resources to support the user and application requirements for installation.

No matter how well you tune your applications, if the appropriate hardware resources are not used, your applications cannot reach their optimal performance levels. Oracle Fusion Middleware has minimum hardware requirements for its applications and database tier. For details on Oracle Fusion Middleware supported configurations, see Verifying Certification, System Requirements, and Interoperability in Planning an Installation of Oracle Fusion Middleware.

Sufficient hardware resources must meet or exceed the acceptable response times and throughputs for applications without becoming saturated. To verify that you have sufficient hardware resources, you should monitor resource utilization over an extended period to determine if (or when) you have occasional peaks of usage or whether a resource is consistently saturated. For details on monitoring, see Monitoring.

Tip:

Your target CPU usage should never reach 100% utilization. Target the CPU utilization based on your application needs, including CPU cycles for peak usage.

If your CPU utilization is optimized at 100% during normal load hours, you have no capacity to handle a peak load. In applications that are latency sensitive, maintaining a fast response time is important. High CPU usage (approaching 100% utilization) can increase response time while throughput stays constant or even decreases. For such applications, a 70% - 80% CPU utilization is recommended. A good target for non-latency sensitive applications is about 90%.

If any of the hardware resources are saturated (consistently at or near 100% utilization), one or more of the following conditions might exist:

• The hardware resources are insufficient to run the application.

• The system is not properly configured.

• The application or database must be tuned.

For a consistently saturated resource, the solutions are to reduce load or increase resources. For peak traffic periods when the increased response time is not acceptable, consider increasing resources or determine if any traffic can be rescheduled. To reduce the peak load, you must schedule the batch or background operations during slower periods.

Oracle Fusion Middleware provides a variety of mechanisms to help you control resource concurrency. This can limit the impact of bursts of traffic. However, for a consistently saturated system, this mechanism is a temporary solution. See Controlling Concurrency.

Tuning the Operating System

Each operating system has native tools and utilities that can be useful for monitoring and tuning purposes.

Native operating system commands enable you to monitor CPU utilization, paging activity, swapping, and other system activity information.

For operating system commands and guidelines on performance tuning of the network or operating system, refer to the documentation provided by the operating system vendor.

Tuning Java Virtual Machines (JVMs)

How you tune your Java virtual machine (JVM) greatly affects the performance of Oracle Fusion Middleware and your applications.

For more information on tuning your JVM, see Tuning Java Virtual Machines (JVM) in Tuning Performance of Oracle WebLogic Server.

Tuning the WebLogic Server

Tune the WebLogic Server to match your application needs.

If your Oracle Fusion Middleware applications use the WebLogic Server, see Tuning WebLogic Server in Tuning Performance of Oracle WebLogic Server.

Tuning Database Parameters

To achieve optimal performance for applications that use the Oracle database, the database tables you access must be designed with performance in mind. Monitoring and tuning the database ensures that you get the best performance from your applications.

Note:

The information in these topics is a subset of database tuning information for Fusion Middleware. Make sure that you have also reviewed the Database Performance Tuning Guide.

Always review the tuning guidelines in your database-specific vendor documentation.

• Tuning Database Parameters
  
• Tuning Database Files
  
• Tuning Automatic Segment-Space Management (ASSM)
  

Tuning Database Parameters

The following tables provide common init.ora parameters and their descriptions. Follow these guidelines to set the database parameters. Ultimately, however, the database administrator must monitor the database health and tune parameters based on the need.

The database that is used for SOA is configured with the suggested values. Tuning the database involves adjusting the sizing parameters based on the available resource and load on the database.

The sga_target, pga_aggregate_target, and processes parameters from Table 2-2 are examples of such parameters that must be tuned based on the System Global Area (SGA) and Parent Global Area (PGA) advisories and looking into the number of open processes during peak load.

Table 2-2 Important Oracle 12c Database Tuning Parameters

Parameter	Description	Tuning Recommendation
audit_trail Default: DB	Enables or disables database auditing.	Set to NONE if there is NO policy to audit database activity. Enabling auditing can impact performance.
plsql_code_type Default: INTERPRETED	Compilation mode for PL/SQL library units. Possible modes are as follows: INTERPRETED: PL/SQL library units are compiled to PL/SQL byte code format and executed by the PL/SQL interpreter engine. NATIVE: PL/SQL library units are compiled to native (machine) code. Such modules are executed natively without incurring any interpreter impacts.	Set to NATIVE.
nls_sort Default: Derived from NLS_LANGUAGE	Collating sequence for ORDER BY queries. If the value is a named linguistic sort, the collating sequence is based on the order of the defined linguistic sort. Most languages supported by the NLS_LANGUAGE parameter also support a linguistic sort with the same name. If the value is set to BINARY, then the collating sequence is based on the numeric value of characters. This requires fewer system resources.	Set to BINARY.
open_cursors Default: 50	Maximum number of open cursors that a session can have at once. Open cursors are handles to private SQL areas. The value of OPEN_CURSORS must be high enough to prevent your application from running out of open cursors.	Increase to 500.
session_cached_cursors Default: 50	Number of session cursors to cache. Repeated parse calls of the same SQL statement cause the session cursor for that statement to be moved into the session cursor cache. Subsequent parse calls locate the cursor in the cache. However, they do not reopen the cursor. Oracle uses a least recently used algorithm to remove entries in the session cursor cache to make room for new entries when needed. This parameter also constrains the size of the PL/SQL cursor cache, which PL/SQL uses to avoid having to reparse as statements are reexecuted.	Increase to 500.
_b_tree_bitmap_plans Default: TRUE	Enables or disables the use of bitmap access paths for b-tree indexes.	Set to FALSE.
processes Default: 100	Maximum number of operating system processes that can be connected to the Oracle database concurrently. The value of this parameter must account for Oracle the background processes. The SESSIONS parameter is deduced from this value.	For most systems, increasing to 1500 must suffice. For a large-scale system, such as databases with a large number of users, the recommended value is 5000.
Memory_target	Oracle system-wide usable memory. The database tunes memory to the MEMORY_TARGET value, reducing or enlarging the SGA and PGA as needed.	Consider setting to NONE. Then set the SGA and PGA targets separately as setting MEMORY_TARGET does not allocate sufficient memory to SGA and PGA as needed.
sga_target Default: 0	A non-zero value enables Automatic Shared Memory Management. This can simplify configuration and improve performance.	For small systems, use a minimum of 2 GB. For large systems, set it to 18 GB.
pga_aggregate_target Default: 0	Target aggregate PGA memory available to all server processes attached to the instance.	For small systems, use a minimum of 1 GB. For large systems, set it to 8 GB.
Disk_asynch_io Default: TRUE	Controls whether I/O to data files, control files, and log files is asynchronous. It decides what parallel server processes can overlap I/O requests with CPU processing during table scans.	Set to FALSE only if your platform does not support asynchronous I/O.
Filesystemio_options Default: None	I/O operations for file system files.	Set to SETALL.
Secure_Files Default: PERMITTED	How to store LOB objects from tables.	Set to ALWAYS.
parallel_max_servers Default: PARALLEL_THREADS_PER_CPU*CPU_COUNT*concurrent_parallel_users*5	Maximum number of parallel execution processes and parallel recovery processes for an instance. As the demand increases, the Oracle database increases the number of processes from the number created at instance startup to this value.	Set to 12.
job_queue_processes Default: 1000	Maximum number of job slaves per instance that can be created for the execution of DBMS_JOB jobs and Oracle Scheduler (DBMS_SCHEDULER) jobs.	Set to 12.
shared_servers Default: 0 (or) 1	Number of server processes that you want to create when an instance is started.	Set to 0.

The table below describes the important inti.ora Database Tuning Parameters.

Table 2-3 Important inti.ora Oracle 12c Database Tuning Parameters

Database Parameter	Description
AUDIT_TRAIL	If there is no policy to audit database activity, consider setting this parameter to NONE. Enabling auditing can impact performance.
MEMORY_MAX_TARGET	Maximum value to which a database administrator can set the MEMORY_TARGET initialization parameter.
MEMORY_TARGET	Consider setting to NONE. Set SGA and PGA separately as setting the MEMORY_TARGET does not allocate sufficient memory to SGA and PGA as needed.
PGA_AGGREGATE_TARGET	Consider using a value of 1G for PGA initially and monitor the production database daily and adjust SGA and PGA accordingly. If the database server has more memory, consider setting the PGA_AGGREGATE_TARGET to a value higher than 1G, based on usage needs.
SGA_MAX_SIZE	Consider setting the MEMORY_TARGET instead of setting SGA and the PGA separately.
SGA_TARGET	Consider using a value of 2G initially and then monitor the production database daily and adjust SGA and PGA accordingly. If the database server has more memory, consider setting the SGA_TARGET to a value higher than 2G, based on usage needs.

In addition, set a minimum value for SHARED_POOL_SIZE and DB_CACHE_SIZE to minimize frequent resizing.

Tuning Database Files

In addition to tuning the database parameters, the database administrator must configure the REDO logs, UNDO table space, and TEMP table spaces to meet the demands of the database workload. The recommendations here are intended to provide initial guidance in these areas.

The location of the database files must be optimized for I/O performance and growth. Segment Advisor must be leveraged to optimize the use of segment space and ensure that performance degradation does not occur. The advisor can provide historical growth trends of segments, which can be used to proactively plan for growth. See Using the Segment Advisor in Oracle Database Administrator's Guide.

• Configuring REDO Logs
  
• Configuring UNDO Tablespace
  
• Configuring TEMP Tablespace
  
• Creating Additional Tablespaces
  Oracle recommends you to create additional tablespaces based on the requirement of the workload.

Configuring REDO Logs

Under demanding workloads, the size of the REDO log files can influence performance. Generally, larger REDO log files provide better performance. Undersized log files increase checkpoint activity and log file switches, which reduces performance. You can obtain sizing advice on the REDO Log Groups page of the Enterprise Manager.

Depending on your storage configuration and performance characteristics, redistribute the REDO logs to optimize I/O performance. The REDO log files must be placed on a disk separately from the data files to improve the I/O performance.

See Managing the REDO LogOracle Database Administrator's Guide

Configuring UNDO Tablespace

The suggested minimum size for the UNDO tablespace is 6 GB with auto-extend enabled. Oracle recommends that the default mode of automatic undo management is leveraged to maximize performance and efficiency.

The Oracle Enterprise Manager Automatic Undo Management Advisor must be leveraged to set configuration details for UNDO tablespace and retention settings. This advisor also provides access to the Undo Advisor that assesses the effect and provides advice of a new undo retention setting. For more information about using advisors, see The Undo Advisor PL/SQL Interface Oracle Database Administrator's Guide.

Configuring TEMP Tablespace

Oracle recommends the use of locally managed temporary tablespaces with the allocation type set to UNIFORM extents and the default size of 1 MB.

For tuning TEMP tablespaces for SOA, see Tuning Temporary Tablespaces for SOA.

Creating Additional Tablespaces

Oracle recommends you to create additional tablespaces based on the requirement of the workload.

You can increase the size of a tablespace by either of the following options:

• Changing Data File Size: You can alter the size of a data file. For example, you can increase the size of one or more data files when more space is needed in the database. For more information, see Changing Data File Size.
• Creating Data Files and Adding Data Files to a Tablespace: You can create data files and associate them with a tablespace using several different SQL statements. For more information, see Creating Data Files and Adding Data Files to a Tablespace.
• Enabling and Disabling Automatic Extension for a Data File: You can create data files or alter existing data files so that they automatically increase in size when more space is needed in the database. The file size increases in specified increments up to a specified maximum. For more information, see Enabling and Disabling Automatic Extension for a Data File.

Sample Script to create additional tablespaces:

CREATE TABLESPACE apps_tbs LOGGING 
     DATAFILE '/u01/app/oracle/oradata/mynewdb/apps01.dbf' 
     SIZE 500M REUSE AUTOEXTEND ON NEXT  1280K MAXSIZE UNLIMITED 
     EXTENT MANAGEMENT LOCAL;
-- create a tablespace for indexes, separate from user tablespace (optional)
CREATE TABLESPACE indx_tbs LOGGING 
     DATAFILE '/u01/app/oracle/oradata/mynewdb/indx01.dbf' 
     SIZE 100M REUSE AUTOEXTEND ON NEXT  1280K MAXSIZE UNLIMITED 
     EXTENT MANAGEMENT LOCAL;

Tuning Automatic Segment-Space Management (ASSM)

For permanent tablespaces, consider using automatic segment-space management. Such tablespaces, often referred to as bitmap tablespaces, are locally managed tablespaces with bitmap segment space management.

For backward compatibility, the default local tablespace segment-space management mode is MANUAL.

Oracle recommends to specify the allocation type to SYSTEM.

See Free Space Management and Specifying Segment Space Management in Locally Managed Tablespaces in Oracle Database Administrator's Guide.

Reusing Database Connections

It is important to tune the connection pool attributes in the JDBC data sources in your WebLogic Server domain correctly to improve application and system performance.

Creating a database connection is a resource-intensive process in any environment. Typically, a connection pool starts with a few connections. As client demands for more connections grow, there will not be enough in the pool to fulfill the requests. WebLogic Server creates more connections and adds them to the pool until the maximum pool size is reached.

One way to avoid connection creation delays is to initialize all connections at server startup, rather than on-demand. This is appropriate if your load is predictable and even. Set the initial number of connections equal to the maximum number of connections in the Connection Pool tab of your data source configuration. Determine the optimal value for the Maximum Capacity as part of your preproduction performance testing.

When the load is uneven, and has high number of connections at peak load than at typical load, set the initial number of connections equal to your typical load. In addition, set the maximum number of connections based on your supported peak load. With these configurations, WebLogic Server can free up some connections when they are not used.

See Tuning Data Source Connection Pool Options in Administering JDBC Data Sources for Oracle WebLogic Server.

Enabling Data Source Statement Caching

Statement caching improves performance by caching executable statements that are used repeatedly.

When a prepared statement or callable statement is used in an application or EJB, it impacts the performance associated with the processing of the communication between the application server and the database server. To minimize the processing impact, enable the data source to cache prepared and callable statements used in your applications. When an application or EJB calls any of the statements stored in the cache, the 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.

Consider the following data source configurations when performance is an issue:

• When configuring the data source, ensure that the connection pool has enough free connections.

• Statement caching can eliminate potential performance impacts caused by repeated cursor creation and repeated statement parsing and creation. Statement caching also reduces the performance impact of communication between the application server and the database server.

• Disable unnecessary connection testing and profiling.

Each connection in a data source has its own individual cache of prepared and callable statements used on the connection. However, you configure statement cache options as per the data source. That is, the statement cache for each connection in a data source uses the statement cache options specified for the data source. Each connection caches its own statements. Statement cache configuration options include:

• Statement Cache Type—The algorithm that determines which statements to store in the statement cache.

• Statement Cache Size—The number of statements to store in the cache for each connection. The default value is 10. Analyze your database statement parse metrics to size the statement cache sufficiently for the number of statements you have in your application.

You can use the Administration Console to set statement cache options for a data source.

For details on using statement caching, see Increasing Performance with the Statement Cache in Administering JDBC Data Sources for Oracle WebLogic Server.

Controlling Concurrency

Limiting concurrency at multiple layers of the system to match specific usage needs can greatly improve performance.

When system capacity is reached, and a web server or an application server continues to accept requests, application performance and stability can deteriorate. Within the Oracle Fusion Middleware, you can throttle the requests to avoid overloading the mid-tier or database tier systems and tune for best performance.

• Setting Server Connection Limits
  
• Configuring Connection Pools
  
• Tuning the WebLogic Server Thread Pool
  

Setting Server Connection Limits

Oracle HTTP Server uses directives in the httpd.conf file. This configuration file specifies the maximum number of HTTP requests that can be processed simultaneously, logging details, and certain limits and time outs.

For details on modifying the httpd.conf file, see Configuring Oracle HTTP Server in Administering Oracle HTTP Server.

Use the MaxRequestWorkers and ThreadsPerChild directives to limit incoming requests to WebLogic instances from the Oracle HTTP Server based on your expected client load and system resources. There are several Oracle HTTP Server tuning parameters related to connection limits that must be tuned based on the expected client load. See Tuning Oracle HTTP Server for details on setting server connection limits and a complete list of tunable parameters.

• Setting MaxRequestWorkers / ThreadsPerChild
  
• Setting KeepAlive
  
• Tuning HTTP Server Modules
  

Setting MaxRequestWorkers / ThreadsPerChild

Note:

The MaxRequestWorkers parameter is applicable only to UNIX platforms. The same is achieved through the ThreadsPerChild and ThreadLimit properties on Microsoft Windows (mpm_winnt).

The MaxRequestWorkers parameter specifies a limit on the total number of server threads running, that is, a limit on the number of clients who can simultaneously connect. If the number of client connections reaches this limit, then subsequent requests are queued in the TCP/IP system up to the limit specified (in the ListenBackLog directive).

You can configure the MaxRequestWorkers directive in the httpd.conf file up to a maximum of 8K (the default value is 150). If the system is not resource-saturated and the user population is more than 150 concurrent HTTP connections, improve your performance by increasing MaxRequestWorkers to increase server concurrency. Increase MaxRequestWorkers until your system becomes fully utilized (85% is a good threshold).

When system resources are saturated, increasing MaxRequestWorkers does not improve performance. In this case, the MaxRequestWorkers value could be reduced as a throttle on the number of concurrent requests on the server.

If the server handles persistent connections, then it requires sufficient concurrent httpd server processes to handle both active and idle connections. When you specify MaxRequestWorkers to act as a throttle for system concurrency, consider that persistent idle httpd connections also consume httpd processes. Specifically, the number of connections includes the currently active persistent and non-persistent connections and the idle persistent connections. When there are no httpd server threads available, connection requests are queued in the TCP/IP system until a thread becomes available, and eventually clients terminate connections.

You can define few server processes and the threads per process (ThreadsPerChild) to handle the incoming connections to Oracle HTTP Server. The ThreadsPerChild property specifies the upper limit on the number of threads that can be created under a server (child) process.

Note:

ThreadsPerChild, StartServers, and ServerLimit properties are inter-related with the MaxRequestWorkers setting. All these properties must be set appropriately to achieve the number of connections as specified by MaxRequestWorkers. See Table 6-1 for a description of all the HTTP configuration properties.

Setting KeepAlive

A persistent HTTP connection, KeepAlive, consumes an httpd child process, or thread during the connection, even if no requests are currently being processed for the connection.

If you have sufficient capacity, KeepAlive must be enabled; using persistent connections improves performance and prevents wasting CPU resources re-establishing HTTP connections. Normally, you do not have to change KeepAlive parameters.

Note:

The default maximum request for a persistent connection is 100, as specified with the MaxKeepAliveRequests directive in the httpd.conf file. By default, the server waits for 15 seconds between requests from a client before closing a connection, as specified with the KeepAliveTimeout directive in the httpd.conf file.

Tuning HTTP Server Modules

The Oracle HTTP Server (OHS) uses the mod_wl_ohs module to route requests to the underlying WebLogic Server or the WebLogic Server cluster. The configuration details for the mod_wl_ohs module are available in the mod_wl_ohs.conf file in the config directory.

See Understanding Oracle HTTP Server Modules in Administering Oracle HTTP Server.

Configuring Connection Pools

Connection pooling is configured and maintained per Java runtime. Connections are not shared across different runtimes. To use connection pooling, no configuration is required. Configuration is necessary only if pooling needs to be customized. For example; control the size of the pools and types of connections to be pooled.

You configure connection pooling by using several system properties at program startup time. These are system properties, not environment properties and they affect all connection pooling requests.

For applications that use a database, performance can improve when the connection pool that is associated with a data source limits the number of connections. Use the MaxCapacity attribute to limit the database requests from Oracle Application Server so that incoming requests do not saturate the database, or to limit the database requests. Thus, the database access does not overload the Oracle Application Server-tier resource.

The connection pool MaxCapacity attribute specifies the maximum number of connections that a connection pool allows. By default, the value of the MaxCapacity attribute is set to 15. For best performance, specify a value for the MaxCapacity attribute that matches the number appropriate to your database performance characteristics.

Limiting the total number of open database connections to a number your database can handle is an important tuning consideration. Configure the database to allow at least open connections as the total of the values specified for all the data sources MaxCapacity option, as specified in all the applications that access the database.

For connection pool options, see JDBC Data Source: Configuration: Connection Pool in the Oracle WebLogic Server Administration Console Online Help and Tuning Data Source Connection Pool Options in Administering JDBC Data Sources for Oracle WebLogic Server.

Tuning the WebLogic Server Thread Pool

By default, WebLogic Server uses a single thread pool. All types of work are executed in this thread pool. WebLogic Server uses work managers to prioritize work based on rules that you can define, and runtime metrics, including the actual time it takes to execute a request and the rate at which requests are entering and leaving the pool. There is a default work manager that manages the common thread pool.

The common thread pool changes its size automatically to maximize throughput. WebLogic Server monitors throughput over time and based on history, determines whether to adjust the thread count. For example, if historical throughput statistics indicate that a higher thread count increased throughput, WebLogic increases the thread count. Similarly, if statistics indicate that fewer threads did not reduce throughput, WebLogic decreases the thread count.

The WebLogic Server thread pool is sized automatically and hence in most situations you do not need to tune it. However, for special requirements, an administrator can configure custom work managers to manage the thread pool at a more granular level for sets of requests that have similar performance, availability, or reliability requirements. With custom work managers, you can define priorities and guidelines for how to assign pending work (including specifying a min threads or max threads constraint, or a constraint on the total number of requests that can be queued or executed before WebLogic Server begins rejecting requests).

Use the following guidelines to help you determine when to use work managers to customize thread management:

• The default fair share is not sufficient.

  This usually occurs in situations where one application is given a higher priority over another.

• A response time goal is required.

• A minimum thread constraint is specified to avoid server deadlock.

• You use MDBs in your application.

  To ensure MDBs use a well-defined share of server thread resources, and to tune MDB concurrency, most MDBs are modified to reference a custom work manager that has a max-threads-constraint. In general, a custom work manager is useful when you have multiple MDB deployments, or if you determine that a particular MDB needs more threads.

Note:

For details on how to use custom work managers to customize thread management, and when to use custom work managers, see the following:

• Tune Pool Sizes in Tuning Performance of Oracle WebLogic Server

• Thread Management in Tuning Performance of Oracle WebLogic Server

• MDB Thread Management in Tuning Performance of Oracle WebLogic Server

• Using Work Managers to Optimize Scheduled Work in Administering Server Environments for Oracle WebLogic Server

• Avoiding and Managing Overload in Administering Server Environments for Oracle WebLogic Server

Use Oracle WebLogic Administration Console to view general information about the status of the thread pool (such as active thread count, total thread count, and queue length.) You can also use the Console to view the scope of the application and the work manager metrics from the Workload tab on the Monitoring page. The metrics provided include the number of pending requests and number of completed requests.

See Servers: Monitoring: Threads and Deployments: Monitoring: Workload in the Oracle WebLogic Server Administration Console Online Help.

The work manager and thread pool metrics can also be viewed from the Oracle Fusion Middleware Control.

Setting Logging Levels

The amount of information that is logged can have a significant impact on the performance.

The amount of information that applications log depends on how the environment is configured and how the application code is instrumented. To maximize performance, it is recommended that the logging level is not set higher than the default INFO level logging. If the logging setting does not match the default level, reset the logging level to the default for best performance.

After you set the application and server logging levels, ensure that the debugging properties or other application level debugging flags are set correctly or disabled. To avoid performance impacts, do not set log levels to levels that produce more diagnostic messages, including the FINE or TRACE levels.

Each component has specific recommendations for logging levels.