Runtimes

What are Runtimes?

Runtimes are individual instances that are running as part of a typical API Management deployment setup. The API management setup comprises various products such as API Gateway, Developer Portal, and Microgateway. Each product can be deployed as single node or clustered for high availability. Irrespective of the number of nodes, a complete deployment of each product represents one runtime. These runtimes can be deployed in varying landscapes such as multi-region, multi-cloud, hybrid environments, and so on.

Assume that John Doe Enterprises makes use of the AWS and Azure versions of the Software AG Cloud platform. It has runtimes scattered in three different regions -in the United States, Europe, and Australia as shown in the figure. There are three staging runtime environments for each region, including development, pre-production, and production. These existing runtimes in varying landscape are added to the API Control Plane. After these runtimes are added, API Control Plane captures the details of all the nine runtimes in the landscape. API Control Plane offers the ability to manage and monitor all the nine runtimes and the specifics of the associated assets in a single UI without logging into individual runtimes.

Manage Runtimes

The Manage runtimes page lists the runtimes in API Control Plane.

The runtimes get auto populated in API Control Plane when the connectivity between runtimes and API Control Plane is established. To establish connectivity from API Gateway (On premise) to API Control Plane, see Configuring API Control Plane section in API Gateway Administration guide. To establish connectivity from webMethods.io API Gateway (Cloud) to API Control Plane, see Configuring API Control Plane. To connect any third-party gateways with API Control Plane, see Agent SDK.

As shown in the following figure, the highlighted areas on the Manage runtimes page allow you to customize the rows and columns of the runtime list, add, search, filter, view, edit, and delete the runtime.

Editing a runtime

Runtimes are automatically populated in API Control Plane when the runtime establishes connectivity with API Control Plane. The API Control Plane agent, embedded in each runtime, starts sending data to API Control Plane, with the information received from each runtime. For details about how to establish a connection between runtimes and API Control Plane, see Connecting webMethods.io API Gateway to API Control Plane section in API Gateway Administration guide. For details about how to establish a connection between runtimes and API Control Plane using SDK see Agent SDK.As a user, you might want to customize the runtimes based on the project requirements, like adding additional tag names, modifying the deployment type, changing the location, and so on.

API Control Plane allows you to modify the auto-populated runtime details of runtimes.

Before you begin:

Ensure that you are assigned to the API platform providers user group to perform this task.

To edit a runtime

  1. Click the Runtimes tab.
    The Manage runtimes page appears.

  2. Click Action menu > Edit on any runtime.
    The Edit page appears, displaying the Step 1 Basic Details section.

  3. Edit the following details as required:

    • Name*. Name is mandatory.
    • Description.
    • Upload the file in the Icon drop area using one of the following method:

      • Drag and drop the files
      • Click Browse files and select the file

      If the file is not uploaded, API Control Plane uses the Default icon.

      Note
      Make sure the file size does not exceed 1 MB. Also, make sure the file you upload is in the svg, jpeg, jpg, or png format.
  4. Click Next.
    The Step 2 Tags section appears.

  5. Edit the following details as required:

    • Tags. Tag name of the runtime.
    • Type *. Runtime type. API Gateway is selected as the default. This field is disabled when you edit a runtime.
    • Deployment type *. The runtime deployment type. Permitted values are On premises, Software AG Cloud, and Private cloud.
    • Host. Specify the host name. This field accepts valid URLs, hostnames, and IPv4 and IPv6 address formats.
    • Capacity. The approximate estimate of the throughput that a runtime can handle. You can configure the Capacity value with any non-negative integer and for any duration which can be in the following units:

      • per second
      • per minute
      • per hour
      • per day
      • per week
      • per month
      • per year

      A data plane’s total capacity is the sum of all of its separate runtime capacities. The aggregate capacity value is displayed on the dashboard and the monitoring screens.

      If the Capacity value is not set or set to 0, the used capacity of the runtime in the Dashboard’s Capacity widget is displayed as 0. For more information on Capacity, see Capacity.

      Note
      • In case of API Gateway, the capacity value is loaded from API Gateway agent when it estabilishes the connection with API Control Plane.
      • You can modify the capacity value loaded from API Gateway agent. When API Gateway agent restarts, the modified capacity value is overwritten.
  6. Click Next.
    The Step 3 Location section appears.

  7. Edit the following details as required.

    • Region. Region of the runtime. For example, AWS-US
    • Location. Location of the runtime. For example, Oregon
  8. Click Save.
    The runtime details are modified and saved.

