Eliminating performance bottlenecks through JSP precompilation

The necessity of JSP pre-compiling

This article looks at removing the potential system performance bottleneck by solving one of the most common problems. The problem with the system overhead of JSP (JavaServer Page) compilation in Server run time, which puzzles almost all of the Java EE development plans. While JSP is the ideal choice for rendering Dynamic HTML views in the context of Java EE applications, they affect performance in a way that is more annoying than the wrong one, giving the first impression that the program is slow.

According to the Java EE specification, JSP is mainly an HTML file, in which the bread contains Java code to interact with other system components and dynamic display information. The specification stipulates that all the Java EE Application Server should support JSP, the customer requests a specific JSP, will:

Convert JSP to a servlet-type Java class (Java source format) from HTML format, replacing a fully compliant Java syntax with a shorthand JSP symbol

Compiles the newly generated Java source file into a. Class byte code form

Executes the appropriate interface method on the newly compiled class and returns a response to the client request.

Although from a development standpoint this is the best way to manage the creation of dynamic HTML within the presentation layer, it affects the server's run-time environment, requiring that the JSP be parsed, transformed into Java code, and compiled before it can handle a particular client request. The obvious effect on the end user is that a response will be delayed knowing that the given JSP file is compiled. Considering that a particular user request might use two or more JSP files, the time required to compile the state has increased many times.

End users, who first request a particular JSP page and force the requested file to be initially compiled, feel that the application is slow and unresponsive. Although such feelings may exist, the compilation process for a particular JSP file is typically done once in the life cycle of a given application server virtual machine instance. As a result, its overall performance impact is considered an impediment rather than a serious impediment to the overall application response time. However, in order to deliver a JSP-based Java EE application production system in a production environment, it is necessary to overcome the JSP defect and transparently compile the end user.

In this way, how can the production environment benefit from the JSP file, but also to avoid run-time compilation performance hit? The answer is simple: Perform a process that is generally precompiled as a JSP. Using JSP precompilation, the JSP files that have been precompiled in the offline environment and their compilation results are deployed in the production environment. If the precompiled and deployment of the resulting class file is completed correctly, the application server will run the previous compilation class for the JSP file, and the specific request will not be forced to recompile in operation. This creates a situation where the operation of the application avoids redundant compilation overhead and allows the system administrator to remove a known bottleneck that affects the overall performance of the system.

Different methodologies and approaches

No one doubts that the promise of JSP precompilation sounds exciting. However, in order to achieve such a commitment, you must first understand the different ways in which the technology can be implemented, as well as their respective strengths and weaknesses.

To run the application for forced precompilation

The most obvious way to implement JSP precompilation is to request all possible JSP pages in the application before the product is released, so the compilation is done before the end user accesses the site. It can be done either through the first manual browsing of the entire site or by launching an automatic request from a client (such as LoadRunner or Silkperformer) from a Test series application or other scripting language. When using this method, which may be the simplest and most unwise method of all JSP precompilation methods, his shortcomings quickly emerge. Perhaps the biggest drawback is that it is difficult to achieve a cross cluster environment, in which the request for a single node instance is multiplied by the number of nodes in the cluster. Furthermore, when the cluster is represented by one or more Web servers or hardware load tradeoffs, it is harder to ensure that each server instance is precompiled in a clustered environment because there is generally no way to figure out which application server The agent initially transferred the request to. In addition, when the application server restarts each time, this method must be performed, when the site is very small, it is not possible to implement all the compilation at once is painful. Therefore, we do not recommend this method of JSP precompilation.

Using the compilation tool to achieve precompilation

Because manually executing a site application to force JSP precompilation is a major disadvantage in a real-world product environment, you can choose to compile the JSP during the precompiled run to make it more exciting for servlets. Luckily, WLS offers two methods. The first method performs precompilation (declarative) when the server starts deploying a particular Web application, and the second method is that the command-line Java tool (WEBLOGIC.JSPC) allows the process to be processed completely offline (precompilation of the program). Both methods have their advantages, and the precompilation of the program approach has more flexibility in both options and provides a more compelling reason to use it.