Coordinate Servlet and JSP operations-improve the running performance of your enterprise applications by adjusting Servlet and JSP

Coordination between Servlet and JSP
-- Adjust Servlet and JSP to improve the running performance of your enterprise
By Rahul Chaudhary Introduction
In this article, Rahul Chaudhary describes the performance coordination Technology (performance-tuning techniques) that can improve Servlet and JSP performance ), therefore, you can use it to improve the performance of your J2EE application. The author believes that readers of this article should have basic Servlet and JSP knowledge.
 
Is your J2EE application running slowly?
Can they support increasing traffic volumes?
This article describes the performance-tuning Technology (PTT) proposed to develop high-performance and large-scale Servlet and JSP applications ). This technology enables us to develop such an application: It runs fast and can maintain this speed from the beginning, more importantly, it can greatly increase the number of users or requests of the application. In this article, I will lead you to practice and prove that the performance-tuning technology can greatly promote the performance of your Servlet and JSP, so as to improve your J2EE application. Some of these technologies are used in the development stage, such as the design or coding stage, and some are related to the configuration.
 
Ptt1: Use the init () method of httpservlet to cache data
The Web server calls the init () method after the server creates a servlet instance, and before the servlet processes all requests. In the lifecycle of a servlet, it is called only once. The init () method can be used to improve performance by caching static data or completing costly actions that need to be executed during initialization.
For example, using JDBC (Java database connectivity) connection pools is a proven method. These connection pools generally include a javax. SQL. datasource interface. Datasource is obtained through the jdni (Java Naming and Directory Interface) tree. For each SQL call, running jdni to obtain datasource is expensive and can have a significant impact on the system performance. Servlet's Init () method can be used to obtain datasource and cached for later use.
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 ;}} Ptt2: Disable auto-reloading of Servlet and JSP
The auto-Reloading attribute of Servlet/JSP is proved to be very useful in the development phase because it reduces the development time. You do not need to restart the server every time you change the servlet or JSP. However, it is extremely expensive in the practical stage. The auto-reloading of Servlet/JSP is extremely inefficient due to the necessary loading or bearing of classloader. In addition, when the specific classloader of some classes cannot coordinate with the classloader used by the current class, your application system will have a strange conflict. Therefore, turning off the auto-reloading of Servlet/JSP in the working environment will achieve good performance.
 
Ptt3: Controls httpsession
Many systems require a series of client requests so that they can be associated with other systems. At this time, Web-based applications need to maintain a state, which becomes a session, because the HTTP protocol is stateless. To support the State that must be maintained by the system, java servlet provides APIs to manage sessions and allows session implementation through several mechanisms. All the functions of sessions are represented by the httpsession object, but it has an expensive cost. When an httpsession object is updated, it will be read whether it is used or rewritten. You can improve the performance by using the following technologies :. Do not generate httpsession in the default status of the JSP page: by default, the JSP page generates httpsession. If you do not use httpsession on JSP pages, to save some performance overhead, use the following command to Prevent Automatic Generation of httpsession when the JSP pages are not mandatory:
<% @ Page session = "false" %>. Do not store large object curves or charts in httpsession: if the data is stored in httpsession, the application server has to process the entire httpsession object every time. This will force Java serialization and increase computing costs. . When httpsession is used up, release the httpsession object: Use the httpsession. invalidate () method to release the httpsession, when they are no longer needed. . Set the time-out value of the session: the servlet engine has a default time-out value. If you do not delete httpsession or use it to reach the time set by time-out, the servlet engine will delete this object from the memory. The larger the time to set time-out, the greater the impact on testability and performance, because of the memory and garbage collection overhead. Try to minimize the time-out time of sessions.
 
