Server Requests

This section describes in more detail the data flow through a user application and the points at which the APMCS system gathers information. This description will help you better understand the concept of a Server Request, how to use the APMCS REST API and how to analyze the data returned from this API to gather performance metrics.

Data flows through an application via some sort of invocation. An invocation is the act of one entity causing some other entity to begin execution. The entity that initiates the invocation is the caller and the entity that begins executing the is the callee. Within APMCS the only entities that participate in invocations are Operations and End-user Actions (for example, a link on web page). The caller of an invocation can be either an End-user Action or an Operation, while the callee is always an Operation. An invocation has additional characteristics that determine its type:

  • Is the invocation synchronous or asynchronous? In a synchronous invocation, the caller will wait for the callee to finish executing before proceeding with the rest of its own execution. In an asynchronous invocation, the caller does not wait for the callee to finish executing before proceeding with the rest of its own execution.
  • Is the invocation between entities in the same application server or does the invocation cross application boundaries?

Server Request, Agent and Flow

A Server Request is a sequence of synchronous invocations in a single application server that returns some set of information. A server request is identified by its starting root operation and represents a series of synchronous invocations occurring in a single application server, along with the outbound invocations leaving the application server or those starting asynchronous invocations. A server request always starts with a single root operation. That root operation itself may have been called by a user interaction (from a web page), or by another server request. The invocation nodes of a single server request are those reachable from the root operation, stopping at, and containing, any node that is the root of some other server request.

A Server Agent probe tracks measurements of invocations, assigns those measurements to request types and then aggregates the measurements. The measurements made are: counting occurrences, counting faulty occurrences, and various time based measurements. These measurements are aggregated in various ways over some time interval and the aggregated measurements are considered the measurements of the server request, its operations and links.

A connected set of server requests may make up a single Flow. This is true as long as context can be propagated across all the requests. When the two sides of an invocation are made on behalf of different cloud tenants then there is no relationship between the two sides of the invocation and no context will be propagated.

In the following example the flow of a single server request starts at service A operation op1. The flow continues into operation op2 in the same service. Then it passes via a synchronous call into another service B in another application server. In service B the flow passes through operations op1, op2 and op3. Whenever possible flow context is passed between services and operations. At any point in the flow the server request caller operation will be the starting operation A.op1, even though, for example for B.op3, the immediate caller operation will be B.op2, Operation A.op2 also makes an asynhronous call into service C. An asynchronous call will start a new server request; thus, in the following figure there are two server requests, the second one starting at operation C.op1:

Figure - Service Request Flow

Service Request Flow

Query and JSON Response

The following is an example of a REST API query to retrieve the server requests within a specific time range:
/api/v1/requests?since=2015-11-25T22:00:00.000Z&until=2015-12-04T10:25:00.000Z&orderBy=averageResponseTime:desc
The JSON response to the REST API query will list the following information:
  • Containing application server identifying information such as the application server name and ports.
  • System context information such as the host server name, deployment name and the type of APMCS agent injected into the application server to gather information.
  • Links to common related resources such as time series data, operations, application servers and callers.
  • Operation identity information such as the operation name and the genre, such as JAXRPC.
  • Metric information pertaining to this server request, such as total and average times, success and failure counts, load rates and error percentages.
  • The server request ID. This ID may be used as a parameter in other opertaions to drill deeper into the server request. For more information about the ID and how to use it, see Object ID Parameters.
  • Control information, such as whether this is the start of a flow and whether this request contains caller information. This information may be used together with the server request ID to track back through the request flow.
The actual JSON response object will look something like the following:
{
  "returnedItemCount" : 1000,
  "items" : [ {
    "appServerName" : "BookmartServer",                 *** Application server identifying information
    "appServerPort" : 5678,
    "appServerSslPort" : 56789,
    "appServerPortsList" : null,
    "appserverVersionId" : 3701668,
    "appServerAdminHost" : "admin",
    "appServerAdminPort" : 9999,
    "links" : [ {                                       *** Links to common related resources
          "rel" : "self",
          "href" : "api/v1/requests/3701696?since=2015-11-25T22:00:00.000Z&until=2015-12-04T10:25:00.000Z"
        }, {
          "rel" : "timeSeries",
          "href" : "api/v1/requests/3701696/timeSeries?since=2015-11-25T22:00:00.000Z&until=2015-12-04T10:25:00.000Z"
        }, {
          "rel" : "instances",
          "href" : "api/v1/requests/3701696/instances?since=2015-11-25T22:00:00.000Z&until=2015-12-04T10:25:00.000Z"
        }, {
          "rel" : "operationLinks",
          "href" : "api/v1/requests/3701696/operationLinks?since=2015-11-25T22:00:00.000Z&until=2015-12-04T10:25:00.000Z"
        }, {
          "rel" : "appServerDetails",
          "href" : "api/v1/appservers/3701668?since=2015-11-25T22:00:00.000Z&until=2015-12-04T10:25:00.000Z"
        }, {
          "rel" : "operationType",
          "href" : "api/v1/operations/3701696"
        }, {
          "rel" : "serverRequestCallers",
          "href" : "api/v1/requests/3701696/serverRequestCallers?since=2015-11-25T22:00:00.000Z&until=2015-12-04T10:25:00.000Z"
        } ],
    "requestId" : 3701696,                              *** ID of this server request
    "serverName" : "hostCd48.dev.corpDom",              *** Host and system context information
    "deploymentName" : "BookmartApp.war",          
    "agentName" : "Observation Generator Agent",
    "operationName" : "OrderService.submit",            *** Operation information
    "operationGenre" : "JAXRPC",
    "maxResponseTime" : 59947,                          *** Metric information
    "minResponseTime" : 47,
    "totalResponseTime" : 26134944,
    "averageResponseTime" : 29071.13,
    "maxSelfTime" : 59947,
    "minSelfTime" : 47,
    "totalSelfTime" : 26134944,
    "averageSelfTime" : 29071.13,
    "maxAppServerTime" : 59947,
    "minAppServerTime" : 47,
    "totalAppServerTime" : 26134944,
    "averageAppServerTime" : 29071.13,
    "maxDatabaseTime" : 0,
    "minDatabaseTime" : 0,
    "totalDatabaseTime" : 0,
    "averageDatabaseTime" : 0,
    "maxExternalTime" : 0,
    "minExternalTime" : 0,
    "totalExternalTime" : 0,
    "averageExternalTime" : 0,
    "completedCount" : 899,
    "failureCount" : 0,
    "loadRate" : 0.07,
    "errorPercentage" : 0,
    "hasCallerInfo" : true,                             *** Control information
    "isFlowStart" : false,
    "meId" : "SR_o4/MHP2dc3YlFVDaqfyww8us1qw="
  }
  ...
}