WebLogic Server Performance Tuning

 

Any successful product in the market has good performance. AlthoughWebLogic Server is a widely used product that requires many features, but its performance is absolutely essential.
Good Programming habits play a major role in helping applications run, but they are not enough. The application server must be able to port between multiple hardware and operating systems, and be universal for a wider range of application types. This is why the application server provides a variety of debugging buttons. By adjusting these buttons, the server can be more suitable for Running Environments and applications.

This article discusses some of the debugging parameters for WebLogic, but does not list all the adjustable attributes. In addition, before applying the recommended methods to the product environment, we recommend that you test them in the test environment.

Performance monitoring and bottleneck Detection

The first step in performance debugging is to isolate "dangerous areas ". Performance bottlenecks can exist in any part of the system-networks, databases, clients, or application servers. It is important to first determine which system component causes performance problems. debugging a wrong component may make the situation worse.

WebLogic Server provides the system administrator with two methods: console and command line tool to monitor system performance. The server has a collection called mbean, which is used to collect information such as thread consumption, resource surplus, and cache usage. Both the console and the command line manager can call the information from the server. The screen snapshot in Figure 1 shows the usage and surplus of the cache in the EJB container, which is one of the performance monitoring options provided by the console.

Code Analyzer is also an effective tool for application code to detect performance bottlenecks. There are several good code analyzers, such as Wily Introscope, Jprobe, and Optimizelt.

EJB container

The most expensive operations in EJB containers are of course DATABASE calls-loading and storing entity beans. Containers also provide various parameters to reduce the number of database accesses. However, unless in special circumstances, at least one loading operation and one storage operation are required for each bean transaction. These special situations are:
1. Bean is read-only. In this case, the bean is loaded only once during the first access and never needs to be stored. Of course, if the read-timeout-seconds parameter is exceeded, the bean will be loaded again.

2. Bean has a special or positive concurrency policy, and the db-is-shared parameter is set to false. In WebLogic Server 7.0, this parameter is renamed cache-between-transactions. Setting the parameter db-is-shared to false is equivalent to setting the parameter cache-between-transactions to true.

3. the Bean has not been modified in the transaction. At this time, the container will optimize the storage operation.

If this is not the case, each entity bean in the code path will be loaded and stored at least once during each transaction. Some features can reduce database calls or overhead of database calls, such as high-speed cache technology, field grouping, concurrency policies, and eager relationship caching, some of these features are newly added to WebLogic Server 7.0.
Cache: the size of the Entity bean cache space is defined by the parameter max-beans-in-cache in the weblogic-ejb-jar.xml. The container is called from the database when loading the bean for the first time in the transaction, and the bean is also stored in the cache. If the cache space is too small, some beans will be stuck in the database. In this way, if you do not consider the first two special cases mentioned above, these beans must be re-loaded from the database during the next call. Calling bean from the cache also means that you do not have to call setEntityContext () at this time (). If the key (primary) Key of the bean is a combination of domains or is complex, you can save time setting for them.

Domain group: The domain group is the domain that is specified to be loaded from the database for the search method. If the entity bean is associated with a large BLOB domain (for example, an image) and rarely accessed, you can define a domain group to exclude this domain, this domain group is associated with a search method, so that the BLOB domain will not be loaded during the search. This feature is only applicable to beans of EJB2.0.

Concurrency policy: In WebLogic Server 7.0, the container provides four concurrency control mechanisms. They are exclusive, database, positive, and read-only. The concurrency policy is closely related to the isolation level during the transaction. Concurrency Control is not a real measure to improve performance. Its main purpose is to ensure the consistency of the data represented by the Entity bean, which is mandatory by the bean deployer. In any case, some control mechanisms make the container process requests faster than others, but this speed is at the cost of data consistency.
The strictest concurrency policy is exclusive. Access to beans using special primary keys is serialized. Therefore, only one transaction can access beans at a time. Although this provides good concurrency control in the container, the performance is limited. This method is useful when Transactions allow mutual caching, but cannot be used in the cluster environment. In this case, the load operation is optimized and thus the concurrency may be lost.

Database-based concurrency policies differ from database concurrency control. The Entity bean is not locked in the container, and multiple transactions are allowed to perform concurrent operations on the same entity bean, thus improving the performance. Of course, this may require a higher isolation level to ensure data consistency.

