8.7.1 Separating the deployment of the static contents and the Web application

From the files that are used for responding to the requests from the client such as HTML file and image file, the contents that remain the same and do not change according to the contents of the request are called static contents. On the other hand, the contents that are dynamically generated according to the requests from the client, such as servlets and JSPs, are called dynamic contents.

The following section explains how to enhance the performance by separating and deploying the static contents and Web applications that are the dynamic contents. The setup method is different when you integrate with a Web server, and when you use an in-process HTTP server.

Each example of setup is explained on the basis of an example of displaying an HTML page consisting of frames and inline images, as shown in the following figure, in the web browser:

Figure 8-16 Example of HTML page consisting of static and dynamic contents

[Figure]

In the above configuration, the following files form the static contents that are not generated dynamically:

Organization of this subsection
(1) For Web server integration
(2) When using an in-process HTTP server

(1) For Web server integration

If the static contents are embedded in the Web application, there is access between the redirector and the Web container even when exchanging static contents that need not be processed in the Web container. In the case of image files, the processing time takes longer due to the large data size.

Hitachi recommends that the static contents be segregated from the Web application and deployed on the Web server. This helps to reduce the frequency of network access and the size of exchanged data that in turn will enhance the performance. The following figure shows an image of the processing of the static contents and the Web application:

Figure 8-17 Image of static contents and Web application processing

[Figure]

The method of deploying the static contents that have been segregated from the Web application is explained below using the HTML page configuration that is shown in Figure 8-16.

In case of Figure 8-16, the performance is enhanced by deploying the following static contents on the Web server:

Contents deployed on the Web server
  • Style sheet (such as a CSS file)
  • Inline image (image file)
  • HTML file that defines frames

The following figure shows an example of deployment:

Figure 8-18 Deploying the static contents on the Web server (in the case of Web server integration)

[Figure]

Define the above mapping as shown below. For details, see 9. File used in Web Server Integration in the uCosminexus Application Server Definition Reference Guide.

When Cosminexus HTTP Server is used as the Web server (mod_jk.conf)

#
JkMount /APP/* worker1
# JkMount /* worker1
If # is used, /images/ on the Web server cannot be referred.

When Microsoft IIS is used as the Web server (uriworkermap.properties)

#
/APP/*=worker1
# /*=worker1
If # is used, /images/ on the Web server cannot be referred.

Note
During the Web server integration, instead of allocating all Web application files to the Web server, allocate only the static contents that are directly accessed from the client.
[Figure]
If the request extension and the path information cannot be read correctly in the redirector, a request for dynamic contents might be incorrectly considered to be the request for static contents. In this case, the redirector sends the Web server contents to the client as it is, without distributing the processing to J2EE server. If dynamic contents, such as servlets and JSPs, are allocated to a Web server, and if a request for dynamic contents is handled as a request for static contents, the source of the contents, such as the class file entities and JSPs, might be sent as a response to the request source client.

(2) When using an in-process HTTP server

When transferring the same contents to the client at all times such as the static contents, even when you use an in-process HTTP server, if you process the static contents on Web server besides the in-process HTTP server and Web container, the performance will improve. Particularly when handling large amount of data with a heavy file size, such as an image file, Hitachi recommends that a Web server be deployed specifically for processing the static contents, instead of embedding the data in Web applications.

To extract static contents from Web applications, and then handle them, a reverse proxy server or load balancer is to be deployed at the front-end. In such a case, depending on the reverse proxy server or load balancer, distribute the process as given below:

The following figure shows an image of the distributed process. This figure is an example of distribution of the process by the reverse proxy server.

Figure 8-19 Image showing the distribution of dynamic and static contents by the reverse proxy server

[Figure]

The method of deploying the static contents that are separated from a Web application is explained below using the HTML page configuration that is shown in Figure 8-16.

In case of Figure 8-16, the performance is enhanced by deploying the following static contents on the Web server:

Contents deployed on the Web server
  • Style sheet (such as a CSS file)
  • Inline image (image file)
  • HTML file that defines frames

The following figure shows an example of deployment:

Figure 8-20 Deploying the static contents on the Web server (to use an in-process HTTP server)

[Figure]

To distribute the process in the above manner, describe the following reverse proxy definition in the ProxyPass directive of the configuration file (httpsd.conf) of Cosminexus HTTP Server.

For details, see the uCosminexus Application Server HTTP Server User Guide.

Reverse proxy definition

ProxyPass /APP/ http://inprocweb/APP/
ProxyPass /images/ http://websvr/images/
ProxyPass /css/ http://websvr/css/