Deleting a runtime

API Control Plane allows you to delete the runtimes and the APIs associated with the runtimes in API Control Plane. The data planes will no longer be associated with the runtime when you delete a runtime that is linked to multiple data planes.

Before you begin:

To delete a runtime

  1. Click the Runtimes tab.
    The Manage runtimes page appears.

  2. Click Action menu > Delete on the runtime that you want to delete.
    The Delete runtime confirmation window appears.

  3. Click Yes, delete runtime.
    The runtime and the APIs associated with it are deleted.

    Note
    You can also delete a runtime using a REST endpoint. For more information on the delete runtime REST endpoint, see Administration APIs. Deleting a user removes the user information and can not be retrieved through audit logs.

Viewing the APIs associated with a runtime

To manage and monitor the APIs across runtimes efficiently, API Control Plane gives a consolidated view of the APIs associated with a specific runtime.

Before you begin

Ensure that you are assigned to the API platform providers, API product managers, or API Control Plane administrators user group to perform this task.

To view the APIs associated with a runtime

  1. Click the Runtimes tab.
    A list of all the available runtimes in API Control Plane appears.

  2. Click Action menu > Details on any runtime.
    The runtime details page appears.

  3. Click APIs.
    A list of all the APIs associated with the runtime appears.

Next steps

Monitor Runtimes

Monitor runtime enables you to monitor and track the key performance indicators of the runtimes. It helps you to make informed business decisions by analyzing the performance metrics of the runtimes.

API Control Plane lets you to monitor the runtimes in following ways:

Before you begin

Ensure that you have the API platform providers or the API product managers user group assigned to perform this task.

Monitoring all runtimes

API Control Plane provides you with the ability to oversee the performance of all runtimes in a unified view. This consolidated perspective allows you to pinpoint the highest and lowest performing runtimes, facilitating data-driven business decisions.

To monitor all the runtimes in the landscape

  1. Click the Runtimes tab.
    The Manage runtimes page appears.

  2. Click the Monitor icon in the top right corner of the page.

    By default, the Monitor runtimes page renders the metrics of all the runtimes pertaining to last 1 hour. If you want to render the metrics for a different time range, select the predefined or custom time range from the Time Range drop-down menu (that appears in the top right corner of the page) based on your requirement and click the Apply button.

    Note
    Since webMethods.io Developer Portal does not send performance metrics to API Control Plane, only the Status and Availability widgets are applicable for Developer Portal runtime type. Therefore, data is populated only in these two widgets. If API Control Plane contains only Developer Portal runtime type and no other runtime types, only the Status and Availability widgets will be rendered on the Monitor runtimes page; the remaining widgets will not be displayed.
Widgets in detail

The widgets in the Monitor runtimes page are explained in detail as follows:

Status, performance & used capacity

This widget provides a comprehensive view of all runtimes by displaying their status, performance, and used capacity.

Status
The status of runtime indicates the health of the runtime. It is determined based on the availability of the runtime. The status of the runtime can be one of the following:

Status Description
Green indicates that the runtime’s availability is 100%.
Amber indicates that the runtime’s availability is greater than 99% and lesser than 100%.
Red indicates that runtime’s availability is less than 99%.
Grey indicates that there is no adequate data to compute the availability of runtimes. For example, if you register a runtime an hour ago and try to view the dashboard by applying the default Last 1 hour time range, the status appears grey due to the lack of available data during that time period.

How to determine the availability of the runtime?

The availability is determined based on the sum of the heartbeat status value of the runtime. If API Control Plane:

