Shulou(Shulou.com)06/02 Report--

This article will give you a detailed explanation on how to improve the response speed of JSP pages. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Method 1: cache data in the init () method of servlet

When the application server initializes the servlet instance and before serving the client request, it calls the init () method of the servlet. During the life cycle of a servlet, the init () method is called only once. System performance can be greatly improved by caching some static data in the init () method or performing some time-consuming operations that only need to be performed once.

For example, by establishing a JDBC connection pool in the init () method is an example of *. Suppose we are using the DataSource interface of jdbc2.0 to obtain a database connection. In general, we need to obtain a specific data source through JNDI. We can imagine that in a specific application, if every SQL request has to execute a JNDI query, then the system performance will degrade sharply. The workaround is the following code, which caches DataSource so that it can still be used the next time SQL is called:

The following is a reference clip:

Public class ControllerServlet extends HttpServlet {

Private javax.sql.DataSource testDS = null;

Public void init (ServletConfig config) throws ServletException {

Super.init (config)

Context ctx = null

Try {

Ctx = new InitialContext ();

TestDS = (javax.sql.DataSource) ctx.lookup ("jdbc/testDS")

} catch (NamingException ne) {ne.printStackTrace ();}

} catch (Exception e) {e.printStackTrace ();}

}

Public javax.sql.DataSource getTestDS () {

Return testDS;

}

...

...

}

This can effectively improve the response speed of JSP pages.

Method 2: disable automatic overloading of servlet and JSP (auto-reloading)

Servlet/JSP provides a practical technology, namely automatic overloading technology, which provides a good development environment for developers. When you change servlet and JSP pages, you do not have to restart the application server. However, this technology is a great drain on the resources of the system during the product run-time, because it puts a great burden on the classloader (classloader) of the JSP engine. Therefore, turning off the automatic reload function is a great help to improve the response speed of JSP pages.

Method 3: don't abuse HttpSession

In many applications, our program needs to maintain the state of the client so that pages can communicate with each other. Unfortunately, because HTTP is inherently stateless, the state of the client cannot be saved. Therefore, the general application server provides session to save the state of the customer. In the JSP application server, the session function is realized through the HttpSession object, but at the same time, it also brings a lot of burden to the system. Because every time you get or update session, the system has to serialize it in a time-consuming manner. You can improve the performance of the system by dealing with HttpSession in the following ways.

If it is not necessary, you should turn off the default setting for HttpSession in the JSP page. If you don't specify it explicitly, each JSP page creates a HttpSession by default. If you don't need to use session in your JSP, you can disable it by using the following JSP page indicator:

The following is a reference clip:

< @ page session= "false" >

Do not store large data objects in HttpSession: if you store large data objects in HttpSession, every time you read and write to it, the application server will serialize it, thus adding to the additional burden on the system. The larger the data objects you store in HttpSession, the faster the performance of the system will degrade.

When you don't need HttpSession, release it as soon as possible: when you no longer need session, you can release it by calling the HttpSession.invalidate () method. Try to make the session timeout shorter: in the JSP application server, there is a default session timeout. When the customer does nothing after this time, the system automatically releases the relevant session from memory. The higher the timeout, the lower the response speed of the JSP page, so the way to * is to keep its value as low as possible.

Method 4: compress the page output

Compression is a good way to solve data redundancy, especially in today's underdeveloped network bandwidth. Some browsers support gzip (GNU zip) to compress HTML files, which can dramatically reduce the download time of HTML files. Therefore, if you compress the HTML pages generated by servlet or JSP pages, users will think that the page browsing speed will be very fast. Unfortunately, not all browsers support gzip compression, but you can check if the customer's browser supports it in your program. Here is a code snippet about the implementation of this method:

The following is a reference clip:

Public void doGet (HttpServletRequest request, HttpServletResponse response)

Throws IOException, ServletException {

OutputStream out = null

String encoding = request.getHeader ("Accept-Encoding");

If (encoding! = null & & encoding.indexOf ("gzip")!-1) {

Request.setHeader ("Content-Encoding", "gzip")

Out = new GZIPOutputStream (request.getOutputStream ())

}

Else if (encoding! = null & & encoding.indexOf ("comdivss")!-1) {

Request.setHeader ("Content-Encoding", "comdivss")

Out = new ZIPOutputStream (request.getOutputStream ())

} else {

Out = request.getOutputStream ()

}

...

...

}

Method 5: use thread pool

By default, the application server creates a thread for each different client request and dispatches the service () method to them, and when the service () method call is complete, the corresponding thread is withdrawn. This default mode degrades the performance of the system because it consumes some system resources to create and undo threads. Fortunately, we can change this by creating a thread pool.

In addition, we need to set a minimum number of threads and a * number of threads for this thread pool. When the application server starts, it creates a thread pool with a minimum number of threads. When the client has a request, a thread is taken out of the pool for processing, and when the processing is completed, the thread is put back into the pool. If there are not enough threads in the pool, the system will automatically increase the number of threads in the pool, but the total number cannot exceed the number of threads. By using thread pools, when client requests increase sharply, the load of the system shows a smooth upward curve, thus improving the scalability of the system.

Method 6: choose the correct page inclusion mechanism

There are two ways to include another page in JSP:

1. Use the include indicator

The following is a reference clip:

< @ includee file= "test.jsp" >

2. Use the jsp indicator

The following is a reference clip:

< jsp:includee page= "test.jsp" flush= "true" / >

In practice, it is found that if you use the * method, you can make JSP pages more responsive.

Method 7: correctly determine the life cycle of javabean

One of the great things about JSP is its support for javabean. By using the jsp:useBean tag in a JSP page, you can insert the javabean directly into a JSP page. It can be used as follows:

The following is a reference clip:

< jsp:useBean id= "name" scope= "page | request | session | application"

Class= "package.className" type= "typeName" >

< / jsp:useBean >

The scope attribute indicates the life cycle of the bean. The default life cycle is page. If you do not choose the life cycle of bean correctly, it will affect the performance of the system.

For example, if you only want to use a bean in one request, but you set the life cycle of the bean to session, then when the request ends, the bean will remain in memory unless the session times out or the user closes the browser. This consumes a certain amount of memory and needlessly increases the workload of the JVM garbage collector. So setting the correct life cycle for bean and cleaning them up as soon as bean's mission is over will improve the response speed of using JSP pages.

Some other useful methods

1. Try not to use the "+" operator in string concatenation operations: in java programming, we often use the "+" operator to concatenate several strings, but you probably never thought it would affect system performance, did you? Because strings are constant, JVM produces some temporary objects. The more "+" you use, the more temporary objects will be generated, which will also have some impact on system performance. The solution is to replace the "+" operator with a StringBuffer object.

2. Avoid using the System.out.println () method: because System.out.println () is a synchronous call, that is, when you call it, the disk Ibank O operation must wait for it to complete, so we should try our best to avoid calling it. But it is an indispensable convenient tool when we debug the program. In order to solve this contradiction, I suggest you use the Log4j tool.

3, the tradeoff between ServletOutputStream and PrintWriter: using PrintWriter may bring some small overhead, because it converts all the original output into a character stream to output, so if you use it as a page output, the system will bear a conversion process. There is no problem with using ServletOutputStream as the page output, but it is output in binary. Therefore, it is necessary to weigh the advantages and disadvantages of the two in practical application.

On "how to improve the response speed of JSP pages" this article is shared here, I hope the above content can be of some help to you, so that you can learn more knowledge, if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.