Method 1: Cache data in the init() method of the servlet
After the application server initializes the servlet instance and before servicing client requests, it calls the servlet's init() method. In the life cycle of a servlet, the init() method will only be called once. By caching some static data in the init() method or completing some time-consuming operations that only need to be performed once, system performance can be greatly improved.
For example, establishing a JDBC connection pool in the init() method is the best example. Suppose we use the DataSource interface of jdbc2.0 to obtain a database connection. Under normal circumstances, we need to obtain specific data through JNDI. source. We can imagine that in a specific application, if a JNDI query is executed for every SQL request, the system performance will drop sharply. The solution is the following code, which caches the DataSource so that it can continue to be used during the next SQL call:
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;
}
...
...
}
Method 2: Disable servlet and JSP automatic reloading (auto-reloading)
Servlet/JSP provides a practical technology, namely automatic reloading technology, which provides developers with a good development environment without having to restart the application server when you change servlet and JSP pages. However, this technology is a huge loss of system resources during the product running stage, because it will bring a huge burden to the class loader of the JSP engine. Therefore, turning off the automatic reload function is a great help to improve system performance.
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. But unfortunately, because HTTP is inherently stateless, it cannot save the client's state. Therefore, general application servers provide sessions to save the client's state. In the JSP application server, the session function is implemented through the HttpSession object, but while it is convenient, it also brings a lot of burden to the system. Because every time you obtain or update a session, the system operator has to perform time-consuming serialization operations on it. You can improve system performance by handling HttpSession in the following ways:
If it is not necessary, you should turn off the default setting of HttpSession in the JSP page: If you do not specify it explicitly, each JSP page will create an HttpSession by default. If you do not need to use session in your JSP, you can disable it through the following JSP page indicator:
＜%@ page session="false"%＞
Do not store large data objects in HttpSession: If you store large data objects in HttpSession, the application server will serialize it every time it is read or written, thus adding extra burden to the system. . The larger the data object you store in HttpSession, the faster the system performance will decrease.
When you no longer need the HttpSession, release it as soon as possible: When you no longer need the session, you can release it by calling the HttpSession.invalidate() method.
Try to set the session timeout as short as possible: In the JSP application server, there is a default session timeout. When the customer does not perform any operations after this time, the system will automatically release the relevant session from the memory. The larger the timeout is set, the lower the system performance will be, so the best way is to try to keep its value as low as possible.
Method 4: Compress page output
Compression is a good way to solve data redundancy, especially today when network bandwidth is not developed enough. Some browsers support gzip (GNU zip) to compress HTML files. This method can dramatically reduce the download time of HTML files. Therefore, if you compress the HTML page generated by a servlet or JSP page, the user will feel that the page browsing speed will be very fast. Unfortunately, not all browsers support gzip compression, but you can check in your program whether the client's browser supports it. Here is a code snippet of how this method is implemented:
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 the thread pool.
The application server creates a thread for processing each different client request by default, and assigns the service() method to them. When the service() method call is completed, the corresponding thread also Then cancel. Since creating and destroying threads consumes certain system resources, this default mode reduces system performance. 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 will create a thread pool with a number equal to the minimum number of threads. When a customer has a request, a thread is taken out from the pool for processing. When the processing is completed, the thread is put back into the pool. middle. 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 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.
Method 6: Choose the right 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 found that if you use the first method, the system performance can be higher.
Method 7: Correctly determine the life cycle of javabeans
One of the powerful features of JSP is its support for javabeans. By using the <jsp:useBean> tag in the JSP page, javabeans can be inserted directly into a JSP page. Here's how to use it:
＜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 bean life cycle correctly, it will affect the performance of the system.
For example, if you only want to use a certain bean in one request, but you set the bean's life cycle to session, then when the request ends, the bean will still remain in memory unless the session Timeout or user closes browser. This will consume a certain amount of memory and unnecessarily increase the workload of the JVM garbage collector. Therefore, setting the correct life cycle for beans and cleaning them up as soon as possible after their mission is over will improve system performance.
other methods
Try not to use the "+" operator in string concatenation operations: In Java programming, we often use the "+" operator to connect several strings, but you may never have thought that it would actually affect system performance. Have an impact? Since strings are constants, the JVM will generate 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 use a StringBuffer object instead of the "+" operator.
Avoid using the System.out.println() method: Since System.out.println() is a synchronous call, that is, when calling it, the disk I/O operation must wait for its completion, so we should try to avoid using it. call. But it is an indispensable and convenient tool when we debug the program. In order to solve this contradiction, I suggest you use the Log4j tool, which can facilitate debugging without generating System.out.println(). method.
Trade-offs between ServletOutputStream and PrintWriter: Using PrintWriter may bring some small overhead, because it converts all raw output into a character stream for output, so if it is used as page output, the system has to bear a conversion process. There is no problem if you use ServletOutputStream as page output, but it is output in binary. Therefore, the pros and cons of both must be weighed in practical applications.
Summarize
The purpose of this article is to greatly improve the performance of your application through some tuning techniques for servlets and JSP, and thus improve the performance of the entire J2EE application. Through these tuning techniques, you can find that it is not a certain technical platform (such as the dispute between J2EE and .NET) that determines the performance of your application. What is important is that you have a deeper understanding of this platform, so that Only then can you fundamentally optimize your application!