The <servlet-reload-check-secs> element defines whether a WebLogic Server will check to see if a servlet has been modified, and if it has been modified, reloads it.
The value -1 means never check the servlets. This is the default value in a production environment.
The value 0 means always check the servlets.
The value 1 means check the servlets every second. This is the default value in a development environment.
A value specified in the console will always take precedence over a manually specified value.
The <resource-reload-check-secs> element is used to perform metadata caching for cached resources that are found in the resource path in the Web application scope. This parameter identifies how often WebLogic Server checks whether a resource has been modified and if so , it reloads it.
The value -1 means metadata is cached but never checked against the disk for changes. In a production environment, this value is recommended for better performance.
The value 0 indicates not to do any metadata caching. Customers who keep changing their files must set this parameter to a value greater than or equal to 0.
The value 1 means reload every second. This is the default value in a development environment.
Values specified for this parameter using the Admin Console are given precedence.
To use native I / O while serving static files with weblogic.servlet.FileServlet, which is implicitly registered as the default servlet, set native-io-enabled to true. (The default value is false.) Native-io-enabled element applies only on Windows.
Sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling. Dependencies are also checked and recursively reloaded if changed.
The value -1 means never check the pages. This is the default value in a production environment.
The value 0 means always check the pages.
The value 1 means check the pages every second. This is the default value in a development environment.
In a production environment where changes to a JSP are rare, consider changing the value of pageCheckSeconds to 60 or greater, according to your tuning requirements.
Set Initial Capacity equal to the Maximum Capacity
Setting Statement cache (note that for each open statement, DBMS will maintain a cursor, this value is set through the General Assembly led to java.sql.SQLException: ORA-01000: maximum open cursors exceeded similar error. Of course, you know, statement The size of cache to cache for each connection is the statement number, for example, you set the connection pool size = 100, set the Statement Cache = 10, then the system to maintain the cursor to the maximum 100 * 10)
Enable Native IO (note, not java's NIO, using Java muxer approach to connectivity, the great impact a large concurrent systems, java need for each connection request from a thread to handle)
Modify the Accept Backlog, when the application server reject the connection when there
Start the weblogic startup script using productmode
To make use jrockit
After release from the 9, weblogic replaced with the work manager thread queue, by default, weblogic there is a default work manager, the average share method using the thread fair share
Usually you do not need to create a work manager, unless you have the following requirements:
Your application has priority
You need to meet the definition of response time SLA
Need to specify the minimum threads constraint to avoid server deadlock