Servlets JSP Performance Tuning Tips

4. Cache the static and dynamic data

The use of caching in different areas of your application gives very good performance. Generally every application’s database schema will have at least some read only tables. There is no need of accessing these tables every time. You can cache that data in memory and reuse it instead of accessing database every time. It reduces network traffic, consumes less CPU cycles and gives good performance.

Caching can be done in three flavors namely static data caching, semi dynamic data caching and dynamic caching. Static data means that the data doesn’t change in its life time, it always constant. Semi dynamic data means that the data changes but not often. For example, the data that changes after every one hour can be called as semi dynamic data, the data does not change for every request. Dynamic data means that it changes the data for every request. Often people use the word dynamic data for semi dynamic data as well. So even I followed the same terminology. In this section, dynamic data is synonymous with semi dynamic data.

It is best to cache static data and dynamic data in order to improve performance. We will discuss a few caching techniques to improve Servlets JSP Performance. They are as follows.

1. Utilizing Browser caching
2. Caching dynamic data at the server
3. Utilizing application server caching facilities
4. Utilizing Servlet API’s built in facility, HttpSession and ServletContext objects

As we saw above, Caching at init() method is useful for caching static data and it reduces the creation time of static data for every request but any way finally we are passing data to the client on every request. This type of caching is useful when you want to pass both static data and dynamic data to the client. One more caching technique is utilizing the browser cache and also cache the content at the server, this can be done by avoiding a call to service() method if the output content is not changed. This technique is achieved by implementing getLastModified() method of HttpServlet class.

Web servers send the response with a ‘Last-Modified‘ header which tells the client when the page was last changed. Web browser sends a request with ‘If-Modified-Since‘ header which tells web server when it last downloaded the page. With this communication server can predict whether the file has changed or not, if not it sends response with ‘Not Modified’ (of 304 status code) so that the browser uses its cache page instead of downloading fresh page. In order to take advantage of this technique, Servlet should implement the getLastModified() method to tell the servlet engine about last modified time. This method returns time in milliseconds.

The third technique is that your application server may support caching facility for dynamic data. All you need to do is that configure the caching properties file which is supported by your server. You can give what Servlet you need to cache and session time out value to remove cache content. For example WebSphere application server supports this type of facility.

The fourth technique is that you can use Servlet API’s HttpSession and ServletContext objects for caching. HttpSession object is available for a user session across multiple requests and ServletContext object is available for all the users using the application. You can set cacheable objects into these objects and get those objects whenever you require within their scope. The methods that support caching are:

	ServletContext.setAttribute(String name, Object cacheableObject);
	ServletContext.getAttribute(String name);
	
	HttpSession.setAttribute(String name, Object cacheableObject);
	HttpSession.getAttribute(String name);

5. Choosing the right session mechanism

We use session mechanism to maintain client state across multiple pages. The session starts when the client, such as browser requests for a URL from the web server and it ends when the web server ends the session or web server times out the session or user logs out or user closes the browser.

There are few approaches available to maintain the session. They are:

1. HttpSession provided by Servlet API
2. Hidden fields
3. Cookies
4. URL rewriting
5. Persistent mechanism

Obviously it is difficult to select one mechanism out of above mentioned approaches to maintain session data. Each one impacts performance depending on amount of the data to be stored as session data and number of concurrent users.

The following table gives you an idea of performance based on the approach used.

Session mechanism	Performance	Description
HttpSession	Good	There is no limit on size of keeping session data
Hidden fields	Moderate	There is no limit on size of passing session data
Cookies	Moderate	There is a limit for cookie size
URL rewriting	Moderate	There is a limit for URL rewriting
Persistent mechanism	moderate to poor	There is no limit of keeping session data

Here the Persistent mechanism means that you store the session data in the database, file storage or any other persistent storage. There are few a approaches for this mechanism, they are

1. Using your application server’s persistent mechanism for session data storage
2. Using your own persistent mechanism by maintaining your own database schema

