Performance tuning parameters

          Performance tuning parameters

 

Web Logic Server performance tuning ranges over an extremely broad area and includes the tuning of 

1. Operating system Tuning (CPU and Native IO)
2. JVM Tuning (Heap and GC tuning)
3. Weblogic server Tuning ( Cluster,Thread pools and stuck threads)
4. Workmangers Tuning. (Define workmangers)
5. Java DataBase Tuning (Connection Pools ,Data sources,Transactions )
6. JMS Tuning
7. Application Tuning and Web services Tuning (Servelets, JSP's)

Setting Java Parameters for Starting WebLogic Server

The important performance tuning parameters in these files are the JAVA_HOME parameter and the Java heap size parameters: 

• Change the value of the variable JAVA_HOME to the location of your JDK. For example:
  set JAVA_HOME=C:\bea\jdk150_03 
• For higher performance throughput, set the minimum java heap size equal to the maximum heap size. For example:
  "%JAVA_HOME%\bin\java" -server – Xms512m – Xmx512m -classpath %CLASSPATH% - 

Work Managers and Execute Queues

Execute Queues: incoming requests are put into a default execute queue or a user-defined execute queue. Each execute queue has an associated execute queue manager that controls an exclusive, dedicated thread-pool with a fixed number of threads in it.

Work managers provide you the ability to better control thread utilization (server performance) than execute-queues, primarily due to the many ways that you can specify scheduling guidelines for the priority-based thread pool. These scheduling guidelines can be set either as numeric values or as the capacity of a server-managed resource, like a JDBC connection pool.

Tuning the Stuck Thread Detection Behavior

WebLogic Server diagnoses a thread as stuck if it is continually working (not idle) for a set period of time. You can tune a server’s thread detection behavior by changing the length of time before a thread is diagnosed as stuck, and by changing the frequency with which the server checks for stuck threads.

a thread in an execute queue becomes “stuck.” Because a stuck thread cannot complete its current work or accept new work

WebLogic Server Clusters to Improve Performance

a group of WebLogic Servers instances that together provide fail-over and replicated services to support scalable high-availability operations for clients within a domain.

Scalability expands the capacity of the middle tier beyond that of a single WebLogic Server or a single computer,New WebLogic Servers can be added to a cluster dynamically to increase capacity but it must be able to communicate by IP multicast.

Session Replication

User session data can be stored in two standard ways in a J2EE application: stateful session EJBs or HTTP sessions.

HTTP Seession replication and Replica aware stub.

high-availability by using the redundancy of multiple servers to insulate clients from failures. The same service can be provided on multiple servers in a cluster. If one server fails, another can take over. The ability to have a functioning server take over from a failed server increases the availability of the application to clients.

Java Heap Size and Garbage Collection

Java heap is repository for live objects, dead objects, and free memory. When an object can no longer be reached from any pointer in the running program, it is considered “garbage” and ready for collection.

Garbage collectors usually have to stop all other activity for some portion of the garbage collection process. This stop-the-world approach means all application-related work stops while the garbage collector runs. As a result, any in-flight requests will experience an increase in their response time by the amount of time taken by the garbage collector. Other, more sophisticated collectors run either incrementally or truly concurrently to reduce or eliminate the application pauses. Some garbage collectors use a single thread to do their work; others employ multiple threads to increase their efficiency on multi-CPU machines. Some garbage collectors used by modern JVMs are:

Types of Collectors

•    Mark-and-sweep collector – traverses the object graph and marks reachable objects. Next, the heap is scanned for unmarked objects and their memory added to a list of available memory segments. This collector uses a single thread to do its work and is a stop-the-world collector. 
•    Mark-sweep-compact collector – uses the same marking phase as a mark-and-sweep collector. During the second phase, the heap is compacted by copying marked objects to a new area of the heap. These collectors are stop-the-world collectors. 
•    Copying collector – divides the heap into two areas. Only one area at a time is used. When the garbage collector runs, all reachable objects are copied to the other area, thus compacting the heap as the live objects are copied. All dead objects are left behind. This algorithm works well for short-lived objects, but the expense of continually copying long-lived objects makes it less efficient. This is a stop-the-world collector. 
•    Incremental collector – divides the heap into multiple areas and collects garbage from only one area at a time. This can create much smaller, though more frequent, pauses in the application. Numerous approaches exist for defining how the actual collection is handled from traditional mark-and-sweep to algorithms designed explicitly for use with multiple smaller areas. 
•    Generational collector – divides the heap into two or more areas that are used to store objects with different lifetimes. The JVM generally creates all new objects in one of these areas. Over time, the objects that continue to exist get tenured and move into another area for longer-lived objects. Generational collectors often use different algorithms for the different areas to optimize performance. 
•    Concurrent collector – runs concurrently with the application, typically as one or more background threads. These collectors typically have to stop-the-world at some point to complete certain tasks, but the amount of time they halt all processing is significantly reduced because of their background work. 
•    Parallel collector – uses one of the traditional algorithms but uses multiple threads to parallelize their work on multiprocessor machines. This can dramatically improve the scalability of an application.