The frequency at which the runtime must send the heartbeat status to API Control Plane is defined in the API Control Plane Agent configuration. For details about how to configure the API Control Plane Agent, see Connecting webMethods.io API Gateway to API Control Plane section in API Gateway Administration guide. For details about how to develop agent using SDK, see Agent SDK. .

For example, if the heartbeat interval is defined as 60 seconds in the API Control Plane agent configuration, then for an hour, the expected heartbeat status value must be 3600.

Availability of a runtime=i=1n(Actual heartbeat value of the runtime in the time stamp i)i=1n(Expected heartbeat value of the runtime in the time stamp i)×100\text{Availability of a runtime} = \frac{\displaystyle\sum_{i=1}^{n}\left(\text{Actual heartbeat value of the runtime in the time stamp }i\right)}{\displaystyle\sum_{i=1}^{n}\left(\text{Expected heartbeat value of the runtime in the time stamp }i\right)}\times 100

Example:

Let’s determine the availability of the runtime A for 4 hours based on the following metrics. Let’s assume:

Time stamp Sum of actual heartbeat value received Sum of expected heartbeat value
1st one hour 1800 3600
2nd one hour 3600 3600
3rd one hour 1200 3600
4th one hour 3600 3600

Availability of the runtime A for 4 hours=(1800+3600+1200+36003600+3600+3600+3600)100=70.83%\text{Availability of the runtime A for 4 hours} = (\frac{1800+3600+1200+3600}{3600+3600+3600+3600})*100 = 70.83\%

The status of the runtime is displayed as red.

Note
If you have changed the runtime’s heartbeat status frequency in the API Control Plane Agent configuration, then the actual and expected heartbeat value is calculated based on the updated heartbeat status frequency.

Performance
Performance shows how good each runtime is performing based on two metrics - error rate and latency. The threshold for the latency and error rate are set based on the user preference. For details about setting the performance threshold, see Change threshold settings. For details about how to determine the error rate and latency, see Error rate, Latency.

The performance status of the runtime can be one of the following:

Performance status Description
Green indicates that both latency and error rate threshold values are within the acceptable limit.
Amber indicates that either latency or error rate threshold value is within warning limit or above the unacceptable limit.
Red indicates that both latency and error rate threshold values are within warning limit or above the unacceptable limit.
Grey indicates that there is no adequate data to compute the performance of the runtimes in the data plane.
For example, if you register a runtime an hour ago and you try to view the dashboard by applying the default Last 1 hour time range, the status appears as grey due to the lack of available data during that time period.

Used capacity
Capacity displays the used capacity rate of the runtime. Capacity is the number of transactions that a runtime can handle. The used capacity status of the runtime can be one of the following:

Used capacity status Description
Green indicates that the capacity rate is lesser than or equal to 30%
Amber indicates that the capacity rate is greater than 30% and lesser than or equal to 70%
Red indicates that the capacity rate is greater than 70%
Grey indicates one of the following:
  • there is no adequate data to compute the capacity rate. For example, if you register a runtime an hour ago and try to view the dashboard by applying the default Last 1 hour time range, the status appears grey due to the lack of available data during that time period.
  • the capacity is not defined for all runtimes in the data plane.

How to determine the used capacity of the runtime?

Used capacity of the runtime=(Actual TPS of the runtimeExpected TPS of the runtime)100\text{Used capacity of the runtime} = (\frac{\text{Actual TPS of the runtime}} {\text{Expected TPS of the runtime}})*100

Example: Let’s see how to determine the used capacity of a runtime. Assume that you have defined the capacity as 10000 transactions per hour for runtime A. For more details about how to define the capacity of a runtime, see Editing a runtime.

The expected TPS of the runtime A = 100001hr60min60secs=2.77\frac{10000}{1hr * 60 min * 60secs} = 2.77 transactions per second.

Let’s assume that runtime A has performed 39000 transactions in the last 6 hours.

The actual TPS of the runtime A = 390006hrs60min60secs=1.81\frac{39000}{6hrs * 60 min * 60secs} = 1.81 transactions per second.

Used Capacity of the runtime A =(1.812.77)100=65%(\frac{1.81}{2.77})*100 = 65\%

