Key aspects of portal performance are managed at the domain level. These include:
Optimally, when you deploy, you need to create a new domain that is configured for your production environment. However, if you have deployed a development domain and want to use it for production, you must change your domain environment settings to optimize performance.
Note: | It is not recommended to use a development domain for production, see Creating WebLogic Domains Using the Configuration Wizard for more information. |
The domain settings are managed by the setDomainEnv.cmd
(or setDomainEnv.sh
) script which is found in your domain directory. By default, the script is found in: <BEA_HOME>
/user_projects/
domain_name
/bin/setDomainEnv.cmd/sh
.
To edit this file, open it in a text editor.
Table 2-1 lists the start script settings and their appropriate values for a production domain. Remember if you are using a domain that was created for production mode, you do not need to modify the configuration.
When deploying a domain, you should remove the debug.properties
file from the domain directory. Although this file is helpful during development, debugging should not be done in production environments.
WebLogic Server has several logging features available. When using the WebLogic logging infrastructure, make sure that the server logs at an appropriate level and to the correct location. For example, a production system logging at DEBUG or TRACE levels can produce gigabytes of log data fairly quickly when writing to a log file. A production system should have logging set to the INFO level or higher. This can be done from the command line, from MBeans, or from the console. See the WebLogic Server document Configuring Log Files and Filtering Log Messages for more detailed information on WebLogic Server logging.
Additionally, WebLogic server internally processes all log messages before writing these messages to the logging infrastructure. In a production system where the logging level has been set to INFO or NOTICE, having the server process all DEBUG messages, for example, can add significant overhead. It is a good idea to match the internal WebLogic Server log processing level to the logging framework level. Do this by specifying the -Dweblogic.log.LoggerSeverity
flag to the server at startup.