 |
|
|
 首页 |
名片设计 CorelDRAW Illustrator AuotoCAD Painter 其他软件 Photoshop Fireworks Flash |
|
JSP预编译的必要性 本月的文章着眼于移除潜在的系统性能瓶颈，它通过解决一个最普通的问题?D?D在服务器运行时间中的JSP (JavaServer Page)编译的系统开销问题，这个问题困扰着几乎所有的J2EE发展计划。虽然JSP是在J2EE应用范围内呈现动态HTML视图的理想选择，但在某种程度上它们会影响性能，这比错误的更令人讨厌，给人的第一感觉是该程序很慢。 根据J2EE规范，JSP主要是HTML文件，在它里面包含着Java代码用来和其他的系统组件进行交互以及动态的显示信息。规范规定所有的J2EE编译应用服务器应当支持JSP，客户哀求一个特定的JSP，将： ● 转变JSP从HTML格式成为servlet类型的Java类（Java源格式），用简写的JSP符号代替完全符合规定的Java语法 ● 将新产生的Java源文件编译成.class字节码形式 ● 在新编译的类上执行适当的接口方式并且对客户端哀求返回响应。 虽然从发展的观点来看对于在表示层内治理动态HTML的产生这是最好的途径，但它影响到服务器的运行时间环境，要求JSP被解析、转换成Java代码，并且在它去处理一个特定的客户端哀求之前被编译。对最终用户明显的影响是，一个响应将会被延迟知道给定的JSP文件被编译通过。考虑到一个特定的用户哀求可能用到两个或多个JSP文件，因此编译状态必需的时间增加了很多倍。 对第一个哀求一个特定的JSP页面并且迫使被哀求的文件进行初始编译的终端用户，会感觉应用程序很慢并且没有响应。 虽然这样的感觉可能存在，但是对于特定的JSP文件的编译过程通常在给定的应用服务器虚拟机实例的生命周期中完成一次。 因此，它对性能总体上的影响被考虑成一种障碍，而不是对应用程序总响应时间的一个严峻的障碍。然而，在生产环境中为了传送基于JSP的J2EE应用程序的生产系统，必须克服JSP的缺陷并且对最终用户进行透明的编译。 这样，生产环境如何能受益于JSP文件，还要避免运行时编译的性能打击？答案是简朴的：执行一个一般作为JSP预编译的过程。 借用JSP预编译，已经被预编译的在脱机环境中的JSP文件和他们的编译结果被部署在生产环境中。假如结果类文件的预编译和部署准确的完成，应用程序服务器将会为JSP文件运行先前的编译类，并且在运行中将不强制对特定的哀求进行再编译。 这样产生了一种情况，应用程序的操作避免了多余的编译开销，答应系统治理员移除对系统总性能会造成影响的一个已知的瓶颈。 不同的方式论和途径 没有人怀疑JSP预编译的承诺听起来令人高兴。 然而，为了要实现这样的承诺，你必须首先了解能够执行这个技术的不同途径，以及它们各自长处和缺点。 运行应用程序进行强制预编译 用于实现JSP预编译最显而易见的方式是在产品发布前，通过哀求在应用程序中的所有可能的JSP页面，因此编译在终端用户访问站点前完成。它既可以通过第一次人工浏览整个站点时完成也可以通过从测试系列应用程序或其他脚本语言的客户端（例如LoadRunner 或 SilkPerformer）发动自动哀求来实现。 当使用这种方式（可能是所有的JSP预编译方式中的最简朴的而又较下策的一个方式）时，他的缺点很快就显现出来了。也许最大的缺点是很难实现跨集群环境，在集群环境中，用该方式对于单一节点的实例发送的哀求依集群中的节点数量成倍的增加。而且，当这个集群是由一个或更多的Web服务器或硬件负载权衡者来代理时，更难保证在一个集群的环境中每个服务器实例都进行JSP预编译，因为一般没有方式来搞清代理最初把哀求转到哪个应用服务器。此外，在应用服务器每次重启时，这个方式必须执行，当站点很小时，不能一次实现所有的编译就会很痛苦。因此，我们不推荐这种JSP预编译的方式。 使用编译工具来实现预编译 因为人工执行一个站点应用程序来强制JSP预编译在真实的产品环境中是一个较大的缺点，在预编译运行期间选择编译JSP，使其变成为servlets变得更令人心动。幸运地，WLS提供了二个方式。第一种方式在服务器启动部署一个特定的Web应用程序的时候执行预编译（declarative预编译），第二种方式是命令行Java工具（weblogic.jspc）答应过程在完全脱机的情况下处理（程序方法的预编译）。两种方式都有它们的长处，程序方法的预编译在两者中有更灵活的选项，并且提供更让人无法抗拒的理由来使用它。 DECLARATIVE预编译 对于在WLS下宣布的预编译，一个特定的Web应用程序（独立的或者作为EAR的一部分）能够被配置，因此所有的JSP在应用程序部署（服务器启动时）和重新部署（运行时）期间里被预编译。对WEB-INF/ weblogic.xml部署描述符要做必要的配置变化，使用预编译<jsp-param/>指令，如下： <weblogic-web-app> … <jsp-descriptor> <jsp-param> <param-name>precompile</param-name> <param-value>true</param-value> </jsp-param> </jsp-descriptor> … </weblogic-web-app> 在一个特定的Web应用程序上进行部署（或重新部署），假如上述的参数被设定成真， WLS 将会在WAR内尝试预编译所有的JSP文件，在程序中从 Web 应用程序的根目录下循环的运行它的方式( 略过Web-INF) 。以. jsp 或 .JSP为扩展名的文件都变成了编译的对象。 被编译后的文件被以适当的包目录结构形式被放置在Web 应用程序的临时工作目录下面（默认在Web-INF子目录中，除非在 weblogic.xml 里有特殊说明）。 这个方式是到目前为止进行JSP预编译最方便的途径（“flick-a-switch” 途径），他有许多指出来毫无意义的缺点。假如一个错误在JSP的编译期间或在部署(或重新部署) 的时候发生，Web 应用程序的预编译将会在例外处暂停。另外，假如在一个特定的Web应用程序里面有许多JSP文件的情况，declarative预编译显著的影响着部署时间，阻断部署直到所有的文件都被编译。对于大型的应用程序，当出现数以百计的JSP 文件以declarative预编译被执行的时候，这种部署时间趋向以分钟来计算 (在某些情况10到15分钟，其他情况可能更长时间)。设想开始一个服务器实例，在一个特定的Web应用程序周期内进入部署状态用declarative 预编译激活。假如在应用内有很多的JSP文件以及部署，接近完成时就已经花费了大量的时间，在编译期间由于抛出一个例外而忽然失败，当然会引起挫折感。虽然起先看起来比较方便，但declarative 编译对生产系统治理造成重大的风险，因此应该在经过慎重的考虑后再使用它。 程序方法的预编译 在WLS下最可靠的预编译JSP的方式是使用Java命令行，weblogic.jspc，它位于WLS安装的lib目录之下的weblogic.jar文件中。这个工具答应开发者在发展阶段和在部署前解决编译时间问题的时候编译需要的JSP文件。它也为生产系统提供一个有能力实现JSP预编译的治理员。这种用法的主要好处是： ● 文件可以被预编译一次然后可以被多次部署。（这不被服务器实例的重复利用所影响） ● 编译时的例外可以被预先解决而不影响部署。 ● 类可以通过集群部署。 使用weblogic.jspc的缺点是需要人工干涉，并且它在开发时并当在JSP文件变得过时的时候必须被重新运行。然而，考虑到前面的两个方式的讨论，我们几乎不能将这种不方便当成该方式的一个缺点，因此推荐它作为最可靠和最灵活的机制来实现JSP预编译。 执行weblogic.jspc 为了更有效的使用weblogic.jspc，你必须首先了解它的用法和语法。这篇文章我们将利用WLS6.1 SP2的工具的功能。注重：下面给出的语法和最好的惯例应该应用于WLS 6.1的所有版本以及新的WLS 7.0。 为了调用命令行JSP编译器（weblogic.jspc），你必须确定下面的内容： ● PATH环境变量必须包含你机器上安装的J2SE1.3包的二进制目录（例如，/opt/j2se/1.3.1/sdk/bin 或者c:sunsoftj2se1.3.1sdkbin），以获得JVM运行时的支持。假如你打算使用javac作为你的JSP编译的Java编译器，要确定PATH包含全部Java 1.3 的软件开发工具包（SDK）的二进制目录，并且不仅仅是JRE（Java Runtime Engine，Java运行时间引擎），因为没有编译器和JRE关联。 假如你打算使用一个编译器而不是javac（例如 Jikes），也要为那个编译器确定在PATH中包含准确的目录。 ● 设置Java系统类路径用来包含来自WLS 6.1 SP2 安装目录的weblogic.jar文件，通过在产品库目录下默认建立（例如，/opt/bea/wlserver6.1/lib/weblogic.jar或者c:beawlserv -er6.1libweblogic.jar）。此外，请确定在JSP编译阶段中你可能需要的参考类（JAR或类文件）也在你的类路径中。 在第一次执行weblogic.jspc之前，你需要测试你的命令行配置是否是按上述配置。它可以通过简朴运行一个WLS版本检查来完成，使用命令“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 假如你的输出和上面的不相似（和你运行的版本相对应），在进行JSP预编译前，要重新访问PATH和类路径变量将其设置成你的当前命令行环境。 一般的weblogic.jspc的语法如下面给出的： java weblogic.jspc [options] <jsp files>... 在一个编译器的单一调用中默认情况下JSP编译器可以编译一个JSP文件或一组JSP文件，并且可以通过设置命令行选项，编译器可以以不同的方式工作。下面给出一个例子： 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 mywebappindex.jsp 这篇文章只列举了一个例子，假如你要想更加了解weblogic.jspc如何能在你的环境中使用和治理的话，请参阅www.slackwerks.com/wldj，我们提供了对整套的工作选项，使用的含义以及相关联问题的讨论。 结论 虽然关于JSP预编译的问题较多，但许多的途径可以解决。然而，考虑到上文所说的那些长处和缺点，应该较轻易的看出经由weblogic.jspc预编译的程序方法是为克服JSP固有的缺点的一个灵活的选项。在开发阶段的早期，认识该工具将改善生产期间应用程序的治理和性能状况。 返回类别: 教程 上一教程: JAVA在CLIENT/SERVER网络中的应用 下一教程: 用XMLHTTP和JAVA SESSION监听改善站内消息系统 您可以阅读与"通过JSP的预编译消除性能瓶颈"相关的教程: · SERVLET、JSP性能优化 · 使用JMeter测试JSP应用程序性能 · JSP 2.1技术规范投票通过 表达式语言有所改进 · 通过JSP实现对数据的批量更新 · 用缓冲技术提高JSP程序的性能和稳定性 |
  |
| 快精灵印艺坊 版权所有 |
首页 会员中心在线印刷在线编辑付款方式索取样品设计指南连锁门店
|
||
