Any product in the market has a good performance. Although it is necessary to have a lot of characteristics that are widely used in WebLogic Server, performance is absolutely indispensable. Good programming habits have played a lot of role in helping the application, but only they are still not enough. The application server must be able to be transplanted between a variety of hardware and operating systems, and a versatility must have a wide range of application types. That is why the application server provides a wealth of debug "button", by adjusting these "buttons", enabling the server more suitable for the running environment and the application.
This article discusses some debug parameters for WebLogic, but all adjustable properties are not listed. In addition, before using the recommended methods to the product environment, it is recommended that you test them in the test environment.
Performance monitoring and bottleneck finding
The first step in performance debugging is to isolate "dangerous areas". Performance bottlenecks can exist in any of the network, databases, clients, or application servers throughout the system. It is important to first determine which system component causing performance issues, and debug-offs the component may make the situation.
WebLogic Server provides system administrators to monitor system performance in both management console and command line tools. The server is called a collection of MBean, which is used to collect information such as thread consumption, resource surplus, cache usage. Console and command line managers can call this information from the server. The screen snapshot of Figure 1 shows the use and remaining conditions of the EJB container, which is one of the options for performance monitoring provided by the console.
The code analyzer is also another effective tool for applying code to detect itself bottleneck. There are a few good code analyzers, such as: Wily Introscope, Jprobe, Optimizelt.
EJB container
The most expensive operation in the EJB container is of course database calling? D load and storage entity bean. The container also provides a wide variety of parameters to reduce the number of access to the database. However, in any case, unless it is in special cases, at least one load operation and a storage operation are available at least in each transaction of each bean. These special circumstances are:
1. Bean is read-only. At this point, Beans only load it once in the first access, never need to store operations. Of course, beans will be loaded again if the settings of the parameter read-timeout-seconds are exceeded.
2. Bean has special or active concurrent policies, and the parameter DB-IS-Shared is set to false. This parameter is renamed in WebLogic Server 7.0 to cache-between-transactions. The parameter db-is-shared setting is equivalent to the parameter cache-between-transactions set to true.
3. Bean has not been modified in the transaction. At this time, the container optimizes the storage operation.
If it is not a case described above, each entity bean in the Code Path is at least loaded and stored at least once each transaction. Some features reduce database calls or reduce the overhead of database calls, such as cache technology, domain (field) packet, concurrent policies, and close-up associations, etc., some of which is the new increase of WebLogic Server 7.0 of.
Cache: The size of the entity bean cache space is defined by the parameter max-beans-in-cache in WebLogic-EJB-JAR.XML. The container is called from the database when the BEAN is loaded in the transaction, and the bean is also placed in the cache. If the cached space is too small, some beans are stuck in the database. Thus, if the first two special situations mentioned above are not considered, these beans must be loaded from the database when they are called. From the cache call bean also means that setentityContext () is not required. If the key (main) key of the bean is a combination domain or complicated, it can also save their time.
Domain packet: Domain packet is a domain that specifies the domain loaded from the database for the lookup method. If the entity bean is associated with a large BLOB domain (in a picture, an image), and rarely accessed, you can define a domain group that excludes this domain, which is associated with a lookup method. When you look, the blob domain will not be loaded. This feature is only available to the bean of EJB2.0. Concurrent Strategy: In WebLogic Server 7.0, the container provides four concurrent control mechanisms. They are exclusive, database, active and read-only. The concurrent strategy is closely related to the isolation level of the transaction. Concurrency control is not true to improve performance, which is the main purpose to ensure the consistency of the data represented by the entity bean, which is enforced by the bean deployer. In any case, certain control mechanisms make the container processing request than the other fast, but this fast is at the expense of the consistency of the data.
The most stringent concurrent strategy is exclusive, using special primary keys to the bean access is serialized, so it can only be accessed by a transaction each time. This provides good concurrent control in the container, but performance is limited. This method is useful when the transaction is allowed to cache, but it cannot be used in the cluster environment. At this time, the load operation is optimized, so it may result in loss of parallelism. The database-type concurrent policy is different from concurrent control of the database. The entity bean is not locked in the container, allowing multiple transactions to simultaneously operate the same entity bean, so performance can be improved. Of course, this may be high for isolation levels to ensure the consistency of data. Active concurrent policy is also different from concurrent control of the database. Different from the inspection of data consistency occurs when storing the set update operation rather than being launched during loading. If the conflict between the same bean access is not very intense, this policy is faster than the database, although two provide the same data consistency protection level. However, when there is a conflict, this policy requires the caller to re-initiate call. This feature is also only applicable to EJB 2.0.
The read-only strategy can only be used to read only beans. The bean is only loaded only when applying the first access or when the value specified by the parameter read-timeout-seconds is applied. BEAN never needs to be stored. When the basic data changes, beans will be notified via the Read-Mostly format, causing reloading.
Tight associated cache: If two entities beans, bean a and bean b are associated with CMR (container relationship management), two are accessed in the same transaction, and we are called tightly associated cache in the same transaction. This is a new feature of WebLogic Server 7.0, which is equally applicable to EJB2.0.
In addition to the above-mentioned access to the database to achieve a feature of the performance of the database, there are some parameters of the session bean and entity beans other than the container, and the parameters of the session bean and entity beans can help improve performance.
Buffer pools and caches are the main features provided by EJB containers to improve session beans and entity bean performance. However, these methods are not suitable for all types of Beans. They have a high demand for memory, although this is not a major problem. The buffer pool is suitable for stateless session beans, a message drive bean (MDB), and entity beans. Once the size of the buffer pool is set for SLSB and MDB, many instances of these beans will be created and placed in the buffer pool, and the setsessionContext () / setMessageDriveContext () method is called. The size of the buffer pool set for these beans does not have to exceed the number of executed threads (in fact, it is required to be small than this). If the method setsessionContext () To do any expensive operation, the JNDI query has been completed, and the instance method to use the buffer pool will speed up the speed. For the entity bean, the buffer pool is connected to the BEAN's anonymous instance after completing the setentityContext () method call (no primary key). These instances can be used by the query operation, the query method takes an instance from the buffer pool, specifies a primary key, and then loads the corresponding bean from the database. The cache is suitable for stateful session beans and entity beans. The entity bean is already discussed earlier. For SFSB, the cache can avoid operation of serializing the hard disk. Serialization to the hard drive is very expensive, absolutely should be avoided. The cache size for SFSB can be slightly larger than the number of concurrent clients connected to the server, because the container will try to stand in the database only when the cache is occupied by 85%. If the cache is larger than the actual desired, the container will not be standing by the cache spent time.
The EJB container provides two ways to perform call operations for bean-to-bean and web-tier-to-beans: pass value call and transmit address call. If the bean is in the same application, it is default, it is a way to transmit an address, which is faster than the pass value. The way to transmit the address is generally not prohibited unless there is sufficient reason to force this. Another way to force the delivery address is to use the local interface. Another feature is introduced in WebLogic Server 7.0 is an Activation using activation (Activation). Although this approach affects performance to some extent, the scalability is greatly improved due to low memory requirements. If the scalability is not worth paying, parameter NOOBJECTACTION can be transferred to EJBC to turn off activation.
JDBC
For database access, debugging JDBC is equally important to debug EJB containers. For example, setting the size of the connection pool? D? D connection pool should be enough to accommodate all threads to the connection requirements. If all the access to the database can be implemented in the default execution queue, the number of connections should be the number of threads in the execution queue, which is more than the thread that reads the socket (used in the default queue to read the procedure thread) There are fewer numbers. In order to avoid creating and deleting the connection during operation, the connection pool can be set to its maximum capacity at the beginning. If possible, ensure that the parameters TestConnectionsSonReServe is set to false (false, this is the default setting). If this parameter is set to true (TRUE), it is tested before the connection is assigned to the caller, which will additionally request repeated connection to the database.
Another important parameter is PreparedStateCachesize. Each connection sets a static cache for a macro spectrium, and the size is specified by the JDBC connection pool configuration. The cache is static, keeping in mind this very important. This means that if the size of the cache is n, only the first N statement placed in the cache is executed. Make sure that expensive SQL statements enjoy the cache method is to store these statements into the cache with a startup class. Although caching technology improves performance from a large extent, it cannot be blindly used. If the format of the database has changed, then the statement in the cache cannot be fade or replaced with newly without restarting the server. Of course, the statement in the cache will cause the cursor in the database to be retained. For WebLogic Server 7.0, since JDRiver performance has made it far from the Oracle-C-driver, especially for applications to complete a large number of SELECT operations. This can be proof from the two ECPERF results submitted by HP (http://ecperf.theserverside.com/ecperf/index.jsp?page=results/top_ten_price_persults/top_ten_price_performance).
JMS
The JMS subsystem provides a lot of debug parameters. The JMS message is processed by independent execution queues called JMSDispatcher. Therefore, the JMS subsystem will neither "nutrient" due to the application of the application in the default or other executive queue, which will not grab the resources of other applications. For JMS, most debug parameters are compromised in the quality of services. For example, using the File-Persistent Destnation to prohibit synchronous write operations (by setting feature: -dweblogic.jmsfilestore.synchronouswritesenabled = false) will cause dramatic improvement, but at the same time, there will be lost messages or repeat. Receive the risk of the message. Similarly, using multi-point transmission sent messages will increase performance, and there will be dangerous to lose halfway.
The message confirmation interval should not be set too much? D? D Send a confirmation ratio, the larger the speed of the processing message, the slower the speed. At the same time, if it is too large, the message will be lost or repeatedly sent when the system fails. Generally speaking, multiple JMS destinations should be configured on a single server instead of being dispersed in multiple JMS servers unless they no longer need to scale.
Closing Message Page Scheduling (paning) may increase performance, but will affect scalability. If you open Message Page Scheduling (PAGING), additional I / O operations are required to serve the message to the hard disk, read it again when necessary, but also reduces the requirements for memory.
In general, asynchronous processes are better than synchronous processes, easier to regulate.
WEB container
The Web layer is more in the application to generate expression logic. The widely used architecture is to read data from the application layer and then generate dynamic content using the servlet and JSP, where the application layer is generally composed of EJB. In this structure, servlet and JSP reserve reference to EJB to prevent them directly to databases or data sources. It is a good idea to save these references. If JSP and servlet do not have an EJB deployment on the same application server, it is expensive to use JNDI to query.
The JSP cache tag can be used to store data within the JSP page. These markers support the input and output of the cache. The output of the cache involves the content generated by the code within the marker, involves the cached input involving the code within the marker pair of variables. If you do not want the Web layer frequently, you can turn off the Auto-Reloading function by setting servletReloadChecksecs to -1. After using this method, the server will no longer poll if the Web layer has changed, and if the number of JSP and Servlets is large, the effect is very obvious. It is also recommended not to store too much information in the HTTP session. If the information is necessary, consider using a status session bean to replace.
JVM debugging
Most JVMs today have autonomous adjustment, as they can detect hazardous areas in the code and optimize them. The debug parameters that developed and deployers can consider probably the stack is set. Setting these and there is no general rule. JVM typical stack space, which is generally set to one-third or half organization for the entire heap space by new space or reservation space. The entire heap space cannot be specified excessive memory garbage collection (GC) processing that cannot be supported. In this setup environment, if the heap is too large, the spacing of garbage recovery should be set to a minute or longer. Finally, it is necessary to pay attention to that these settings depend to a large extent, depending on the mode of the application that is deployed on the server. Other information about debugging JVM can be referenced:
Server debugging
In addition to the debug parameters provided by each subsystem, there are also parameters suitable for servers to help improve performance. The most important of which is the number of threads and execution queues. Increasing the number of threads is not always effective, only when the following is true, consider using this method: the predetermined throughput is not reached; waiting for the queue (not started with the request) too long; the CPU still has the rest. Of course, doing so does not necessarily improve performance. The low CPU usage may be due to the competition of other resources of the server, such as without sufficient JDBC connection. These similar factors should be considered when changing threads.
In WebLogic Server 7.0, you provide a function of configuring multiple execution queues, and can define a special EJB or JSP / Servlet request in the deployment. To do this, just transfer the flag-DispatchPolicy
Another bigger problem is to decide to use WebLogic performance packages (http://e-docs.bea.com/wls/docs70/Perform/wlstuning.html - 1112119). If the number of sockets is not much (there is a socket on each server for the remote method call connection to client JVM, and always busy reading request data sent from the client, then use the performance package at this time. There will be obvious improvements. It is also possible that it is possible to make similar or better results, depending on the specific implementation of the JVM during processing network I / O.
Socket reads the thread to take the default queue. In a Windows environment, each CPU has two Socket read threads. In the Solaris environment, there are three Sockets for local input and output (Native I / O). For Java input and output (I / O), the read thread is set by the parameter percentsocketReadertHreads in configuration file config.xml. Its default is 33%, the upper limit is 50%, which is obvious because if there is no thread to handle the request, there will be no more read threads. For Java I / O, the number of read threads should be allowed to approach the client connection, because Java I / O will block when waiting for the request. This is why the number of threads cannot be equal to the reason why the number of threads is increased. in conclusion
We only discussed the partial ways of the debug server. What needs to be remembered is that a design is a foot-written application, usually does not have a good performance performance, regardless of how the server and its parameters are debugged. Throughout the stages of the application development cycle, performance should always be a key factor in consideration from design to deployment. Regular occurrence is that after the performance is placed, it is difficult to find that the problem is discovered.
Note: Introduction to the following is a WebLogic8.1 as an example, and other versions of WebLogic may differ.
1) Set the Java parameter;
a) Edit the WebLogic Server startup script file;
l bea_home / user_projects / domains / domain-name / startweblogic.cmd (StartWeblogic.sh On Unix)
l bea_home / user_projects / domains / domain-name / startmanagedweblogic.cmd (startManagedWeblogic.sh On)
b) Edit the SET JAVA_OPTIONS command, such as: set java_options = -XMS256M -XMX256M;
c) Save and restart.
Note: In WebLogic, in order to get better performance, BEA recommends the minimum Java pile equal to the largest Java pile.
2) Development mode vs. product mode;
The default value of some parameters of development model and product mode may affect performance, the following is a list of parameters that have an impact on performance:
parameter
Development mode default value
Product mode default value
Execute Queue: Thread Count
15 threads
25 Threads
JDBC Connection Pool: MaxCapacity
15 connnections
25 Connections
By starting the management console, in the domain (such as: mydomain)> Configuration> General Select product mode.
3) Try to turn on local I / O;
By launching the management console, the local I / O is enabled in the domain (such as: MyDomain)> Server> Server instance (such as: MyServer)> Configuration> Adjustment Selection Enables local I / O.
Note: This value can also be manually modified the config.xml configuration file.
4) Tuning the execution queue thread;
a) Modify the number of default execution threads
Here, the number of threads of the execution queue represents the number of operations that can be executed simultaneously. But this value is not a big better, it should be just right to set it, too small, the executive queue will accumulate the task to be processed, too big, will consume a lot of system resources to affect the overall performance. In the product mode, it is defen that 25 execution threads. In order to set the ideal number of threads, we can start the management console, in the domain (such as: MyDomain)> Server> Server instance (such as: MyServer)> Monitor> Execute Querans and queues when monitoring the maximum load The waiting request number is determined herein.
The ideal default execution thread is determined by many factors, such as machine CPU performance, overall architecture, I / O, process schedule mechanism for operating system, and JVM thread scheduling mechanism. As the number of CPUs increase, WebLogic can almost linearly improve the number of threads. The more threads, the more time spent on thread switching; the smaller the number of threads, the CPU may not be fully utilized. In order to obtain an ideal thread number, it needs to be repeated. In the test, it can be adjusted as a reference in the number of 25 * CPUs. When the idle thread is small, when the CPU utilization is low, the size of the thread is increased (each 50 increments) can be appropriately increased. For PC Server and Windows 2000, it is preferred that each CPU is less than 50 threads, and the CPU utilization is about 90% is the best.
Modify the thread count in the domain (such as: myServer)> execute Queue> WebLogic.kernel.Defalt> configuration by launching the management console.
b) Set the overflow condition of the execution queue;
WebLogic Server provides the default execution queue or user-defined execution queue to custom overflow conditions, when this overflow condition is met, the server changes its status as a "warning" state, and additionally allocates some threads to process in the queue Requests to reach the length of the queue length.
By launching the management console, in the domain (such as: MyDomain)> Server> Server instance (such as: MyServer)> Execute Queue> WebLogic.kernel.Defalt> Configure the following:
l Queue Length: This value indicates that the maximum number of requests that can be accommodated in the execution queue, the default value is 65536, and finally do not manually change this value.
l Queue length threshold percentage: This value indicates the overflow condition, which is the percentage of the queue length size that can be achieved before the queue overflow.
l The number of threads increase: When the overflow condition is detected, the number of threads in the execution queue will be added. If the CPU and memory are not sufficient, try not to change the default value "0". Because WebLogic will not be automatically reduced once it is increased, although it may ultimately reducing the request, it will affect the performance of the program in the future run.
l Maximum thread: In order to prevent excessive number of threads from being created, it can be controlled by setting the maximum thread.
In actual application scenarios, the above parameters should be adjusted appropriately depending on the specific situation.
c) Set the execution queue monitoring behavior
WebLogic Server automatically monitors when an execution thread becomes "blocked". The execution thread that changes to the "blocked" state will not be able to complete the current job and no new requests will be performed. If all execution threads in the execution queue be changed to "block" state, WebLogic Server may change the status "Warning" or "Severe" state. If WebLogic Server changes to a "severe" state, you can turn off this server via Node Manager and restart it. For details, please refer to: Node Manager Capabilities documentation. By launching the management console, you can configure the following items under the domain (such as: MyDomain)> Server instance (such as: MyServer)> Configuration> Adjustment:
l Blocking Thread For the longest time: The length of the thread must continue to work continuously before this server diagnose the thread as the blocking thread. By default, WebLogic Server considers that the thread has become a blocking thread after 600 seconds.
l Blocking thread timer interval: WebLogic Server regularly scan threads to see if they have worked continuously in the interval time (seconds) of the length of time specified in the "Block Thread Machic" field. By default, WebLogic Server set this time interval to 600 seconds.
5) Tuning TCP connection number;
WebLogic Server uses the Accept Backlog parameter to specify the queue size requesting the server to the operating system, the default value is 50. When the system is overloaded, this value may be too small, and the log is reported to the valid connection request, which can be rejected, which can improve the Accept Backlog 25% until the connection refusal to errors disappear. For Portal types, the default value is often not enough. Login Timeout and SSL Login Timeout parameters represent the timeout time of normal connections and SSL connections, if the client connection is larger than the server interrupt or SSL capacity, you can try to add this value.
Configure "Accept Preparation Connections" under the domain (such as a MyDomain)> Server instance (such as: MyServer)> Server> Server instance (such as: MyServer)> Configuration> Adjustment.
6) Change the Java compiler;
The standard Java compiler is Javac, but compiled JSP servlets is too slow. In order to improve compilation speed, you can use the SJ or JIKES compiler to replace the Javac compiler. Let me talk about the Java compiler:
By launching the management console, change the Java compiler in the domain (such as: MyServer)> Server> Server instance (eg MyServer)> Configuration> Configuration, the Java compiler is changed, and the default is JavaC. Enter the full path, such as: c: /visualcafe31/bin/sj.exe. Then open the advanced option to prepare the Java compiler path pre-planned option when preparing the Java code, such as: BEA_HOME / JDK141_02 / JRE / lib / rt.jar.
7) Use Webogic Server clusters to improve performance;
I will not be fine about how to configure the WebLogic cluster. For details, please refer to: Introduction to WebLogic Server Clustering.
8) WebLogic EJB tuning
Since EJB2.0 has already used it, EJB3.0 is mature, I added this part!
9) JDBC application tuning
JDBC Connection Pool Tuning is subject to the number 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 maximum number of connections is, in order to avoid the resource consumption on both sides, it is recommended to set the maximum value of the connection pool equal to or slightly smaller than the number of threads. At the same time, in order to reduce the overhead of the new connection, set the minimum and maximum value to match. Increasing Statement Cache Size helps for a large number of applications that use PreparedStatement objects, WebLogic can cache these objects for each connection, and this value is default 10. In the premise of ensuring that the database cursor is sufficient, you can improve Statement Cache Size as needed. For example, when you set up the number of connections 25, when cache size is 10, 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 the JDBC Connection Pool provides a lot of 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 not to set a test table, and Test Reserved Connections and Test Released Connections are not needed. Of course, if your database is unstable, the time is intermittent, you may need the above parameters to open.
Finally, the selection of the type of driver is mentioned. Take Oracle as an example, Oracle provides Thin driver and OCI driver, in terms of performance, OCI drive is stronger than Thin driver, especially the amount of data. However, in a simple database operation, performance is not large, and this weak will be compensated as Thin drivers continue to improve. The thin driver is significantly stronger than OCI drive. So in general, this is recommended to use Thin driver. The latest drive may not be the latest in the WebLogic Server / Bin directory, please take the Oracle website: http://www.oracle.com/technology/software ... JDBC / HTDOCS / JDBC9201.html.
10) JSP tuning
Set JSP-param PageCheckseconds = -1;
Set serlet-reload-check = -1 or servletReloadChecksecs = -1;
Set JSP-Param Precompile = true, close the JSP precompiled option.
