Elimination of performance bottlenecks through pre-compilation of JSP

js| Compilation | performance

Welcome to the "Management Corner" edition, the new Monthly column focuses on the management, configuration, processing, and development of WebLogic servers.

The purpose of this column is to introduce the problem of non-Java development that can be commonly used when using WebLogic sever. Developers and managers will also find this column valuable as they apply both to development and to the application of the final product. In addition, it has largely taken advantage of experience from the field and the Engineering laboratory, which provides detailed answers to practical questions.

The necessity of JSP pre-compiling

This month's article looks at removing potential system performance bottlenecks by addressing one of the most common problems-the overhead of JSP (JavaServer Page) compilation at server run time, which plagues 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.

declarative Pre- compiling

For precompilation published under WLS, a particular Web application (either standalone or as part of the ear) can be configured so that all JSPs are precompiled during application Deployment (server startup) and redeployment (runtime). For the Web-inf/weblogic.xml deployment descriptor to make the necessary configuration changes, use the precompiled <jsp-param/> directive as follows:

<weblogic-web-app>
...
<jsp-descriptor>
<jsp-param>
<param-name>precompile</param-name>
<param-value>true</param-value>
</jsp-param>
</jsp-descriptor>
...
</weblogic-web-app>

To deploy (or redeploy) on a particular Web application, if the above parameters are set to True, WLS will attempt to precompile all JSP files in the war, in which the method of running it from the root directory of the Web application (skip Web-inf). To. JSP or. The JSP file for the extension becomes the compiled object. The compiled files are placed under the temporary working directory of the Web application in the appropriate package directory structure (default in the Web-inf subdirectory unless specifically described in Weblogic.xml).

This approach is the easiest way to do JSP precompilation so far (the "flick-a-switch" approach), and he has many points to the point of meaningless flaws. If an error occurs during the compilation of a JSP or when it is deployed (or redeployed), the precompilation of the WEB application will be paused at the exception. In addition, if there are many JSP files in a particular Web application, declarative precompilation significantly affects deployment time, blocking deployment until all files are compiled. For large applications, when hundreds of JSP files appear to be executed with declarative precompilation, this deployment time tends to be measured in minutes (in some cases 10-15 minutes, others may be longer). Imagine starting a server instance, going into the deployment state within a specific Web application cycle, using declarative precompilation activation. If there are a lot of JSP files in the application and deployment, close to completion has spent a lot of time, during the compilation of an exception to throw a sudden failure, of course, will cause frustration. While it may seem convenient at first, declarative compilation poses a significant risk to production system management and should be used after careful consideration.

Pre-compiling of program mode

The most reliable way to precompile a JSP under WLS is to use the Java command line, WEBLOGIC.JSPC, located in Weblogic.jar file under WLS installed Lib directory. This tool allows developers to compile the required JSP files during the development phase and when resolving compile-time issues before deployment. It also provides an administrator with the ability to implement JSP precompilation for production systems. The main benefits of this usage are:

Files can be precompiled once and can be deployed multiple times. (This is not affected by the reuse of the server instance)

Compile-time exceptions can be resolved in advance without affecting deployment.

Classes can be deployed through clusters.

The disadvantage of using WEBLOGIC.JSPC is that it requires manual intervention, and it is developed and must be rerun when the JSP file becomes obsolete. However, given the discussion of the previous two methods, we can hardly regard this inconvenience as a disadvantage of the method, so it is recommended as the most reliable and flexible mechanism to implement JSP precompilation.

Execute WEBLOGIC.JSPC

In order to use WEBLOGIC.JSPC more effectively, you must first understand its usage and syntax. In this article we will take advantage of the functionality of the WLS6.1 SP2 tool. Note: The syntax and best practices given below should be applied to all versions of WLS 6.1 and to the new WLS 7.0.

In order to invoke the command line JSP compiler (WEBLOGIC.JSPC), you must determine the following:

The PATH environment variable must contain a binary directory of the j2se1.3 package installed on your machine (for example,/opt/j2se/1.3.1/sdk/bin or c:\sunsoft\j2se\1.3.1\sdk\bin) to obtain support for the JVM runtime. If you plan to use Javac as your JSP compiled Java compiler, make sure that path contains a binary directory of all Java 1.3 software Development Kits (SDK), and not only the JRE (Java Runtime Engine,java runtime engine), Because there are no compilers associated with the JRE. If you plan to use a compiler instead of javac (for example, Jikes), be sure to include the correct directory in the path for that compiler.

Set the Java system classpath to contain Weblogic.jar files from the WLS 6.1 SP2 installation directory, created by default in the Product library directory (for example,/opt/bea/wlserver6.1/lib/weblogic.jar or c:\bea\ Wlserv-er6.1\lib\weblogic.jar). Also, make sure that the reference class (Jar or class file) you may need in the JSP compilation phase is in your classpath as well.

Before you perform WEBLOGIC.JSPC for the first time, you need to test that your command-line configuration is configured as described above. It can be done by simply running a WLS version check and using the command "Java weblogic.version", which should return the following:

Which should return the following:
WebLogic Server 6.1 SP2 12/18/2001 11:13:46
#154529
WebLogic XML Module 6.1 SP2 12/18/2001
11:28:02 #154529

If your output is not the same as the one above (corresponds to the version you are running), re-access the path and CLASSPATH variables and set it to your current command-line environment before you precompile the JSP.

The general WEBLOGIC.JSPC syntax is given below:

Java WEBLOGIC.JSPC [options] <jsp files> ....

In a single invocation of a compiler, the JSP compiler can compile a JSP file or a set of JSP files by default, and the compiler can work in different ways by setting command-line options. An example is given below:

Java
Weblogic.jspc
-webapp MyWebApp
-compiler Javac
-compileflags "-G"
-classpath/u/apps/dist/src/lib.jar
-D.
-package com.slackwerks.mywebapp.jsp
-commentary
-keepgenerated
-K
mywebapp\index.jsp

This article only cites an example, if you want to know more about how WEBLOGIC.JSPC can be used and managed in your environment, see WWW.SLACKWERKS.COM/WLDJ, we provide a discussion of the full set of work options, the meaning of use, and related issues.

Conclusion

Although there are many problems about JSP precompilation, a lot of ways can be solved. However, given the advantages and disadvantages mentioned above, it should be easier to see how the program via WEBLOGIC.JSPC is a flexible option to overcome the inherent drawbacks of JSP. Early in the development phase, familiarity with the tool will improve the management and performance of applications during production.