Ptt4: gzip Compression
Compression is a method that removes unnecessary information and uses the smallest space to save the data you need. For hmtl files, using gzip (GNU zip) to compress files can greatly reduce the download time. The smaller your information size, the faster it will be sent. Therefore, if you compress the content produced by your web application, it will be uploaded to the user quickly and displayed to the user more quickly. Not all browsers support gzip compression, but you can easily check whether a browser supports gzip and then send gzip compressed content to those browsers that support gzip compression.
The following is a code snippet to demonstrate how to send compressed content if the browser can receive it:
Public void doget (httpservletrequest request, httpservletresponse response) throws ioexception, servletexception {outputstream out = NULL // check the accepting-encoding header from the HTTP request. // If the header contains des gzip, choose gzip. // If the header already des compress, choose zip. // otherwise choose no compression. string encoding = request. getheader ("Accept-encoding"); If (encoding! = NULL & encoding. indexof ("gzip ")! =-1) {response. setheader ("content-encoding", "gzip"); out = new gzipoutputstream (response. getoutputstream ();} else if (encoding! = NULL & encoding. indexof ("compress ")! =-1) {response. setheader ("content-encoding", "compress"); out = new zipoutputstream (response. getoutputstream ();} else {out = response. getoutputstream ();}}
 
 
Ptt5: Do not use singlethreadmodel
Singlethreadmodel allows the servlet to process only one request at a time. If a servlet implements this interface, the servlet engine generates an independent servlet instance for each new request. This results in overhead on the number of system objects. If you want to solve the thread security issues, use other methods instead of implementing the siglethreadmodel interface. The siglethreadmodel interface has been deprecated in servlet2.4.
 
Ptt6: Use thread pool
The servlet engine generates an independent thread for each request. These threads are allocated to the Service () method. After the service () method is executed, these threads are deleted. By default, the servlet engine generates a thread for each request. These default behaviors reduce the system performance because the overhead of generating and deleting threads is expensive. These performance can be improved by using the thread pool. You can configure a thread pool by predicting the number of users who concurrently access the system and setting the maximum and minimum number of users in the pool. At startup, the servlet engine generates a thread pool, which has the smallest number of threads you have configured. Then, the servlet engine allocates threads from the pool to each request, instead of generating a thread for each request. After the thread is used, the thread is returned to the thread pool. With the thread pool, the system performance can be thoroughly improved. If needed, you can add more threads based on the minimum number of threads.
 
 
Ptt7: select the correct include Mechanism
On the JSP page, there are two methods for us to introduce a file: Include reference (<% @ include file = "test. JSP "%>) and include actions (<JSP: Include page =" test. JSP "Flush =" true "/> ). Include references introduce detailed file content in the conversion phase, that is, the page is converted to servlet. The include action introduces the file content in the request processing stage, that is, when the user requests the page, the include reference is faster than the include action. Therefore, unless the referenced files change frequently, using include references can provide a good performance.
 
 
Ptt8: use the correct range when using usebean actions
A powerful weapon to use JSP pages is to use them together with the JavaBean Component. With the tag <JSP: usebean>, JavaBean can be directly embedded into the JSP page. The syntax is as follows:
<JSP: usebean id = "name" Scope = "Page | request | session | application" class = package. classname "type =" typename "> </jsp: usebean>
The scope attribute specifies the range of JavaBean visibility. The default value is page. You can select an appropriate value based on your application needs. Otherwise, it will affect the performance of your system.
For example, if you only need an object as a special request, but your scope is set to session, the object will always exist, and your request has ended for a long time. It will stay in the memory until you delete it explicitly, or make the session invalid, or the session has already timed out according to the timeout value you set in the servlet engine. If you do not select the scope value correctly, it will affect the performance because of memory and garbage collection overhead. Therefore, we need to select the correct scope value and delete the objects immediately after they are used.
 
 
Compound Technology
. Avoid string join. Using the "+" operator to connect strings produces many temporary objects, because the string object is a constant. The more you use "+", the more temporary objects are generated, which greatly reduces system performance. Use stringbuffer instead of "+" when you need to connect many strings. . Avoid using system. Out. println: system. Out. println to synchronize disk I/O systems, which significantly reduces input output. Try to avoid using system. Out. println, even if this weird debug tool is available. Sometimes, system. Out. println is useful for tracking purposes, printing errors, or debuging. You should configure system. Out. println so that it is only valid in the case of error and debuging. To achieve this, a Boolean variable is used. When the Boolean variable is false, the out variable is optimized to make it effective during the compilation phase detection and tracking. . Servletoutputstream for printwriter: using the latter will cause a small overhead, because it means the character output stream and the data is encoded as bytecode. Therefore, printwriter can ensure that all characters are correctly converted. On the other hand, when you use servletoutputstream, your servlet only returns binary code, so you can reduce the overhead of character conversion because the servlet container does not encode binary code.
 
 
Conclusion
The purpose of this article is to show you some practical and proven performance coordination technologies that will greatly promote the servlet/jsp performance, this improves the performance of the entire system. In the next step, we will discuss other related technologies such as EJB (Enterprise JavaBeans), JMS (Java Message Service), and JDBC (Java database connectivity) Performance coordination technologies.