The capacity of the runtime A is displayed as 65% in amber.




Problematic runtimes by

This widget helps identify issues across runtimes by analyzing total transaction volumes, error rate, response time, and latency of all associated runtimes. Choose a business metric to view its corresponding least and most problematic runtime. The runtime split and line graph display runtime in a sequence from the most problematic to the least.

For details about how to determine the error rate, response time, latency, and transactions, see Error rate, Response Time, Latency, and Transactions.



Transactions

This widget provides a comprehensive overview of total transaction volumes across all runtimes with a trend percentage, along with detailed insights into the top-performing and under-performing runtimes to help you make informed business decisions. It presents both pictorial and graphical representations of the runtimes based on performance, highlighting maximum and minimum transaction counts for easy comparison. Click Top runtimes or All runtimes tab to view its respective transactions in the runtime split and line graph.

You can customize the number of Top runtimes to display using Row settings under User preferences. For more details, see Customizing Row settings.

The Upward Trending tab displays the list of runtimes for which the transaction trend percentage is greater than the set transaction trend threshold in the Runtime: Upward trending/improving section of the User preference - Threshold page. The Downward trending tab displays the list of runtimes for which the transaction trend percentage is lesser than the set transaction trend threshold in the Runtime: Downward trending / deteriorating by section of the User preference - Threshold page. For more details on how to set the trend threshold, see Change threshold settings.

How to determine the total transactions and trend analysis for all runtimes?

Total transactions of the runtime=i=1n(Total transactions of the runtime in the time stamp i)\text{Total transactions of the runtime} = {\sum_{i=1}^{n} \left(\text{Total transactions of the runtime in the time stamp } i\right)}

Example:

Let’s determine the total transactions of the runtime A for 4 hours based on the following metrics. Let’s assume:

Time stamp Total transactions
1st one hour 100
2nd one hour 200
3rd one hour 200
4th one hour 50

Total transaction of the runtime A for 4 hours=100+200+250+100=550\text{Total transaction of the runtime A for 4 hours} = {100+200+250+100} = 550

Similarly, let’s assume, the total transactions of the runtime B for 4 hours is 450

Total transactions of all runtimes=i=An(Total transactions of runtime i)\text{Total transactions of all runtimes} = {\displaystyle\sum_{i=A}^{n} \left(\text{Total transactions of runtime } i\right)}

Let’s determine the total transactions of all runtimes for 4 hours. Let’s assume:

Runtime Total transactions
A 550
B 450

Total transaction of all runtimes for 4 hours=550+450=1000\text{Total transaction of all runtimes for 4 hours} = {550+450} = 1000

Transactions trend analysis allows you to compare current and past transactions based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

Transactions trend percentage for all runtimes for 24 hours=(Total transactions of runtime in last 24 hoursTotal transactions of runtime in previous 24 hoursTotal transactions of runtime in previous 24 hours)100\text{Transactions trend percentage for all runtimes for 24 hours} = (\frac{\text{Total transactions of runtime in last 24 hours} - \text{Total transactions of runtime in previous 24 hours}}{\text{Total transactions of runtime in previous 24 hours}})*100

You can replace 24 hours with the time range you select in the time range. If the determined trend percentage of transactions is a

Example:
Let’s determine the transactions trend percentage for all runtimes for 24 hours:

Let’s assume:

Total transactions of runtime in last 24 hours Total transactions of runtime in previous 24 hours, that is the 24 hours prior to the last 24 hours
1000 500

Transactions trend percentage for 24 hours for all runtimes=(1000500500)100=100%\text{Transactions trend percentage for 24 hours for all runtimes} = (\frac{1000-500}{500} )*100 = 100\%

The determined transactions trend percentage, 100% (positive), appears in green with an upward arrow indicating increased transactions compared to the previous 24 hours.


Error rate

Error rate indicates the percentage of errors that occurred during API transactions. This widget provides a comprehensive overview of error rate of all runtimes along with the details of the runtime with maximum and minimum error rate to make informed business decisions. Click Top runtimes or All runtimes tab to view its respective error rate in the runtime split and line graph.

