iWiz ShareBase

IT Specialist 윤태현의 iWiz ShareBase는 IT뿐 아니라 각종 잡다한 지식들을 함께 나누는 지식공유 커뮤니티입니다.

iWiz,ShareBase,윤태현,Java,JSP,EJB,IT,정보기술,웹프로그래밍,PHP,ASP,DBMS,MySQL,서버,네트워크,server,network,WAS,웹애플리케이션,블로그,blog,웹서버,DB,오라클,oracle,mysql,JRun,웹로직,톰캣,tomcat,아파치,자동차,EF쏘나타,로또 6/45

갤러리 Pixelgrapher.com | 로또 6/45 번호생성 및 통계 데이터 | 전체기사보기 | 전체글 #1 | 전체글 #2 | 전체글 #3 | 전체글 #4 | 전체글 #5 | 전체글 #6 | 전체글 #7 | 전체글 #8 | 전체글 #9 | 전체글 #10 |
HOME iWiz
ShareBase
Remember 0523 & 0818
지식은 나눌수록 커집니다 - iWiz's ShareBase
웹프로그래밍(기타) PHP, ASP, Perl, CGI 등 각종 웹프로그래밍에 관한 자료들입니다.


  iWiz(2004-01-04 22:39:32, Hit : 9445, Vote : 31
 http://www.wz.pe.kr

Optimizing JSPs


Optimizing JSPs

This section presents some ideas for improving the responsiveness of your JSPs.

Since JSPs are compiled into servlets when they are first requested, look at the optimization techniques for servlets for additional ideas. For more information, see "Optimizing servlets".

Precompiling JSPs

Unlike servlets, which are compiled before deployment, JSP pages are compiled by JRun the first time they are requested. This can cause an apparent lag, which can appear to some users as slow responsiveness. JRun provides the option of precompiling the JSPs.

The JSPC compiler is a command-line tool that you use to compile JSPs outside the context of a web server. With the JSPC compiler, you can explicitly compile JSPs from a command line, rather than use JRun to compile them upon a request of the JSP. JSPC uses the IBM jikes compiler if it is located in the jrun_root/bin directory. Otherwise, it uses the Sun javac compiler.

When precompiling JSPs, it is also a good idea to disable JRun's autodetection of changes to those files. For more information, see "Disabling change detection".

Note:   The JSPC compiler is the same compiler that JRun uses to compile JSPs. The only difference is that you invoke the JSPC compiler from a command line.

For more information on using the JSPC compiler, see the JRun Assembly and Deployment Guide.

Disabling change detection

By default, JRun cycles through web component files (like servlets and JSPs) to detect if the files have changed since the last cycle. This process is what makes hot deployment and autodetecting changes work. However, this cycling also degrades performance and should be disabled in a production environment. It is especially unnecessary if you precompile your JSPs, as described in "Precompiling JSPs".

To disable the autodetection of changes for JSPs, set the JSPServlet's translationDisabled initialization parameter in the default-web.xml file to true, as the following example shows:

<servlet>
   <servlet-name>JSPServlet</servlet-name>
   <servlet-class>jrun.jsp.JSPServlet</servlet-class>
   <load-on-startup>1</load-on-startup>
   <init-param>
     <param-name>keepGenerated</param-name>
     <param-value>false</param-value>
   </init-param>
   <init-param>
     <param-name>translationDisabled</param-name>
     <param-value>true</param-value>
   </init-param>  
 </servlet>

Caching static data in the ServletContext object

The ServletContext object stores objects as attributes. By caching objects, such as hashtables or other structures, you reduce the processing load of your application.

The implicit application object in a JSP represents the ServletContext for that JSP. You do not have to execute a method to get the ServletContext as you do in servlets. For example, the following code sets an attribute to the ServletContext object in a JSP:

application.setAttribute("statelist", qt);

If you use the jrun:sql tag in the JRun Tag Library to get a QueryTable, you can store the QueryTable object as an application attribute. You do not have to convert the ResultSet to a Hashtable or other serializable object.

The ServletContext object behaves the same with JSPs as it does with servlets. For more information, see "Caching static data in the ServletContext object".

Disabling sessions

Every time a JSP is requested, JRun creates an HttpSession object to maintain state for each unique client. The session data is accessible in the JSP as the implicit session object. In JSPs, sessions are enabled by default.

Each session object uses up a small amount of system resources, because it is stored on the server. In addition, traffic between the client and server must include the session ID when sessions are enabled. This adds a small amount of overhead.

Use the page directive to disable sessions. Set the session attribute of the page directive to false, as shown in the following example:

<%@ page session="false" %>

Increasing response object's buffer

Increase the size of the response object's buffer to reduce socket creation.

The default size of the JSP response buffer is 8kb. JRun flushes the buffer whenever the response size reaches at least this size. Set the buffer to a larger value to reduce the number of flushes necessary, as shown in the following example:

<%@ page buffer="16kb" %>

The page directive applies to an entire JSP page and any of its included files.

To check the size of the buffer, use the getBufferSize method of the implicit response object, as shown in the following example:

Buffer size is <%= response.getBufferSize() %>

Using includes correctly

Whenever possible, use the include directive rather than the include action when including static pages. The include directive inserts the contents of the included file at compile time (in the case of JSPs, the first time the page is requested), whereas the include action fetches the included file during runtime (every time the page is requested). The latter requires more processing on the server side.

For example, if you have a static file, header.html, include the file using the include directive, as shown in the following example:

<%@ include file="/static-pages/header.html" %>

Do not include the static file with an include action, as shown in the following example:

<jsp:include page="/static-pages/header.html" flush="true" />

While Server-Side Includes (SSI) and includes perform the same tasks, do not use SSI taglets in your JSPs. JRun no longer supports SSIs.

Not flushing output

In previous versions of JRun (and any servlet engine that adhered to the earlier specifications), you were required to flush the buffer output after an include action. The required flush attribute of the include action had to be set to true. In JRun 4, the attribute defaults to false and is optional. By setting the attribute to false, you can delay the flushing of the output buffer. Depending on your page size, this can improve the performance of your JSPs.

The following code line shows setting the flush attribute to false in an include action:

<jsp:include page="myadditionalpage.jsp" flush="false" /> 

Using the setProperty shortcut

JavaBeans store state information or other data used by JSPs. Processing form variables and storing each of the input fields as a bean property can be tedious, difficult to update, and prone to errors.

The following is a typical setProperty tag that sets the form field to a JavaBean property:

<jsp:setProperty name="myBean" property="first_name" value="<%= request.getParameter("first_name") %>" />

JSPs provide a shortcut that lets you set all the bean properties with one tag.

Set property attribute to * so that the jsp:setProperty tag iterates over all the request parameters and matches parameter names and value type to bean property names and types. Each matched property is set to the value of the matching parameter. You do not specify the value parameter in the setProperty tag.

The following is an example of using the property wildcard:

<jsp:setProperty name="myBean" property="*" />

If you set the parameter value to an empty string (""), the corresponding property is not modified. If the request parameter does not have a corresponding bean property, it is ignored.

Caching static data in jspInit

JRun calls the jspInit method once when a client first requests the JSP. It is only called again if the JSP source code changes or if you restart the JRun server. The jspInit method is the equivalent of a servlet's init method.

You can override the jspInit method of a JSP and store static data in it. A common example is constructing and initializing a database connection pool. Other tasks can also be handled in the jspInit method, such as retrieving application-scoped initialization parameters.

The following code sample shows a JSP page that gets an initialization parameter in the jspInit method and later uses it in the body:

<%!
 String email;
 public void jspInit() {
  System.out.println("in jspInit()");
  javax.servlet.ServletConfig servletConfig = getServletConfig();
  email = servletConfig.getServletContext().getInitParameter("email");
}
%>
<HTML><BODY>
Email addy is: <%= email %>
</BODY></HTML>

You define the initialization parameter in the context-param block of the web.xml file, as shown in the following example:

<web-app>
...
<context-param>
 <param-name>email</param-name>
 <param-value>webmaster@macromedia.com</param-value>
</context-param>
...
</web-app>

Using application-scoped beans for caching

Setting the scope of a bean to application indicates to JRun that there should only be one instance of the bean for the current application.

For example, if you select a list of states and their abbreviations from a database and store the results as properties in an application-scoped bean, you are not required to query the database every time you want to look up the full state name.

As a result, JRun only executes one database query until you restart the server. Any JSP that has access to the bean can now get at the properties of the bean, as shown in the following example:

<jsp:usebean id="statelist" class="jrunsamples.optimize.StateList" scope="application" />
<jsp:setProperty name="statelist" property="*" />

To access a state that is one of the bean's properties, use the following line:

<jsp:getProperty name="statelist" property="MA" />

You can also change the scope of a bean to session, page, or request. If you set a bean's scope to session, you must not override sessions=true in the page directive.

* iWiz님에 의해서 게시물 이동되었습니다 (2010-02-03 16:57)



62   mod_throttle 모듈을 이용한 사용자 트래픽 제어  iWiz 2006/06/22 9063 0
61   Tomcat-Apache using JK2 connector  iWiz 2004/03/21 7799 41
60   RedHat 9.0에서의 JRun JSP 컴파일러의 문제점  iWiz 2004/01/04 5553 50
59   RedHat 9.0에서의 JRun-Apache 커넥터의 문제점  iWiz 2004/01/04 5187 48
58   JRun 4.0의 튜닝 관련 옵션  iWiz 2004/01/04 5945 68
57   JRun 4.0의 Activity 모니터링 방법  iWiz 2004/01/04 4921 57
56   JRun4.0: DataSource 커넥션풀 관련 옵션 [4]  iWiz 2004/01/04 6664 46
55   JRun에서 JSP 컴파일시 java 파일 생성하기  iWiz 2004/01/04 8068 63
54   JRun의 실제 서비스 운영시 고려사항  iWiz 2004/01/04 6373 44
53   수정된 인터넷 익스플로러에서 상호작용 ActiveX 컨트롤 활성화 가이드  iWiz 2006/03/03 8457 4
52   HTML 특수기호 엔터티(Entity) 테이블 [2]  iWiz 2006/03/03 14183 2
51   웹사이트의 새로운 혁명 Ajax [13]  iWiz 2005/11/22 5870 6
50   MSN 메신저 친구 자동등록 스크립트  iWiz 2004/10/12 6192 35
49   JavaScript MD5 해쉬 생성 함수  iWiz 2004/01/07 9080 35
48   JavaScript로 만든 진법변환 및 보수계산기 [4]  iWiz 2004/01/04 160610 51

1 [2][3][4][5]
 

Copyright 1999-2023 Zeroboard / skin by zero
iWiz ShareBase, ⓒCopyleft by iWiz.  For more information contact .
본 웹사이트에 게시된 이메일 주소가 전자우편 수집 프로그램이나 그 밖의 기술적 장치를 이용하여 무단으로 수집되는 것을 거부하며, 이를 위반시에는 정보통신망법에 의해 형사처벌됨을 유념하시기 바랍니다. [게시일 2004. 1. 31]