The positive concurrency policy is also different from the concurrency control of the database. The difference is that the check for Data Consistency occurs when the configured Update operation is stored, rather than locking the entire row during loading. If the access to the same bean in the application is not very intense, this policy is faster than the database-based policy, although the two provide the same data consistency protection level. However, when a conflict occurs, this policy requires the caller to initiate a new call. This feature is only applicable to ejbs 2.0.

Read-Only policies can only be used for read-only beans. The Bean is loaded only when the application is accessed for the first time or when the value specified by the read-timeout-seconds parameter is exceeded. Bean never needs to be stored. When the basic data changes, the bean will also be notified through the read-mostly format, resulting in re-loading.

Closely associated cache: If two entity beans, bean A and bean B are associated in CMR (container relationship management), and the two are accessed in the same transaction, it is loaded by the same database call, which is called closely associated cache. This is a new feature of WebLogic Server 7.0 and applies only to EJB2.0.

In addition to the features listed above that increase the performance by optimizing the access to the database in the container, some other parameters for Session bean and Entity bean can help improve the performance.

Buffer Pool and high-speed cache are the main features that EJB containers provide to Improve the Performance of session beans and entity beans. However, these methods are not applicable to all types of beans. Their negative side is high memory requirements, although this is not the main problem. The buffer pool is applicable to stateless Session bean (SLSB), message-driven bean (MDB), and Entity bean. Once the buffer pool size is set for SLSB and MDB, many instances of these beans will be created and put into the buffer pool, and the setSessionContext ()/setMessageDriveContext () method will be called. The size of the buffer pool set for these beans does not need to exceed the number of execution threads configured (in fact, it is required to be smaller than this number ). If the setSessionContext () method is used to perform any expensive operations, the JNDI query is completed, and the instance method call in the buffer pool will speed up. For the Entity bean, after the setEntityContext () method is called, the buffer pool is connected to the bean's anonymous instance (without a primary key ). These instances can be used by query operations. The query method extracts an instance from the buffer pool, specifies a primary key for it, and then loads the corresponding bean from the database.

Cache is applicable to stateful Session bean (SFSB) and Entity bean. Entity bean has been discussed earlier. For SFSB, caching can avoid serialization to hard disks. Serializing to a hard disk is very expensive and should be avoided. The cache size for SFSB is slightly larger than the number of concurrent clients connected to the server. This is because the container will try to hold the bean on standby only when the cache is occupied by 85%. If the cache is greater than what is actually needed, the container will not wait for the bean through the cache.

The EJB container provides two methods for calling bean-to-bean and Web-tier-to-bean: value transfer call and transfer address call. If the bean is in the same application, it uses the transfer address method by default, which is faster than passing the value. Generally, the transfer address method should not be disabled unless it is required for good reasons. Another way to force a transfer address is to use a local interface. Another feature introduced in WebLogic Server 7.0 is activation for stateful services ). Although this method affects the performance to some extent, it greatly improves the scalability due to low memory requirements. If the scalability is not worth noting, you can send the noObjectAction parameter to ejbc to disable activation ).

JDBC

For database access, debugging JDBC is equally important as debugging EJB containers. For example, set the size of the Connection Pool-the connection pool should be large enough to accommodate the connection requirements of all threads. If all 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, this is less than the number of threads reading the socket (the thread used to read requests in the default execution Queue. To avoid creating and deleting connections during running, you can set the connection pool to its maximum capacity at the beginning. If possible, make sure that the TestConnectionsOnReserve parameter is set to false (false, which is the default setting ). If this parameter is set to true, tests are performed before the connection is assigned to the caller. This requires repeated connections to the database.

Another important parameter is PreparedStatementCacheSize. Each connection sets a static cache for the macro Statement, which is specified when the JDBC connection pool is configured. The cache is static and it is important to keep this in mind. This means that if the cache size is n, only the first n statements in the cache will be executed. To ensure that expensive SQL statements can be cached, use a startup class to store these statements in the cache. Although the caching technology has greatly improved the performance, it cannot be used blindly. If the format of the database changes, the statements in the cache cannot be invalidated or replaced with a new one without restarting the server. Of course, statements in the cache will keep the cursor in the database.

For WebLogic Server 7.0, jDriver performance improvement has made it much faster than the Oracle compaction driver, especially for applications that require a large number of SELECT operations. This can be exploited by submitting from HP