You can customize the number of Top runtimes to display using Row settings under User preferences - Display. For more details, see Customizing Row settings.

The Upward Trending tab displays the list of runtimes for which the error rate trend percentage is lesser than the set error rate trend threshold in the Runtime: Upward trending/improving section of the User preference - Threshold page. The Downward trending tab displays the list of runtimes for which the error rate trend percentage is greater than the set error rate trend threshold in the Runtime: Downward trending / deteriorating by section of the User preference - Threshold page. For more details on how to set the trend threshold, see Change threshold settings.

How to determine the error rate and trend analysis for all runtimes?

Error rate of the runtime=i=1n(Error count of the runtime in the time stamp i)i=1n(Transactions count of the runtime in the time stamp i)×100\text{Error rate of the runtime} = \frac{\displaystyle\sum_{i=1}^{n} \left(\text{Error count of the runtime in the time stamp } i\right)}{\displaystyle\sum_{i=1}^{n} \left(\text{Transactions count of the runtime in the time stamp } i\right)} \times 100

Example:

Let’s determine the error rate of the runtime A for 4 hours based on the following metrics. Let’s assume:

Time stamp Error count Total transactions
1st one hour 150 300
2nd one hour 115 200
3rd one hour 30 500
4th one hour 100 300

Error rate of the runtime A for 4 hours=(150+115+30+100300+200+500+300)100=35.90%\text{Error rate of the runtime A for 4 hours} = (\frac{150+115+30+100}{300+200+500+300})*100 = 35.90\%

Similarly, let’s assume, the error rate of the runtime B for 4 hours is 50%

Error rate of all runtimes=i=An(Error count of the runtime i)i=An(Transactions count of the runtime i)×100\text{Error rate of all runtimes} = \frac{\displaystyle\sum_{i=A}^{n} \left(\text{Error count of the runtime } i\right)} {\displaystyle\sum_{i=A}^{n} \left(\text{Transactions count of the runtime } i\right)} \times 100

Let’s determine the error rate of all runtimes for 4 hours. Let’s assume:

Runtime Error count Total transactions
A 395 1100
B 250 500

Error rate of all runtimes for 4 hours=(395+2501100+500)100=40.31%\text{Error rate of all runtimes for 4 hours} =(\frac{395 + 250}{1100 + 500})*100 = 40.31\%

Error rate trend analysis allows you to compare current and past error rates based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

Error rate trend percentage for all runtimes for 24 hours time range=(Error rate of all runtimes in last 24 hoursError rate of all runtimes in previous 24 hoursError rate of all runtimes in previous 24 hours)100\text{Error rate trend percentage for all runtimes for 24 hours time range} = (\frac{\text{Error rate of all runtimes in last 24 hours} -\text{Error rate of all runtimes in previous 24 hours}}{\text{Error rate of all runtimes in previous 24 hours}})*100

You can replace 24 hours with the time range that you select. If the determined error rate trend percentage is a

Example:

Let’s determine the error rate trend percentage for all runtimes for 24 hours. Let’s assume:

Error rate of all runtimes in last 24 hours Error rate of all runtimes in previous 24 hours, that is 24 hours prior to the last 24 hours
35.90% 50%

Error rate trend percentage for 24 hours time range for all runtimes=(0.350.500.50)100=30%\text{Error rate trend percentage for 24 hours time range for all runtimes} = (\frac{0.35-0.50}{0.50})*100 = -30\%

The determined error rate trend percentage, -30% (negative), appears in green with an downward arrow indicating that the error rate has decreased compared to the previous 24 hours.


Availability

This widget shows the availability of all runtimes, which enables you to monitor the health status of all associated runtimes.

The availability is determined based on the sum of the heartbeat status value of the runtime. If API Control Plane:

The frequency at which the runtime must send the heartbeat status to API Control Plane is defined in the API Control Plane Agent configuration. For details about how to configure the API Control Plane Agent, see Connecting webMethods.io API Gateway to API Control Plane section in API Gateway Administration guide. For details about how to develop agent using SDK, see Agent SDK.

