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

This article is to share with you about the ways to improve applications in JSP. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

JSP in-depth programming 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:

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;}...}

JSP in-depth programming method 2: disable servlet and JSP automatic overloading (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 overload function is a great help to the improvement of system performance.

JSP in-depth programming 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 your system by dealing with HttpSession in the following ways:

If not, you should turn off the default setting for HttpSession in JSP pages: if you don't specify it explicitly, each JSP page will create 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:

< @ 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 performance of the system, so the way to * is to keep its value as low as possible.

JSP in-depth programming 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:

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 ("compress")! =-1) {request.setHeader ("Content-Encoding", "compress"); out = new ZIPOutputStream (request.getOutputStream ());} else {out = request.getOutputStream ();}.}

JSP in-depth programming method 5: using thread pools

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.

JSP in-depth programming method 6: choose the correct page inclusion mechanism

There are two ways to include another page in JSP: 1. Use the include indicator (<% @ includee file= "test.jsp"% >). 2. Use the jsp indicator (< jsp:includee page= "test.jsp" flush= "true" / >). In practice, I have found that if you use the * method, you can make the system performance higher.

JSP in-depth programming 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 javabean directly into a 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 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 possible after the end of bean's mission will improve the performance of the system.

Some other useful JSP in-depth programming methods

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.

Avoid using the System.out.println () method: because System.out.println () is a synchronous call, that is, the disk I _ System.out.println O operation must wait for it to complete when it is called, we should avoid calling it as much as possible. But it is also an indispensable convenient tool when we debug the program. In order to resolve this contradiction, I recommend that you use the Log4j tool (http://Jakarta.apache.org), which can facilitate debugging without generating methods such as System.out.println ().

Trade-off between ServletOutputStream and PrintWriter: using PrintWriter may incur some small overhead because it converts all the raw output into a character stream for output, so if you use it as page output, the system has to 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.

Thank you for reading! This is the end of this article on "what are the ways to improve applications in JSP?". 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, you can share it 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.