JSP and Servlet Optimization

1. Using the init () method in servlet for high-speed cache
After the application server initializes the servlet instance and provides services for client requests, it will call the init () method of the servlet. In the lifecycle of a servlet, The init () method is called only once. By caching some static data in the init () method or completing some time-consuming operations that only need to be executed once, the system performance can be greatly improved.

Test results:
Using init is faster than using init:
0.465 vs. 0.591

You can observe JVM memory usage in jconsole.
If init is not used, the memory will gradually increase. If init is used, the memory will be relatively stable.

2. Disable auto-reload in Web. xml
<Context docbase = "F:/petweb" reloadable = "false" Path = "/PET"/>
Reloadable = "false" indicates that when the content in the application changes, the server will not automatically load it. This attribute is usually set to true in the development stage for convenient development, set it to false in the release phase to speed up application access. Docbase is a path. You can use an absolute path or a relative path relative to webapps. The value of the path attribute is the root address during access. The access address is as follows: http: // localhost: 8080/PET/

3. Do not abuse httpsession
In many applications, our programs need to maintain the client state so that pages can communicate with each other. Unfortunately, because HTTP is inherently stateless, the client state cannot be saved. Therefore, common application servers provide sessions to store the customer's status. In the JSP application server, the session function is implemented through the httpsession object, but it brings a lot of burden to the system while being convenient. Because whenever you obtain or update a session, the system will perform time-consuming serialization operations on it. You can improve the system performance through the following processing methods for httpsession.

If not, disable the default settings for httpsession on the JSP page. If you do not specify it explicitly, an httpsession is created for each JSP page by default. If you do not need to use session in your JSP, you can use the following JSP page indicator to disable it:
<% @ Page session = "false" %>

Do not store enlarged data pairs in httpsession: If you Store enlarged data pairs in httpsession, the application server will serialize them whenever it reads/writes data, this increases the additional burden on the system. The larger the data pair you store in httpsession, the faster the system performance is.

If you do not need an httpsession, release it as soon as possible: when you no longer need a session, you can release it by calling the httpsession. invalidate () method. Set the Session Timeout time to a shorter value: On the JSP application server, there is a default session timeout time. When the customer does not perform any operation after this time, the system will automatically release the relevant session from the memory. The larger the timeout value, the lower the system performance. Therefore, the best way is to keep its value at a lower level.

4. compress the page output
Method 1: Some containers (servers) provide functions, but this is limited to specific containers. For example, Apache + Tomcat or resin-pro.

Method 2: perform manual gzip compression before deployment and use it with the servlet filter. This can implement the gzip function, but reduces the flexibility.

Lab:
Write a compression filter in servelet, and then observe the difference in data transmission volume and transmission speed before and after compression in httpwatch.

Note that the container requires a large amount of memory for processing compression, the original response is copied to the JVM memory, and then the compression algorithm is run, the algorithm itself needs to use a certain amount of memory to create and process intermediate data.

 

Refer:
Http://lylhelin.javaeye.com/blog/821957
Http://tdcq.javaeye.com/blog/453644

 

5. Use the thread pool
By default, the application server creates a thread for each different client request for processing and assigns them a service () method. After the service () method is called, the corresponding thread is also revoked. This default mode reduces system performance because creating and canceling threads consume a certain amount of system resources. But fortunately, we can change this situation by creating a thread pool.

In addition, we also need to set a minimum number of threads and a maximum number of threads for this thread pool. When the application server starts, it creates a thread pool with the minimum number of threads equal to the number of threads. When the customer requests, it extracts a thread from the pool for processing, after the processing is complete, re-place the thread into the pool. If the number of threads in the pool is insufficient, the system automatically increases the number of threads in the pool, but the total number cannot exceed the maximum number of threads. By using the thread pool, when client requests increase sharply, the system load will show a smooth upward curve, thus improving the scalability of the system.

 

6. Select the correct page inclusion mechanism
There are two methods in JSP to include another page:
(1) Use the include indicator
<% @ Include file = "test. jsp" %>

(2) Use JSP indicators
<JSP: Include page = "test. jsp" Flush = "true"/>
In practice, it is found that the first method can improve the system performance.

Because the first method is to execute include in the compilation phase and integrate it with the servlet of the main jsp. The second type is executed in the request processing phase.

 

7. correctly determine the lifecycle of JavaBean
A powerful part of JSP is its support for JavaBean. By using the <JSP: usebean> tag on the JSP page, you can insert a JavaBean directly to a JSP page. It is used as follows:
<JSP: usebean id = "name" Scope = "Page | request | session | application" class = "package. classname" type = "typename"> </jsp: usebean>

The scope attribute specifies the bean lifecycle. The default lifecycle is page. If you do not correctly select the bean lifecycle, it will affect the system performance.

For example, if you only want to use a bean in a request, but you set the bean lifecycle to session, after this request is complete, this bean will remain in the memory unless the session times out or the user closes the browser. This will consume a certain amount of memory and increase the workload of the JVM garbage collector. Therefore, setting the correct lifecycle for beans and clearing them as soon as possible after Bean's mission will improve system performance.

Lab:
Compile a JSP page to reference the bean, use different scopes to point out the lifecycle of the bean, and then use jprofiler to view the lifecycle of the object in the memory.

 

 

Refer:
Http://hi.baidu.com/netpet/blog/item/7501ae4498b00882b3b7dc05.html