Servlets JSP Performance Tuning Tips

9. Control HttpSession(JSP)

Many applications require a series of client requests so they can associate with one another. Web-based applications are responsible for maintaining such state, called a session, because the HTTP protocol is stateless. To support applications that must maintain state, Java servlet technology provides an API for managing sessions and allows several mechanisms for implementing sessions. Sessions are represented by an HttpSession object, but a cost is involved while using it. An HttpSession must be read by the servlet whenever it is used and rewritten when it is updated. You can improve performance by applying the following techniques:

1. Do not create HttpSessions in JSP pages by default: By default, JSP pages create HttpSessions. If you do not use HttpSession in your JSP pages, to save some performance overhead, use the following page directive to prevent HttpSessions from being created automatically when they are unnecessary in JSP pages:

<%@ page session="false"%>

2. Do not store large object graphs inside an HttpSession: If you store the data in the HttpSession as one large object graph, the application server will have to process the entire HttpSession object each time. This forces Java serialization and adds computational overhead. The throughput decreases as the size of the objects stored in the HttpSession increases because of the serialization cost.

3. Release HttpSessions when done: Invalidate sessions when they are no longer needed using the HttpSession.invalidate() method.

4. Set session time-out value: A servlet engine has a default session time-out value set. If you do not either remove the session or use it for the time equal to the session time-out, the servlet engine will remove the session from memory. The larger the session time-out value, the more it affects scalability and performance because of overhead on memory and garbage collection. Try to keep the session time-out value as low as possible.

10. Use gzip compression

Compression is the act of removing redundant information, representing what you want in as little possible space. Using gzip (GNU zip) to compress the document can dramatically reduce download times for HTML files. The smaller your information’s size, the faster it can all be sent. Therefore, if you compress the content your Web application generates, it will get to a user faster and appear to display on the user’s screen faster. Not every browser supports gzip compression, but you can easily check whether a browser supports it and then send gzip-compressed content to only those browsers that do.

Here is the code snippet that shows how to send compressed content whenever possible:

public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException 
{
  OutputStream out = null

	   // Check the Accepting-Encoding header from the HTTP request.
  	   // If the header includes gzip, choose GZIP.
   	   // If the header includes compress, choose ZIP.
                  // Otherwise choose no compression.

  String encoding = request.getHeader("Accept-Encoding");    
      
  if (encoding != null && encoding.indexOf("gzip") != -1)
  {
    response.setHeader("Content-Encoding" , "gzip");
    out = new GZIPOutputStream(response.getOutputStream());
  }
  else if (encoding != null && encoding.indexOf("compress") != -1)
  {
    response.setHeader("Content-Encoding" , "compress");
    out = new ZIPOutputStream(response.getOutputStream());
  } 
  else
  {
    out = response.getOutputStream();
  }
   ...
   ...                        
}  

11. Do not use SingleThreadModel

SingleThreadModel ensures that servlets handle only one request at a time. If a servlet implements this interface, the servlet engine will create separate servlet instances for each new request, which will cause a great amount of system overhead. If you need to solve thread safety issues, use other means instead of implementing this interface. SingleThreadModel interface is deprecated in Servlet 2.4.

12. Choose the right include mechanism

There are two ways you can include files in a JSP page: include directive (<%@ include file="test.jsp" %>) and include action (). The include directive includes the specified file’s content during the translation phase; i.e., when the page converts to a servlet. The include action includes the file’s content during the request processing phase; i.e., when a user requests the page. Include directive is faster than include action. So unless the included file changes often, use include directive for better performance.

13. Choose the right scope in useBean action

One of the most powerful ways to use JSP pages is in cooperation with a JavaBeans component. JavaBeans can be directly embedded in a JSP page using the action tag. The syntax is as follows:

The scope attribute specifies the scope of the bean’s visibility. The default value for scope attribute is page. You should select the correct scope based on your application’s requirements, otherwise it will affect application performance.

For example, if you need an object only for a particular request, but your scope is set to session, that object will remain in memory even after you are done with the request. It will stay in memory until you explicitly remove it from memory, you invalidate the session, or the session times out as per the session time-out value configured with the servlet engine. If you do not select the right scope attribute value, it will affect the performance because of overhead on memory and garbage collection. So set the exact scope value for the objects and remove them immediately when finished with them.

14. Miscellaneous techniques

1. Avoid string concatenation: The use of the + operator to concatenate strings results in the creation of many temporary objects because strings are immutable objects. The more you use +, the more temporary objects are created, which will adversely affect performance. Use StringBuffer instead of + when you concatenate multiple strings.

2. Avoid the use of System.out.println: System.out.println synchronizes processing for the duration of disk I/O, and that can slow throughput significantly. As much as possible, avoid the use of System.out.println. Even though sophisticated debugging tools are available, sometimes System.out.println remains useful for tracing purpose, or for error and debugging situations. You should configure System.out.println so it turns on during error and debugging situations only. Do that by using a final boolean variable, which, when configured to false, optimizes out both the check and execution of the tracing at compile time.

3. ServletOutputStream versus PrintWriter: Using PrintWriter involves small overhead because it is meant for character output stream and encodes data to bytes. So PrintWriter should be used to ensure all character-set conversions are done correctly. On the other hand, use ServletOutputStream when you know that your servlet returns only binary data, thus you can eliminate the character-set conversion overhead as the servlet container does not encode the binary data.

4. Avoid the unnecessary creation of objects: This has always been good advice–creating unnecessary objects wastes memory and wastes a fair amount of time as the objects are created. With servlets, it’s even better advice. All but the most recent JVMs have a global object heap that must be locked for each new memory allocation. While any servlet is creating a new object or allocating additional memory, no other servlet can do so.