17.3.2 Controlling the number of concurrent executions of a Web application

(1) Difference in the control of number of concurrently executed threads

The difference in the control of the number of concurrently executed threads in the case of each Web container, Web application and URL group is explained below:

Web container

You can set the number of threads for simultaneous processing of requests in the entire Web container.

Web application

You can set the number of threads for simultaneous processing of requests for each Web application running in the Web container.

URL group

You can set the number of threads for simultaneous processing of requests for each process of distribution destination URL, when a request is distributed to a URL corresponding to the specific business process (business logic) in the Web application.

The figure below illustrates the relationship between concurrently executed threads of each Web container, Web application, and URL group.

Figure 17‒1: Relationship between concurrently executed threads of each Web container, Web application, and URL group

Important note

Control of the maximum number of threads to be concurrently executed for each Web container is enabled only when the control of the number of threads to be concurrently executed for each Web application is disabled.

When control of the number of threads to be concurrently executed for each Web application is enabled, the maximum number of threads to be concurrently executed for each Web container is checked by the control of the number of threads to be concurrently executed for each Web application. For details, see the manual uCosminexus Application Server Web Container Functionality Guide.

The execution of requests for a Web application is controlled by the number of concurrently executed threads set in each Web container, Web application, and URL group. A request that exceeds the number of concurrently executed threads that are set in each Web container, Web application, and URL group enters the respective pending queue.

To Page Top

(2) Guidelines for selection

The guidelines for selecting the unit of control for concurrently executed threads are explained below:

For details about the functionality for controlling the number of concurrently executed threads, see 2.13 Overview of control over the number of concurrently executed threads in the uCosminexus Application Server Web Container Functionality Guide.

• Guidelines for selecting a Web application

  The J2EE server can manage not only the TCP connection requests but also the pending queue of the Web applications by controlling the number of concurrently executed threads of the Web application. Therefore, Hitachi recommends setting a number of concurrently executed threads of a Web application even when a single Web application is running on the J2EE server.

  Setting the number of concurrently executed threads in the Web application has the following advantages as compared to the setting of the number concurrently executed threads in each Web container:

  • Setting the maximum number of concurrently executed threads for each Web application will prevent the Web application with a large number of requests, corresponding to a particular business, from using the processing efficiency of the entire Web container. As a result, the other businesses can also be executed without any delay.

  • If there are several Web applications with different loads required for CPU and I/O processing, you can set the number of concurrently executed threads according to the conditions of respective Web applications.

  • As the size of the pending queue for requests can be set for each Web application separately, it is possible to control the pending queue according to the features of the Web application. In addition, if the requests exceeding the pending queue size of each Web application are sent, it can be communicated to the client using the HTTP response code.

  The number of concurrently executed threads of each Web application can be dynamically changed in the running J2EE server. For details about the procedure for dynamically changing the number of concurrently executed threads of Web applications executed on running J2EE servers, see 2.17.2 Flow of dynamically changing the number of concurrently executed threads in the uCosminexus Application Server Web Container Functionality Guide.

• Guidelines for selecting a URL group

  If concurrently executed threads are controlled in a Web application, control the concurrently executed threads in a URL group if you want to further control the concurrently executed threads in business logic.

  Determine the settings of a URL group to include the following business logic in the Web application:

  • Business logic that you want to prioritize and execute without being influenced by other processes

  • Business logic where the CPU and I/O load is high or the required processing time is more as compared to other processes

  Setting the concurrently executed threads in a URL group has the following advantages as compared to setting only in a Web application.

  • The threads that need to be executed are allocated to the business logic (URL group) with a high priority. Even when the requests for another business logic increase, you can execute the business logic with a high priority instead of assigning the concurrently executed threads of the entire Web application to the business logic with more requests.

  • Setting the upper limit for concurrently executed threads of business logic (URL group) that require more processing time makes it possible to prevent a particular business logic from using up the concurrently executed threads of the entire Web application.

  • If a Web application has several business logics (URL groups) with CPU and I/O having different loads, you can set the number of concurrently executed threads according to the business logic.

  • Setting the queue size (pending queue size) for the request of each business logic (URL group) in the Web application allows the controlling of the pending queue according to the features of the business logic. If the pending queue of each URL group exceeds the upper limit, the same is notified to the client by using the HTTP response code 503 (Service Temporarily Unavailable).

To Page Top