For example, if the heartbeat interval is defined as 60 seconds in the API Control Plane agent configuration. Then for an hour the expected heartbeat status value must be 3600.

Availability of a runtime=i=1n(Actual heartbeat value of the runtime in the time stamp i)i=1n(Expected heartbeat value of the runtime in the time stamp i)×100\text{Availability of a runtime} = \frac{\displaystyle\sum_{i=1}^{n} \left(\text{Actual heartbeat value of the runtime in the time stamp } i\right)}{\displaystyle\sum_{i=1}^{n} \left(\text{Expected heartbeat value of the runtime in the time stamp } i\right)} \times 100

Example:

Let’s determine the availability of the runtime A for 4 hours based on the following metrics. Let’s assume:

Time stamp Sum of the heartbeats received Sum of the heartbeats expected
1st one hour 1800 3600
2nd one hour 3600 3600
3rd one hour 3000 3600
4th one hour 3600 3600

Availability of the runtime A for 4 hours=(1800+3600+3000+36003600+3600+3600+3600)100=83.33%\text{Availability of the runtime A for 4 hours} = (\frac{1800+3600+3000+3600}{3600+3600+3600+3600})*100 = 83.33\%

Similarly, let’s assume, the availability of the runtime B for 4 hours is 100%

Availability of all runtimes=i=AnAvailability of Runtime iTotal Number of Runtimes\text{Availability of all runtimes} = \frac{\displaystyle\sum_{i=A}^{n} \text{Availability of Runtime } i} {\text{Total Number of Runtimes}}

Let’s assume:

Runtime Sum of the heartbeats received Sum of the heartbeats expected
A 55 60
B 35 60

Availability of all runtimes=(83.33+1002)100=91.66%\text{Availability of all runtimes} = (\frac{83.33+100}{2})*100 = 91.66\%

Availability trend analysis allows you to compare current and past availability status based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

Availability trend percentage for all runtimes for 24 hours time range=(Availability of all runtimes in last 24 hoursAvailability of all runtimes in previous 24 hoursAvailability of all runtimes in previous 24 hours)100\text{Availability trend percentage for all runtimes for 24 hours time range} = (\frac{\text{Availability of all runtimes in last 24 hours} - \text{Availability of all runtimes in previous 24 hours}}{\text{Availability of all runtimes in previous 24 hours}})*100

You can replace 24 hours with the time range that you select. If the determined trend percentage of availability is

Example:

Let’s determine the availability trend percentage for all runtimes for 24 hours. Let’s assume:

Availability of all runtimes in last 24 hours Availability of all runtimes in previous 24 hours
98% 80%

Availability Trend percentage for runtimes for 24 hours time range=(0.980.800.80)100=22%\text{Availability Trend percentage for runtimes for 24 hours time range} = (\frac{0.98-0.80}{0.80})*100 = 22\%

The determined availability trend percentage, 22% (positive), appears in green with an upward arrow indicating that the availability has increased compared to the previous 24 hours.

Response time

Response time indicates total time taken to process an incoming API request and send the response to the client during API transactions. This includes the time taken by API Gateway and the backend service to process the request. This widget provides a comprehensive overview of response time of all runtimes along with the details of the runtime with maximum and minimum latency to make informed business decisions. Click Top runtimes or All runtimes tab to view its respective response time in the runtime split and line graph.

You can customize the number of Top runtimes to display using Row settings under User preferences - Display. For more details, see Customizing Row settings.

The Upward Trending tab displays the list of runtimes for which the response time trend percentage is lesser than the set response time trend threshold in the Runtime: Upward trending/improving section of the User preference - Threshold page. The Downward trending tab displays the list of runtimes for which the response time trend% is greater than the set response time trend threshold in the Runtime: Downward trending / deteriorating by section of the User preference - Threshold page. For more details on how to set the trend threshold, see Change threshold settings.

How to determine the response time and trend analysis for all runtimes?

