Chapter 3   Tuning Your Application


This chapter provides a comprehensive guide to tuning your applications for maximum performance. The following topics are discussed in this chapter:

• Java Coding Guidelines

• J2EE Programming Guidelines

Java Coding Guidelines

In this section, we will cover issues related to Java coding and performance related issues. The guidelines laid down in this section are not specific to iPlanet^TM Application Server, but are general rules to be followed while coding Java applications:

• Avoid serialization and deserialization

  In Java, serialization and deserialization of objects is a CPU-intensive procedure and is likely to slow down your application.

• Avoid Arrays

  This is a tough recommendation to follow but the use of arrays should be minimized in Java. One of the primary goals of Java is safety, so many of the problems that plague programmers in C and C++ are not repeated in Java. A Java array is guaranteed to be initialized and cannot be accessed outside of its range.

  This range checking comes at the price of having a small amount of memory overhead on each array as well as verifying the index at run-time. While the amount of time used is minimal, it is nevertheless a factor when a large number of arrays are used in code.

• Use StringBuffer.append() instead of the "+" operator

  In Java, strings are immutable i.e. they never change after creation. For example, the following sequence,

  String str = "testing";

  str = str + "abc";

  is understood by the compiler as:

  String str = "testing";

  StringBuffer tmp = new StringBuffer(str);

  tmp.append("abc");

  str = tmp.toString();   

  Thus, copying is inherently expensive and can become a significant factor in hindering performance in case it is overused. We recommend that you use StringBuffer.append().

• Explicitly assign null value to de-referenced variables

  Doing this helps the garbage collector easily identify the parts of memory that can be safely reclaimed. Java does not prevent you from using excessive amounts of memory or from cycling through too much memory (e.g., creating and de-referencing many objects). You can get memory leaks by holding on to objects without releasing references. This stops the garbage collector from reclaiming those objects, resulting in increasing amounts of memory being used. Thus, explicitly dereferencing variables by setting them to null improves performance.

J2EE Programming Guidelines

The J2EE model defines a framework for application development. It defines the use of JSPs, servlets and EJBs (in addition to JNDI, JMS, and JTS) in application architecture. While all parts of the J2EE model have their uses, some issues need to be kept in mind while designing the architecture. They are:

• Servlet programming guidelines

  All applications in iPlanet Application Server are serviced by JSPs or servlets (which are also entry points to EJBs). In the case of the servlet multithread model (the default model), a single instance of a servlet is created for each JVM. All requests for a servlet on that JVM share the same servlet instance. This can create thread contention. Thus, the use of class variables should be avoided as it creates synchronization problems.

  In addition, the use of the synchronization clause (around code or around methods) should be avoided as this creates critical sections of code. Only a single thread can execute in the synchronized block at one time. All others are blocked and have to await access. This wait queue can be a significant factor for high performance websites.

• Avoid the use of EJBs

  EJBs are very useful in the context of reusable services. However, this flexibility comes at a cost. This is because the method in which EJBs are designed to work rather than any quirk in the implementation of a container (in this case, the container will be iPlanet Application Server). Often, in J2EE applications, requests to EJBs are routed through servlets.

  Servlets need to do a JNDI lookup, get a bean reference and use that reference to call a bean method. Normally, the reference is cached and used for all subsequent hits. Due to the levels of direction that need to be executed before an EJB can be accessed, it is found that EJBs are inherently more expensive than servlets that perform the same task.

  If you need to use EJBs, please follow these steps to improve response time:

  • Cache EJB references at the servlet. This will avoid the need to do a JNDI lookup for every request.

  • The following EJB types are listed in descending order, based on their performance. The bean-type with the highest performance is at the top:

· Stateless Session Beans

· Stateful Session Beans

· Entity Beans with CMP (Container Managed Persistence)

· Entity Beans with BMP (Bean Managed Persistence)

Stateless session beans are the fastest among EJBs and are almost comparable to servlets in performance.

• Use sticky load balancing in the case of stateful session beans. If sticky load balancing is not used and a bean reference (that has been stored in session) gets routed to another iPlanet Application Server, then a cross container lookup will need to be done to service a request. This can be very expensive.

• Size the container (iPlanet Application Server) based on performance tests. Configure threads for processes and set time-out values for iPlanet Application Server. Configure EJB cache for improved performance.

• Try to deploy servlets and JSPs to iPlanet Application Server rather than to the iPlanet Web Server. Deploy an application to iPlanet Application Server if:

· An application is highly transactional

· Requires failover support to preserve session data,

· Accesses legacy data.

• Deploying an application to iPlanet Web Server is useful if an application is mostly stateless, read-only, and non-transactional.

• Ask the server administrator to co-locate EJBs with your presentation logic (servlets and JSPs) on the same server to reduce the number of Remote Procedure Calls (RPCs) when the application runs.
  

  ---

  Note

  Decomposing an application into a moderate to large number of separate EJBs can create a huge application performance degradation and more overhead. EJBs, like JavaBeans, are not simply Java objects. EJBs are higher level entities than Java objects. They are components with remote call interface semantics, security semantics, transaction semantics, and properties.

  ---