7 ways to improve response times in jsp pages to share
- 2020-06-19 11:32:03
- OfStack
Method 1: Cache the data in servlet's init () method
After the application server initializes the servlet instance, it invokes the init () method of this servlet before serving the client request. The init () method is called only once in the lifetime of an servlet. You can greatly improve system performance by caching 1 static piece of data in the init () method or completing 1 time-consuming operation that only needs to be performed once.
For example, setting up an JDBC connection pool in the init () method is a good example. Suppose we use the jdbc2.0 DataSource interface to get the database connection. Under normal circumstances, we need to get the specific data source through JNDI. We can imagine that in a specific application, if SQL queries were executed once per SQL request, the system performance would be dramatically reduced. The solution is the following code, which caches DataSource so that the next SQL call can still take advantage of it:
Method 2: servlet and JSP are prohibited from automatic overloading (ES24en-ES25en)
Servlet/JSP provides a useful technique called automatic reloading, which provides a good environment for developers to change servlet and JSP pages without having to restart the application server. However, this technology is a significant resource drain on the system during the production run because it places a significant burden on the JSP engine classloader (classloader). Therefore, turning off automatic overloading is a great help in improving system performance.
Step 3: Don't abuse HttpSession
In many applications, our program needs to keep the client state so that the pages can relate to each other. Unfortunately, because HTTP is inherently stateless, it is not possible to save the state of the client. As a result, application servers no. 1 provide session to hold the state of the customer. In THE JSP application server, the HttpSession image is used to realize the functions of session, but it is not only convenient, but also a burden on the system. Because every time you get or update session, the system does time-consuming serialization of it. There are several ways you can improve the performance of HttpSession.
If not, turn off the default Settings for HttpSession on the JSP page. If you do not specify JSP, each HttpSession page will be created by default. If you do not need to use session in JSP, you can disable it with the following JSP page indicator:
< %@ page session="false"% >
Don't store large data pairs in HttpSession: If you store large data pairs in HttpSession, the application server will serialize them every time it is read or written, putting an additional burden on the system. The more data you store in HttpSession, the faster the system degrades.
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. Make session timeout as short as possible: In JSP application servers, there is a default session timeout. When the customer does nothing after this time, the associated session is automatically released from memory. The larger the timeout, the lower the performance of the system, so the best approach is to keep it as low as possible.
Method 4: Compress the page output
Compression is a good way to solve the data redundancy, especially in the network bandwidth is not developed today. Some browsers support gzip (GNU zip) to compress HTML files, which can dramatically reduce the download time of HTML files. Therefore, if you compress servlet or JSP pages to generate HTML pages, users will think that the page will be very fast. Unfortunately, not all browsers support gzip compression, but you can do this by checking in your application that the client's browser supports it. Here is a snippet of code for this approach:
Method 5: Use thread pools
By default, the application server creates a thread for each different client request to process and dispatches them to the service () method, and when the service () method is called, the corresponding thread is withdrawn. This default mode degrades system performance because creating and undoing threads consumes 1 dollar of system resources. Fortunately, we can change this by creating a thread pool.
In addition, we will set a minimum and a maximum number of threads for this thread pool. When the application server starts up, it creates a thread pool equal to the minimum number of threads, pulls one thread from the pool for processing when the client has a request, and puts the threads back into the pool when the processing is complete. If there are not enough threads in the pool, the system automatically increases the number of threads in the pool, but the total cannot exceed the maximum number of threads. By using thread pools, the system's scalability is improved by showing a smooth upward curve in load when client requests increase sharply.
Method 6: Select the correct page inclusion mechanism
There are two ways to include another page in JSP:
1. Use include indicator
< %@ includee file="test.jsp" % >
2. Use the jsp indicator
< jsp:includee page="test.jsp" flush="true"/ >
In practice, it has been found that using the first method can make the system perform better.
Approach 7: Determine the lifecycle of javabean correctly
One of the strengths of JSP is its support for javabean. By using the jsp:useBean tag on an JSP page, you can insert javabean directly into an JSP page. It can be used as follows:
The scope attribute indicates the life cycle of this 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 an bean for one request, but you set the session's lifetime to session, the bean will remain in memory after the request, unless the session timeouts or the user closes the browser. This consumes a fixed amount of memory and unnecessarily increases the workload of the JVM garbage collector. So setting up the correct life cycle for bean and cleaning them up as soon as bean's mission is over will result in an improvement in usage system performance.
Some other useful methods
Try not to use the "+" operator in string concatenation: In java programming, we often use the "+" operator to concatenate several strings, but you probably never thought that it would affect system performance. Since the string is constant, JVM produces a temporary image. The more "+" you use, the more temporary images you generate, which also has a slight impact on system performance. The solution is to replace the "+" operator with the StringBuffer image.
System.out.println () : Since System.out.println () is a synchronous call, when it is called, the disk I/O operation must wait for it to complete, so we try to avoid calling it. But when we are in the debugger is essential to it is a handy tool, in order to solve this contradiction, I suggest you had better use Log4j tools (http: / / Jakarta. apache. org), it can convenient debugging, and won't produce System. out. println () method.
3. Tradeoff between ServletOutputStream and PrintWriter: Using PrintWriter may incur a small overhead because it converts all the original output to a character stream for output, so the system has to bear a conversion process if it is used as page output. Using ServletOutputStream as the page output is not a problem, but it outputs in base 2. Therefore, the advantages and disadvantages of the two should be weighed in practical application.
conclusion
The goal of this article is to greatly improve the performance of your application and thus the overall performance of your J2EE application by tuning servlet and JSP 1. Through these tuning techniques, you can see that it's not really a technology platform (J2EE and EE, for example). NET) determines the performance of your application. It is important that you have a deep understanding of the platform so that you can fundamentally optimize your application.
After the application server initializes the servlet instance, it invokes the init () method of this servlet before serving the client request. The init () method is called only once in the lifetime of an servlet. You can greatly improve system performance by caching 1 static piece of data in the init () method or completing 1 time-consuming operation that only needs to be performed once.
For example, setting up an JDBC connection pool in the init () method is a good example. Suppose we use the jdbc2.0 DataSource interface to get the database connection. Under normal circumstances, we need to get the specific data source through JNDI. We can imagine that in a specific application, if SQL queries were executed once per SQL request, the system performance would be dramatically reduced. The solution is the following code, which caches DataSource so that the next SQL call can still take advantage of it:
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 (a);
testDS = ( javax.sql.DataSource ) ctx.lookup ( "jdbc/testDS" );
}catch ( NamingException ne ) {ne.printStackTrace (a); }
}catch ( Exception e ) {e.printStackTrace (a); }
}
public javax.sql.DataSource getTestDS (a) {
return testDS;
}
...
...
}
Method 2: servlet and JSP are prohibited from automatic overloading (ES24en-ES25en)
Servlet/JSP provides a useful technique called automatic reloading, which provides a good environment for developers to change servlet and JSP pages without having to restart the application server. However, this technology is a significant resource drain on the system during the production run because it places a significant burden on the JSP engine classloader (classloader). Therefore, turning off automatic overloading is a great help in improving system performance.
Step 3: Don't abuse HttpSession
In many applications, our program needs to keep the client state so that the pages can relate to each other. Unfortunately, because HTTP is inherently stateless, it is not possible to save the state of the client. As a result, application servers no. 1 provide session to hold the state of the customer. In THE JSP application server, the HttpSession image is used to realize the functions of session, but it is not only convenient, but also a burden on the system. Because every time you get or update session, the system does time-consuming serialization of it. There are several ways you can improve the performance of HttpSession.
If not, turn off the default Settings for HttpSession on the JSP page. If you do not specify JSP, each HttpSession page will be created by default. If you do not need to use session in JSP, you can disable it with the following JSP page indicator:
< %@ page session="false"% >
Don't store large data pairs in HttpSession: If you store large data pairs in HttpSession, the application server will serialize them every time it is read or written, putting an additional burden on the system. The more data you store in HttpSession, the faster the system degrades.
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. Make session timeout as short as possible: In JSP application servers, there is a default session timeout. When the customer does nothing after this time, the associated session is automatically released from memory. The larger the timeout, the lower the performance of the system, so the best approach is to keep it as low as possible.
Method 4: Compress the page output
Compression is a good way to solve the data redundancy, especially in the network bandwidth is not developed today. Some browsers support gzip (GNU zip) to compress HTML files, which can dramatically reduce the download time of HTML files. Therefore, if you compress servlet or JSP pages to generate HTML pages, users will think that the page will be very fast. Unfortunately, not all browsers support gzip compression, but you can do this by checking in your application that the client's browser supports it. Here is a snippet of code for this approach:
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 (a);
}
...
...
}
Method 5: Use thread pools
By default, the application server creates a thread for each different client request to process and dispatches them to the service () method, and when the service () method is called, the corresponding thread is withdrawn. This default mode degrades system performance because creating and undoing threads consumes 1 dollar of system resources. Fortunately, we can change this by creating a thread pool.
In addition, we will set a minimum and a maximum number of threads for this thread pool. When the application server starts up, it creates a thread pool equal to the minimum number of threads, pulls one thread from the pool for processing when the client has a request, and puts the threads back into the pool when the processing is complete. If there are not enough threads in the pool, the system automatically increases the number of threads in the pool, but the total cannot exceed the maximum number of threads. By using thread pools, the system's scalability is improved by showing a smooth upward curve in load when client requests increase sharply.
Method 6: Select the correct page inclusion mechanism
There are two ways to include another page in JSP:
1. Use include indicator
< %@ includee file="test.jsp" % >
2. Use the jsp indicator
< jsp:includee page="test.jsp" flush="true"/ >
In practice, it has been found that using the first method can make the system perform better.
Approach 7: Determine the lifecycle of javabean correctly
One of the strengths of JSP is its support for javabean. By using the jsp:useBean tag on an JSP page, you can insert javabean directly into an JSP page. It can be used as follows:
<jsp:useBean id="name" scope="page|request|session|application"
class="package.className" type="typeName">
</jsp:useBean>
The scope attribute indicates the life cycle of this 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 an bean for one request, but you set the session's lifetime to session, the bean will remain in memory after the request, unless the session timeouts or the user closes the browser. This consumes a fixed amount of memory and unnecessarily increases the workload of the JVM garbage collector. So setting up the correct life cycle for bean and cleaning them up as soon as bean's mission is over will result in an improvement in usage system performance.
Some other useful methods
Try not to use the "+" operator in string concatenation: In java programming, we often use the "+" operator to concatenate several strings, but you probably never thought that it would affect system performance. Since the string is constant, JVM produces a temporary image. The more "+" you use, the more temporary images you generate, which also has a slight impact on system performance. The solution is to replace the "+" operator with the StringBuffer image.
System.out.println () : Since System.out.println () is a synchronous call, when it is called, the disk I/O operation must wait for it to complete, so we try to avoid calling it. But when we are in the debugger is essential to it is a handy tool, in order to solve this contradiction, I suggest you had better use Log4j tools (http: / / Jakarta. apache. org), it can convenient debugging, and won't produce System. out. println () method.
3. Tradeoff between ServletOutputStream and PrintWriter: Using PrintWriter may incur a small overhead because it converts all the original output to a character stream for output, so the system has to bear a conversion process if it is used as page output. Using ServletOutputStream as the page output is not a problem, but it outputs in base 2. Therefore, the advantages and disadvantages of the two should be weighed in practical application.
conclusion
The goal of this article is to greatly improve the performance of your application and thus the overall performance of your J2EE application by tuning servlet and JSP 1. Through these tuning techniques, you can see that it's not really a technology platform (J2EE and EE, for example). NET) determines the performance of your application. It is important that you have a deep understanding of the platform so that you can fundamentally optimize your application.