Response time of a runtime=i=1n(Response time of the runtime in time stamp i×Total transaction count of the runtime in time stamp i)i=An(Transaction count of runtime i)\text{Response time of a runtime} = \frac{\displaystyle\sum_{i=1}^{n} \left(\text{Response time of the runtime in time stamp } i \times \text{Total transaction count of the runtime in time stamp } i\right)}{\displaystyle\sum_{i=A}^{n} \left(\text{Transaction count of runtime } i\right)}

Example:

Let’s determine the response time of the runtime A for 4 hours based on the following metrics. Let’s assume:

Time stamp Response time Transaction count
1st one hour 1.05ms 10
2nd one hour 2.07ms 15
3rd one hour 0.08ms 20
4th one hour 1.07ms 30

Response time of the runtime A for 4 hours=((1.0510)+(2.0715)+(0.0820)+(1.0730)75)=1.00ms\text{Response time of the runtime A for 4 hours} = (\frac{(1.05*10)+(2.07*15)+(0.08*20)+(1.07*30)}{75}) =1.00ms

Similarly, let’s assume, the response time of the runtime B for 4 hours is 0.05ms

Response time of all runtimes=i=An(Response time of runtime i×Total transaction count of runtime i)i=AnTransaction count of runtime i\text{Response time of all runtimes} = \frac{\displaystyle\sum_{i=A}^{n} (\text{Response time of runtime } i \times \text{Total transaction count of runtime } i)}{\displaystyle\sum_{i=A}^{n} \text{Transaction count of runtime } i}

Let’s assume:

Runtime Response time No. of Transactions
A 1.00ms 75
B 0.05ms 60

Response time of all runtimes=((1.0075)+(0.0560)135)=0.57ms\text{Response time of all runtimes} = (\frac{(1.00*75)+(0.05*60)}{135}) = 0.57ms

Response time trend analysis allows you to compare current and past response time based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

Response time trend percentage for all runtimes for 24 hours time range=(Response time of all runtimes in last 24 hoursResponse time of all runtimes in previous 24 hoursResponse time of all runtimes in previous 24 hours)100\text{Response time trend percentage for all runtimes for 24 hours time range} = (\frac{\text{Response time of all runtimes in last 24 hours} - \text{Response time of all runtimes in previous 24 hours}}{\text{Response time of all runtimes in previous 24 hours}})*100

You can replace 24 hours with the time range that you select. If the determined trend percentage of response time is

Example:

Let’s determine the response time trend percentage for all runtimes for 24 hours. Let’s assume:

Response time of all runtimes in last 24 hours Response time of all runtimes in previous 24 hours
0.57ms 3.41ms

Response time Trend percentage for runtimes for 24 hours time range=(0.573.413.41)100=83.28%\text{Response time Trend percentage for runtimes for 24 hours time range} = (\frac{0.57-3.41}{3.41})*100 = -83.28\%

The determined response time trend percentage, -83.28% (negative), appears in green with an downward arrow indicating that the response time has decreased compared to the previous 24 hours.

Latency

Latency indicates time taken by API Gateway to process an API request during API transactions. This does not include the time taken by the backend service to process the request. This widget provides a comprehensive overview of latency of all runtimes along with the details of the runtime with maximum and minimum latency to make informed business decisions. Click Top runtimes or All runtimes tab to view its respective latency in the runtime split and line graph.

You can customize the number of Top runtimes to display using Row settings under User preferences - Display. For more details, see Customizing Row settings.

The Upward Trending tab displays the list of runtimes for which the latency trend percentage is lesser than the set latency trend threshold in the Runtime: Upward trending/improving section of the User preference - Threshold page. The Downward trending tab displays the list of runtimes for which the latency trend% is greater than the set latency trend threshold in the Runtime: Downward trending / deteriorating by section of the User preference - Threshold page. For more details on how to set the trend threshold, see Change threshold settings.

How to determine the latency and trend analysis for all runtimes?

