Server Tuning
The core component of WebLogic server consists of a listening thread, a socket multiplexer, and an execution queue of executable threads. When a server receives a connection request from a listener thread, its connection control is handed over to the socket multiplexer waiting to receive the request. The socket multiplexer then reads the request to leave the socket and place the request along with the relevant security information or transaction processing environment into the appropriate execution queue (typically the default execution queue). When a request appears in the execution queue, an idle execution thread takes the request from the queue, returns the reply, and waits for the next request. Therefore, in order to improve the performance of WebLogic, we must start with adjusting the performance of core components.
1. Use local I/O libraries as much as possible WebLogic server has two socket multiplexer: Java version and local library. A small local library is more efficient and activates the Enable Native IO (default), at which time Unix uses cpus+1 threads by default and double CPU under window. If the system cannot load the local library, the java.lang.UnsatisfiedLinkException will be thrown, and only the Java socket multiplexer can be used to adjust the socket readers percentage, which defaults to 33%. This parameter can be set in the console Server tuning configuration configuration bar.
2. Adjust the default number of execution threads the ideal default number of execution threads is determined by many factors, such as machine CPU performance, bus architecture, I/O, process scheduling mechanism of the operating system, and the thread scheduling mechanism of the JVM. The default thread in the WebLogic production environment is 25, and as the number of CPUs increases, WebLogic can increase the number of threads almost linearly. The more threads, the more time you spend on a thread switch, the smaller the number of threads, and the more CPU may not be fully exploited. To get an ideal number of threads, it needs to be tested over and over again. In a test, you can adjust 25*cpus as a benchmark. You can increase the size of the number of threads (increments per five) appropriately when there are fewer idle threads and lower CPU utilization. For PC Server and Window 2000, it is best to have less than 50 threads per CPU, preferably around 90% CPU utilization. Because the current WebLogic execution thread does not have the ability to shrink the number of threads, you should set the parameter threads increase to 0 and should not change the size of the priority
3. Adjust the connection parameters WebLogic Server uses the Accept backlog parameter to specify the queue size that the server requests to the operating system, and the default value is 50. When the system overloads the load, this value may be too small, the log report connection refused, resulting in a valid connection request rejected, you can increase accept Backlog 25% until the connection rejection error disappears. For portal type applications, default values are often not sufficient. The login timeout and SSL login timeout parameters indicate the timeout for a normal connection and an SSL connection, and you can try increasing the value if the client connection is interrupted by the server or if the SSL capacity is large. These parameters can be found in the console Server tuning configration configuration bar.
4. Creating new execution queues creates new execution queues to help address core business priorities, avoid cross blocking, deadlock, and long-running business issues. You typically set your execution queue to a different priority than the default execution queue, where the priority should not be set to 9 or 10. Defining a new execution queue is easy, using the Configure a new Excute queue link in the View excute queue option to customize the new execution queue. After a new execution queue is created, the user needs to configure an allocation policy for the Java EE component of the application so that it can find a new queue. For example: to bundle a servlet or JSP into a specific execution queue, you must replace the Web.xml file entry and set the Wl-dispatch-policy initialization parameter to its own execution queue name.
<servlet>
<servlet-name>servletname</servlet-name>
<jsp-file>/directoryname/deployment.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>NewExecuteQueueName</param-value>
</init-param>
</servlet>
We can set up our own execution queues for a JSP or servlet, or even a Web application. You can also set your own execution queue for the EJB. It is recommended that you use your own execution queue for an MDB that has a long execution time.
JDBC Tuning
Adjust Connection pool configuration
The tuning of the JDBC Connection pool is subject to the set of WebLogic server threads and the number of database processes, and the size of the cursor. Usually we use a connection in a thread, so the number of connections is not the better, in order to avoid resource consumption on both sides, it is recommended that the maximum number of connection pooling is equal to or slightly less than the thread count. Also, to reduce the cost of creating a new connection, set the minimum and maximum values to be consistent.
Adding statement cache size is useful for applications that use PreparedStatement objects heavily, WebLogic can cache these objects for each connection, which defaults to 10. If the database cursor size is guaranteed to be sufficient, the statement Cache size can be improved according to the need. For example, when you set the number of connections to 25,cache size 10 o'clock, the database may need to open 25*10=250 cursors. Unfortunately, when you encounter an application error related to PreparedStatement cache, you need to set the cache size to 0. Although JDBC Connection Pool provides many advanced parameters, it is useful in development mode, but most of them do not need to be adjusted in the production environment. It is recommended that you do not set the test table at the same time, test Reserved connections and test released connections do not need to hook up. Of course, if your database is unstable and intermittent, you may need to open the above parameters. Finally, the choice of driver type, Oracle as an example, Oracle to provide thin drive and OCI drive, in terms of performance, OCI drive is stronger than the thin driver, especially the large amount of data operations. But in the simple database operation, the performance difference is not big, along with the thin drive unceasing improvement, this weakness will be compensated. The thin-driven transplant is significantly stronger than the OCI drive. Therefore, it is recommended that the thin drive be used under normal circumstances. And the latest drive because the WebLogic Server/bin directory may not be up to date, please refer to Oracle Web site: http://www.oracle.com/technology/software/tech/java/sqlj_ Jdbc/htdocs/jdbc9201.html.
Web Tuning
Adjust the Web application descriptor
The
Web application is simpler to tune than code, just for some Web application descriptors. First, close session monitoringenabled, only in cluster environment set session replication (priority to use memory replication), in ensuring the application of the normal operation of the case, set a shorter session timeout. While the production environment eliminates the need to check the JSP and Servlet:jsppage check secs and the servlet Reload check secs are set to-1, turning off jspkeepgenerated and Jspverbose is also useful for performance. In addition, you can precompile JSP, there are two ways: to activate the precompile option, use WEBLOGIC.APPC to compile beforehand, recommend the latter
JMS Tuning
1. Increase-dweblogic.jmsthreadpoolsize=n (at least 5) to increase the number of threads handling JMS, and add-xxenablefatspin on JRockit to reduce the lock conflict;
2. Adopt a file Storage policy, set the synchronization write policy to Direct-write, and enable disk write caching on the Windows platform;
3. When using distributed destinations, activate connection Factory loadbalancing enabled, Server Affinity enabled;
4. To reduce unnecessary JMS request routing on the server, if there are transactions between multiple destinations, deploy on the same JMS server, deploy the connection factory to the WebLogic instance on which the JMS server is located, and in a clustered environment, it is best to deploy the connection factory to all servers in the cluster. Each JMS server and destination member in the cluster uses similar settings as much as possible;
5. Enable message paging storage to free memory, set up for JMS servers and destinations, activate messagespaging enabled and bytespaging enabled, and use quotas to prevent the server from exhausting all available memory space for receiving messages;
6. It is important for producers outside the Weblogicserver process to use flow control and to increase the send Timeout;
7. Jmsserver Expiration Scan interval set a large value, can prevent the active scan expired messages;
8. Use FIFO or LIFO method to process destination message;
9. mdb Max-beans-in-free-pool should not be greater than the maximum number of MDB threads (the default number of threads/2+1).
Oracle Performance Optimization
The
oracle9i performance optimization, in addition to tuning kernal, is primarily an adjustment to the Oracle boot file, which adjusts the parameters of the SGA. Note that different operating systems have different bits of the machine the best parameters are not the same, here are mainly Windows and UNIX, 32-bit and 64-bit points. The
first requires a large number of processes and cursors, the general default value for the actual application is relatively small, for example, the number of processes can be tuned to 300, the number of cursors can be tuned to 500.
Second, look at an empirical formula: the OS uses memory + SGA + session* (sort_area_size +hash_area_size +2m) <0.7ram, which is generally considered to be more reasonable at this time. Here the sort_area_size is 64k, Hash_area_size is 128k (when the number of sorting needs to increase sort_area_size, according to the adjusted value), the session represents the maximum number of concurrent processes, assuming 100. If 1G memory machine, OS occupancy 200M,PGA occupied 200M, then the SGA can be set to 400-500m, if 2G memory can 1G to sga,8g can be 5G to the SGA. However, for 32-bit databases, you can usually use up to 1.7G of memory.
Then, the basic principle of setting parameters within the SGA is that data buffer can usually be as large as possible, shared_pool_size moderately, log_buffer usually as large as hundreds of K to 1M. Specific: Data buffer 1G memory can be set 500M,2G to 1.2g,8g can be set to 5G. Shared_pool_size is not easy too large, usually should be controlled in 200m--300m, if the use of a large number of stored procedures, can be based on the value of the SGA increase to 500M, if the increase in the hit rate is not improved, then increase is unhelpful. Specific: 1G memory can be set 100M,2G to 150m,8g can be set to 300M. If you do not use Java,java_pool_size 10-20m. Large_pool_size If you do not set MTS, in 20m-30m, if you set MTS, you can consider the session * (Sort_area_size + 2M).
Finally, the settings for memory can be considered for fine-tuning based on view information such as statspack information and V$system_event,v$sysstat,v$sesstat,v$latch.
For Oracle to run efficiently, in addition to the memory factors mentioned above, there is a need for good database design: the rational planning and establishment of tables, views, indexes, and logs. I/O performance is also an important factor and should minimize paging and page allocations. In addition, the efficiency of the inspection points is improved.
Operating System Tuning
operating system affects the performance of the application of the main factors are: hardware configuration (CPU, memory, hard disk, etc.), core parameters, TCP/IP parameters and patches of the situation. The optimization of the operating system here, in addition to updating the latest patches to keep the application running, is to adjust the TCP/IP parameters, file descriptors, and other special parameter adjustments for individual operating systems .
HP-UX
For HP-UX, you first need to install Java Patch:
Http://www.hp.com/products1/unix/java/patches/index.html, and then you need to confirm that the core parameters in the following document are met (you can modify the core parameters using the SAM command): http:// e-docs.bea.com/platform/suppconfigs/configs81/hpux11_risc/81sp3.html#80105.
Adjust TCP parameters: Ndd-set/dev/tcp Tcp_conn_req_max 1024, adjusts the maximum allowable length of the listening queue to 1024. Sometimes the operating system restricts the maximum amount of memory used by the process to the size of the memory you want to configure, and you need to adjust the value.
Readers can learn more about HP-UX tuning suggestions from http://docs.hp.com/hpux/onlinedocs/TKP-90203/TKP-90203.html
Solaris
Adjust TCP parameters, wait interval tcp-time-wait-interval recommended set to 60000ms:/usr/sbin/ndd? set/dev/tcptcp_time_wait_interval 60000;
Other parameters are adjusted as follows:
Tcp_xmit_hiwat/tcp_recv_hiwat 131072
Tcp_conn_req_max_q/tcp_conn_req_max_q0 16384
Adjusts the number of file descriptors opened by a process: soft limits and hard limits, and the size of the hash table, modifying the/etc/system file:
Set tcp:tcp_conn_hash_size=32768
Set rlim_fd_cur=8192
Set rlim_fd_max=8192
For more information on the adjustment, please refer to http://docs.sun.com/db/doc/806-7009 (SOLARIS9).
Aix
AIX adjusts the TCP parameters with the No command, waits the interval tcp_timewait:no-o tcp_timewait=4, sets the tcp.timewait parameter to 4 15-second intervals, or 1 minutes. Running the no-a command displays all the current property values for the network. Because the default cache size for Udp_sendspace is 8k, to reduce I/O exceptions, you need to adjust to 32k:
No-o udp_sendspace=32768. In addition, when the weblogichttp request is busy, you can adjust the maximum length somaxconn to 8192 (the default value is 1024) for the listening queue.
More information: http://publib16.boulder.ibmo.com/pseries/en-us/aixbman/prftungd/prftungd.htm.
Linux
Adjust the Linux system using the SYSCTL command to modify the TCP parameter wait interval: sysctl-wip_ct_tcp_timeout_time_wait=60; Adjust the maximum number of open files: In the/etc/sysctl.conf file, add: fs.file-max=65535, then run sysctl-p; The maximum number of open file descriptors is 8192: in/etc/security/limits.conf file, add: WebLogic hard Nofile 8192 ( For WebLogic users only), and then run the ulimit-n8192 activation setting in the WebLogic startup file.
For more information, please refer to: http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html.
Windows
The adjustment of the Windows system is done by modifying the registry Hkey-local-machinesystemcurrentcontrolsetservices folder. You can adjust the value of the wait interval time tcptimedwaitdelay parameter in the Tcpipparameters subfolder. The default value for the maximum length of a listening queue is 15, in order to modify it, you can create a DWORD entry Listenbacklog in the Inetinfoparameters subdirectory.
In addition, Windows2000 service packs (requiring SP3 above) also affect system Stability: Http://e-docs.bea.com/platform/suppconfigs/configs81/win2ksvr_as_ Data_pentium/81sp3.html.
Add a new value under Registry hkey_local_machine\system\currentcontrolset\services\tcpip\parameters:
MaxUserPort, (DWORD value) Decimal, 65534
TcpTimedWaitDelay, (DWORD value) Decimal, 30
Description: use both parameters, and the Windows Server must be set up when the cluster is clustered.
· MaxUserPort: Determines the maximum port number that TCP/IP can specify when an application requests an available user port from the system. Default value: None. Recommended value: Decimal 65534.
· TcpTimedWaitDelay: Reducing this value allows TCP/IP to release closed connections more quickly and to provide additional resources for new connections. Adjust this parameter if you are running an application that needs to quickly release and create a new connection, and because there are many connections in time_wait that result in low throughput. Default value: 240, which sets the wait time to 240 seconds (4 minutes). Recommended value: Set to 30 seconds. Stop and restart the system.
performance monitoring and performance analysis
Performance bottlenecks
Introduces the practical analysis of Java EE Application performance of the commonly used commands and tools. For the realization of a high-performance Java EE application, master the theory of the optimization of Java EE is not enough. Mastering performance monitoring and discovering bottleneck and problem diagnosis is the key to ensure the continuous and efficient operation of Java EE system.
A bottleneck is a resource in the system that limits all throughput operations and severely affects the reaction time. Finding and correcting bottlenecks within a distributed system is very difficult and requires experienced teams to solve them. Bottlenecks can occur on Web servers, in program code, on application servers, databases, operating systems or networks, and hardware. Experience shows that bottlenecks can easily occur in database connections and queues, in the application server's program code, on application servers and Web server hardware, and in network and TCP configurations. In practice, these links can be monitored in an effort.
Operating system Monitoring
Performance monitoring at the operating system level is mainly to monitor and analyze the usage of memory, CPU, I/O and swap areas. Windows platforms can be viewed through Task Manager and Perfmon tools. If a UNIX system can use the Stat Series command (Vmstat,mpstat, iostat) to monitor the immediate changes in memory, CPU, and I/O, use the swap command to see the swap area. If the operating system installs top, TOPAS, glance, and so on, then using top, TOPAS, glance will make it easier to see the immediate changes in the operating system's memory, CPU, and I/O resources used by the WebLogic process.
While the performance of the network can be monitored by ping and netstat commands, several key network statistics, such as packet resend, duplicate packet and packet interception, are lost.
Description: The Unix command mentioned in this article is not applicable to all operating systems and is for informational purposes only.
Database monitoring
Tools such as spotlight can visually monitor the Oracle database for CPU, memory, I/O, data Buffer size, Shared Pool size, Redo Buffer, and automatically display the abnormal parameters in red.
Console monitoring
In addition to managing configuration functions, Weblogicconsole provides a wealth of monitoring capabilities. With the WebLogic Console, we can view the operation of the server.
Practical Tool Analysis
WebLogic Besides providing console for application monitoring, users can also write JMX programs or monitor them through SNMP protocols. The Quest Spotlight for WebLogic server provides similar monitoring capabilities like the WebLogic console and is red for exceptional conditions.
Here we have to mention the tools that are often used to analyze performance bottlenecks in combat Threaddump, and the unified command is to use WebLogic. Admin command Thread_dump. On Windows, you can also use <Ctrl>+<Break> to create thread dumps that are needed to diagnose problems, and use the kill-3 <wlspid> command on UNIX. We can see how the WebLogic background thread is running, and it usually needs to be performed several times every 10 seconds to help diagnose the problem. For more information, you can refer to the BEA combat highlights.
Application Profiling
Application Analysis In addition to the programmer's rich experience and keen insight to manually check the code, the use of factory tools is also a good time saver choice. Currently there are Borland Optimizeitenterprise Suite and Questjprobe, Jprofile can be used to analyze performance bottlenecks, garbage collection, memory leaks, thread deadlocks and code coverage. Hpjmeter is a free tool that also has the same performance analysis capabilities as above.