If you use the first approach, generally application server converts the session objects into BLOB data type and stores in the database. If you use second approach, you need to design the schema as per your session fields and need to store the session data by writing JDBC code for that, this gives better performance than the first approach because conversion of session object to BLOB takes more time than directly storing session data. Either of persistent mechanisms give moderate to poor performance when compared to other approaches because of overhead involved in database calls through JDBC and it makes calls to database on every request in order to store that session data and finally it needs to retrieve the whole session data from database but it scales well on increasing session data and concurrent users.

URL rewriting gives moderate performance because the data has to pass between the client and server for every request but there is a limitation on amount of data that can be passed through URL rewriting. It gives moderate performance because of overhead involved in network for passing data on every request.

Cookies also give moderate performance because they need to pass the session data between client and server. It also has the size limit of 4k for each cookie.

Like URL rewriting and Cookies, Hidden fields need to pass the data between client and server. All these three session mechanisms give moderate performance and is inversely proportional to the amount of session data.

HttpSession mechanism gives better Servlets JSP Performance when compared to other mechanisms because it stores the session data in memory and reduces overhead on network. Only session id will be passed between client and the server. But it does not scale well when the session data is huge and the concurrent number of users are more because of increase in memory overhead and also increase in overhead on garbage collection.

Remember that choosing the session mechanism from one of the above approaches is not only depends on performance, scalability and security. The best approach is to maintain a balance between performance, security and scalability by choosing a mixed approach. Mixture of HttpSession mechanism and Hidden fields gives both performance and scalability. By putting secure data in HttpSession and non secure data on hidden fields you can achieve better security.

6. Control HttpSession(servlets)

If you decided to use HttpSession for your session tracking, then you need to know how your application server/servlet engine implements HttpSession mechanism. You need to take care of the following points.

1. Remove session explicitly
2. Set Session time out value
3. Application server/servelt engine implementation

Generally, your application server/servlet engine will have default session time out value as 30 minutes which means that if you don’t remove session or manipulate that session for 30 minutes then your servlet engine removes that session from memory. If you set long session time out value such as 1 hour, then it keeps all the session objects till 1 hour. This approach effects scalability and performance because of overhead on memory and garbage collection. In order to reduce memory overhead and to increase performance, it is better to remove/invalidate session explicitly using HttpSession.invalidate() method and also try to reduce the session time out value as per your application’s requirement.

Third important point is that your application server may serialize session objects after crossing certain memory limit; it is expensive and effects Servlets JSP Performance because it not only serializes the single session object but also serializes the total object hierarchy. Use ‘transient’ for variables to avoid unnecessary serialization. So know about your application server/servlet engine session implementation mechanism and act accordingly.

7. Disable Servlet auto reloading

Most of the application servers/servlet engines have the capability of loading servlets dynamically, which means you need not restart your server whenever you change the servlet content. Application server/servlet engine loads the servlet with auto reload each time when you configure the servlet. For example, if you configure auto reload as 1 second, then servlet engine loads that servlet after every 1 second. This feature is good at development time because it reduces the development time by avoiding restarting the server after every change in servlet. But it gives poor Servlets JSP Performance at production by unnecessary servlet loading and burden on class loader. So turn off your auto reloading feature in the configuration file to improve performance.

8. Control Thread pool
Servlet engine creates a separate thread for every request and assigns that thread to service() method in its multithreaded servlet and finally it removes that thread after completion of service() method execution. It happens for every request. Your servlet engine may create a new thread for every request by default. This default behavior reduces performance because creating and removing threads is expensive. This can be avoided by using the thread pool. Servlet engine creates pool of threads at start up and assigns a thread from pool to every request instead of creating a fresh thread every time and it returns that thread to the pool after completion. The size of the thread pool depends upon configuration parameters of the pool. The pool will have minimum and maximum number of threads and you can configure these numbers in the configuration file of your servlet engine. The number of maximum and minimum threads in pool depends upon concurrent users for your application. You have to estimate number of concurrent users for your application and give the thread pool size based on that. Obviously there is a limit on thread pool which depends on your hardware resources. By setting thread pool size correctly, the performance of servlet improves significantly. Your application server/ JSP engine may not have facility to configure thread pool. Tomcat’s Servlet Engine has the facility to configure thread pool. Look at your application server / servlet engine documentation for information about thread pool.

Pages: 1 2 3