Programmatically determining an execution mode for a request dispatch utilizing historic metrics

Abstract

A request dispatcher can automatically switch between processing request dispatches (e.g., include( )) in a synchronous mode and an asynchronous mode. Each dispatch can be associated with a unique identification value such as a process ID or Uniform Resource Identifier (URI), historic metrics, and a ruleset. With each execution of the request dispatch, historic metrics can be collected. Metrics can include, but is not limited to, execution duration and / or execution frequency, processor load, memory usage, network input / output, number of dependent dispatches, and the like. Utilizing historic metrics, rules can be constructed for determining which mode to execute the subsequent execution of the dispatch. As such, runtime optimization of Web applications can be further improved.

Description

BACKGROUND[0001]The disclosure relates to the field of middleware and, more particularly, to programmatically determining an execution mode for a request dispatch utilizing historic metrics.[0002]When an application server processes executable code, such as a Web application (e.g., JAVA Servlet or a JAVA SERVER PAGE), there can be one or more request dispatches present within the Web application. These request dispatches are typically denoted by an include( ) function call specifying a resource to execute, such as another servlet or JAVA SERVER PAGE (JSP). The specified resource can be executed in one of two modes, asynchronously or synchronously. Synchronous execution often results in the executable code blocking (e.g., suspended) until the specified resource execution is complete, a situation which in many instances is unfavorable. Further, the resource can include additional request dispatches, which can execute other resources resulting in an execution chain that frequently intr...

AI Technical Summary

Benefits of technology

[0006]Another embodiment of the disclosure can include a system for dispatching a request. The system can include a dispatch engine able to identify and execute a request dispatch associated with a first executable code. The dispatch engine can be a component of a transport channel chain within a runtime environment. The transport channel chain can be associated with a transport layer of an Open System Interconnect (OSI) layer model. The runtime environment can be any environment supporting an inclusion of resources. For example and in one embodiment, the runtime environment can be a JAVA 2 ENTERPRISE EDITION (J2EE) runtime environment. The system can also include a request dispatch associated with the first executable code. The request dispatch can be associated with a unique identification value. The unique identification value can identify a unique resource to be executed. The request dispatch can trigger the execution of the unique resource. The unique resource can include a second executable code. The system can also include at least one performance metric that is associated with the request dispatch. The performance metric can be automatically collected during the request dispatch execution. The performance metric can be utilized to modify the execution behavior of the request dispatch. A ruleset can exist that is configured to establish at least one of a threshold value, an execution mode, and an event handler associated with the request dispatch. The threshold value can be a user established setting or an automatically determined value. The execution mode can be a synchronous execution mode or an asynchronous execution mode. The synchronous execution mode can result in the first executable code executing sequentially with the second executable code, where the second executable code is not permitted to execute until the first executable code completes its execution. The asynchronous execution mode can result in the first and second executable code running simultaneously.

Problems solved by technology

Synchronous execution often results in the executable code blocking (e.g., suspended) until the specified resource execution is complete, a situation which in many instances is unfavorable.

Further, the resource can include additional request dispatches, which can execute other resources resulting in an execution chain that frequently introduces significant latency to the Web application.

As such, several disadvantages can arise as a result of this latency, which can include unresponsive applications and / or excessive server load.

However, asynchronous execution introduces overhead, such as establishing a new thread, placing markers in the output, and replacing markers for server or client side aggregation.

In many instances, this overhead can compound latency which can significantly reduce performance gains offered by asynchronous execution.

For instance, synchronous execution of a resource can result in 10 ms latency, where executing the same resource asynchronously can result in 20 ms latency due to the overhead introduced by the asynchronous execution (e.g., thread setup costs).

Further, in dynamic server environments, synchronous and asynchronous resource execution can have varying results due to changes in resource availability.

Often times, these guesses do not result in the most optimal application performance.

As such, many server environments executing Web applications can suffer from inefficient resource usage and reduced server capability which can unduly burden an information technology (IT) infrastructure.

Images