Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Removing Performance Bottlenecks Through JSP Precompilation

Removing Performance Bottlenecks Through JSP Precompilation

Welcome to this edition of "In the Admin Corner," a new monthly column devoted to the administration, configuration, management, and deployment aspects of WebLogic Server.

The goal of this column is to provide you with a closer look at the nondevelopment issues of J2EE that are commonly encountered when working with WLS. Developers and administrators alike will find this column to be of value, as the material applies to both the development and production ends of the application spectrum. Furthermore, this feature draws heavily upon experiences from both the field and the engineering lab, providing detailed answers to real-world problems that go beyond the hand-waving solutions of corridor conversations and whiteboard sessions.

The Need for JSP Precompilation
This month's article looks at removing a potential system performance bottleneck by addressing one of the most common problems that plague nearly all J2EE development projects - the overhead of JavaServer Page (JSP) compilation at server runtime. Although JSPs are the ideal choice for presenting dynamic HTML views within J2EE applications, they do impact performance in a way that, while more annoying than detrimental, initially creates the perception that the application is slow.

According to the J2EE specification, JSPs are primarily HTML files in which embedded Java code is utilized to interact with other system components and present information dynamically. The specification states that all J2EE-compliant application servers supporting JSP, upon a client request for a given JSP, will

  • Convert the JSP from its HTML format into a Java class (in Java source format) of servlet type, substituting out any shorthand JSP notation for fully qualified Java syntax

  • Compile the newly generated Java source into its .class bytecode format

  • Execute the appropriate interface method on the newly compiled class and return the response to the requesting client

    While this is an excellent approach - from a development perspective - for managing dynamic HTML generation within the presentation layer, its impact on the server runtime environment requires a JSP to be parsed, converted to Java code, and compiled before it is executed to handle a given client request. The obvious impact on the end user is that a response will, at minimum, be delayed by the time it takes for the JSP compilation phase to occur for one given JSP file. Take into account the possibility that a given user request may hit two or more JSP files within the same request, and suddenly the time required for the compilation phase is multiplied that many more times.

    For the end user who first hits a given JSP and thus forces the initial compilation of the requested file, the perception is that the application is slow and unresponsive. Although such a perception may exist, the compilation process for a given JSP file is generally done once in the lifespan of a given app server VM instance. Therefore, its overall impact on performance is considered to be a nuisance, rather than a critical roadblock to the overall response time of the application. Nonetheless, production systems that aim to deliver a JSP-based J2EE application in a production environment must overcome the pitfalls of JSP and make compilation transparent to the end user.

    So how can a production environment benefit from the use of JSP files, yet escape the performance hit of runtime compilation? The answer is simple - implement a process commonly referred to as JSP precompilation. With JSP precompilation, JSP files and their compiled equivalents are deployed into a production environment, having already been precompiled in an offline environment. If precompilation and deployment of the resultant class files are done correctly, the application server will execute the previously compiled classes for the JSP files, and will not force a given request to recompile the JSP at runtime. This creates a situation in which the application operates without the unnecessary overhead of compilation, allowing the administrator to remove a perceived bottleneck to the overall performance of the system.

    Different Methodologies and Approaches
    There's no doubt that the promises of JSP precompilation sound exciting. However, in order to fulfill such promises, you must first understand the different approaches that can be taken to implement the technique, and the advantages and disadvantages of each.

    Exercising the Application to Force Precompilation
    The most obvious approach used to implement JSP precompilation is to exercise a given site application by requesting all possible JSP pages in the application before the production release, so compilation is done before end users access the site. This can be done either by manually browsing the entire site for the first time or by launching automated requests from test suite applications or other scripted clients (such as LoadRunner or SilkPerformer). While this approach appears to have the downside of being the simplest of all possible JSP precompilation methods, its disadvantages quickly become apparent. Perhaps the biggest disadvantage here is that it's difficult to implement across clustered environments, where the number of requests once required by this approach for a single node instance are now multiplied by the number of nodes within the cluster. Furthermore, it's even harder to ensure that each server instance within a clustered environment undergoes JSP precompilation when the cluster is proxied by one or more Web servers or hardware load balancers, since there is generally no way of knowing to which app server the proxy will initially forward the request. Additionally, this method must be implemented every time the application server is recycled, making it a painful task that cannot be accomplished for all but the smallest of sites. Therefore, we don't recommend this approach to JSP precompilation.

    Using Compilation Tools to Implement Precompilation
    Since manually exercising a site application to force JSP precompilation has significant disadvantages in real-world production environments, the alternative of compiling the JSPs into servlets during preproduction runtime becomes much more enticing. Fortunately, WLS offers two methods to do this. The first way performs precompilation at server startup during deployment of a given Web application (declarative precompilation), while the second offers a command-line Java tool (weblogic.jspc) to allow the process to be handled completely offline (programmatic precompilation). While both have their advantages, programmatic precompilation is the more flexible option of the two, and offers more compelling reasons to be used.

    Declarative Precompilation
    For declarative precompilation under WLS, a given Web application (standalone or as part of an EAR) can be configured so all of its JSPs are precompiled during application deployment (at server startup) and redeployment (at runtime). The necessary configuration changes are made to the WEB-INF/weblogic.xml deployment descriptor, which uses the precompile <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>

    Upon deployment (or redeployment) of a given Web application, WLS will attempt to precompile all JSP files within the WAR if the above parameter is set to true, recursively working its way down from the root directory of the Web application in the process (and skipping over WEB-INF). Files with either a .jsp or .JSP extension become targets for compilation. Compiled class files are then placed underneath the temporary working directory of the Web application (by default a subdirectory of WEB-INF, unless explicitly specified within weblogic.xml) in the appropriate package directory structure.

    While this method is by far the most convenient approach to JSP precompilation (the "flick-a-switch" approach), it has a number of disadvantages that render it almost useless. If an error occurs during compilation of a JSP at the time of deployment (or redeployment), precompilation of the Web application will halt at the point of the exception. Additionally, in situations where there are a large number of JSP files within a given Web application, declarative precompilation significantly impacts deployment time, blocking the deployment until all of the files have been compiled. For large applications, such deployment times tend to be on the order of minutes (10 to 15 minutes in some cases, potentially even longer in others) when hundreds of JSP files are present and declarative precompilation is implemented. Imagine starting a server instance in which a given Web application cycles into the deployment phase with declarative precompilation enabled. If there are a large number of JSP files within the app, and the deployment, nearing completion and having already taken a significant amount of time, suddenly fails because an exception is thrown during compilation, frustration will surely ensue. While convenient at first look, declarative compilation poses a significant risk to production system management and should be utilized only with great consideration.

    Programmatic Precompilation
    The most reliable way to precompile JSP files under WLS is to use the Java command-line utility, weblogic.jspc, located in the weblogic.jar file under the lib directory of the WLS installation. This tool allows a developer to compile the desired JSP files during the development phase and iron out compile-time issues before deployment. It also provides an administrator with the ability to implement JSP precompilation for production systems. The major benefits of this utility are:

  • Files can be precompiled once and then deployed multiple times. (This isn't affected by the recycling of a server instance.)

  • Compile-time exceptions can be worked out in advance without affecting deployment.

  • Classes can be deployed across a cluster.

    The drawbacks are that using weblogic.jspc requires manual intervention and that it must be rerun when JSP files become out-of-date in development. However, given the issues with the other two methods discussed above, we hardly find this inconvenience to be a disadvantage, and recommend it as the most reliable and flexible mechanism to implement JSP precompilation.

    Executing weblogic.jspc
    In order to use weblogic.jspc effectively, you must first understand its usage and syntax. For this article, we will utilize the features of the tool from WLS 6.1 SP2. Note: The syntax and best practices given below should apply to all versions of WLS 6.1 and in part to the new WLS 7.0.

    To invoke the command-line JSP compiler (weblogic.jspc), you must ensure the following:

  • The PATH environment variable must include the binary directory of the J2SE 1.3. package installed on your machine for JVM runtime support (e.g., /opt/j2se/1.3.1/sdk/bin or c:\sunsoft\j2se\1.3.1\sdk\bin). If you plan on using javac as your Java compiler for JSP compilation, be sure your PATH includes the binary directory of the full Java 1.3 software development kit (SDK), and not simply the Java Runtime Engine (JRE), as no compiler is shipped with the JRE. If you plan on using a compiler other than javac (such as Jikes), be sure to include the appropriate directories within the PATH for that compiler as well.

  • Set the Java system classpath to include the weblogic.jar file from the WLS 6.1 SP2 installation directory, by default found under the product library directory (e.g., /opt/bea/wlserver6.1/lib/weblogic.jar, or c:\bea\wlserver6.1\lib\weblogic.jar). Additionally, be sure to reference any libraries (JAR or class files) that you might need from the classpath during the JSP compilation stage.

    Before executing weblogic.jspc for the first time, it's a good idea to quickly test your command-line configuration as set above. This can be achieved by simply running a version check of WLS with the command, "java weblogic.version", 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 isn't similar to the above (appropriate to the version you are running), be sure to revisit the PATH and classpath variables set within your current command-line environment before proceeding with JSP precompilation.

    The general syntax of weblogic.jspc is given below:

    java weblogic.jspc [options] <jsp files>...

    The JSP compiler can by default compile a single JSP file or a set of JSPs in a single invocation of the compiler, and can be configured in a number of different ways via command-line options. A working example is provided:

    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 shows a single example, but so you may better understand how weblogic.jspc can be used and managed in your environment, we provide the complete set of working options, implications of use, and associated issues at www.slackwerks.com/wldj.

    Conclusion
    While the argument for JSP precompilation can easily be made, there are a number of approaches that can be taken to implement it. However, given the advantages and disadvantages of those shown above, it should be readily apparent that programmatic precompilation via weblogic.jspc provides the most flexible option for overcoming the pitfalls inherent to JSP. Becoming familiar with the tool early in the development cycle will improve the administration and performance aspects of the application during production.

  • More Stories By Steve Mueller

    Steve Mueller is a principal
    consultant for BEA Systems, where he specializes in the design,
    development, and administration of enterprise systems running on WebLogic Server.

    More Stories By Scot Weber

    Scot Weber consults on J2EE design, development, and administration, specifically focusing on WebLogic Server. He has been involved as a lead architect and systems engineer in the field of distributed applications, and has participated in and witnessed the maturation of traditional OLTP, RPC, and messaging methodologies into their current J2EE manifestations

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
    René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
    Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
    Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
    If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
    When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
    Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
    Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...