Latency of a runtime=i=1n(Latency of the runtime in time stamp i×Total transaction count of the runtime in time stamp i)i=An(Transaction count of runtime i)\text{Latency of a runtime} = \frac{\displaystyle\sum_{i=1}^{n} \left(\text{Latency of the runtime in time stamp } i \times \text{Total transaction count of the runtime in time stamp } i\right)}{\displaystyle\sum_{i=A}^{n} \left(\text{Transaction count of runtime } i\right)}

Example:

Let’s determine the latency of the runtime A for 4 hours based on the following metrics. Let’s assume:

Time stamp Latency Transaction count
1st one hour 0.05ms 10
2nd one hour 0.07ms 15
3rd one hour 0.08ms 20
4th one hour 0.07ms 30

Latency of the runtime A for 4 hours=((0.0510)+(0.0715)+(0.0820)+(0.0730)75)=0.04ms\text{Latency of the runtime A for 4 hours} = (\frac{(0.05*10)+(0.07*15)+(0.08*20)+(0.07*30)}{75}) = 0.04ms

Similarly, let’s assume, the latency of the runtime B for 4 hours is 0.05ms

Latency of all runtimes=i=An(Latency of runtime i×Total transaction count of runtime i)i=An(Transaction count of runtime i)\text{Latency of all runtimes} = \frac{\displaystyle\sum_{i=A}^{n} \left(\text{Latency of runtime } i \times \text{Total transaction count of runtime } i\right)}{\displaystyle\sum_{i=A}^{n} \left(\text{Transaction count of runtime } i\right)}

Let’s assume:

Runtime Latency No. of Transactions
A 0.04ms 75
B 0.05ms 60

Latency of all runtimes=((0.0475)+(0.0560)135)=0.04ms\text{Latency of all runtimes} = (\frac{(0.04*75)+(0.05*60)}{135}) = 0.04ms

Latency trend analysis allows you to compare current and past latency based on the time range you choose to spot changes, which helps in making informed business decisions and predicting future performance.

Latency trend percentage for all runtimes for 24 hours time range=(Latency of all runtimes in last 24 hoursLatency of all runtimes in previous 24 hoursLatency of all runtimes in previous 24 hours)100\text{Latency trend percentage for all runtimes for 24 hours time range} = (\frac{\text{Latency of all runtimes in last 24 hours} - \text{Latency of all runtimes in previous 24 hours}}{\text{Latency of all runtimes in previous 24 hours}})*100

You can replace 24 hours with the time range that you select. If the determined trend percentage of latency is

Example:

Let’s determine the latency trend percentage for all runtimes for 24 hours. Let’s assume:

Latency of all runtimes in last 24 hours Latency of all runtimes in previous 24 hours
0.04ms 3.41ms

Latency trend percentage for runtimes for 24 hours time range=(0.043.413.41)100=98.82%\text{Latency trend percentage for runtimes for 24 hours time range} = (\frac{0.04-3.41}{3.41})*100 = -98.82\%

The determined latency trend percentage, -98.82% (negative), appears in green with an downward arrow indicating that the latency has decreased compared to the previous 24 hours.

Monitoring a specific runtime

API Control Plane provides guidance on monitoring the performance of a particular runtime. This monitoring capability helps you pinpoint the highest and lowest performing APIs within that runtime, empowering you to make well-informed business decisions.

To monitor a specific runtime

  1. Click the Runtimes tab.
    The Manage runtimes page appears.

  2. Click the Monitor icon under the Action column corresponding to the runtime for which you want view the performance metrics.

    By default, the Runtime specific monitoring page renders the metrics of all the runtimes pertaining to last 1 hour. If you want to render the metrics for a different time range, select the predefined or custom time range from the Time Range drop-down menu (that appears in the top right corner of the page) based on your requirement and click the Apply button.

Note
When monitoring webMethods.io Developer Portal runtime type, only the Status and Availability widgets render on the Runtime specific monitoring page.Since Developer Portal does not send performance metrics to API Control Plane, only the Status and Availability widgets are applicable for Developer Portal runtime type. Therefore, data is populated only in these two widgets.

For more details on how each widget is represented, see Widgets in detail section under Monitoring all runtimes

Runtime specific Monitoring: Activities