Skip to main content

Ddosify Latency Testing GitHub Action

· 9 min read
Fatih Baltaci

Ddosify Latency Testing GitHub Action

Introduction

In this article, we will demonstrate how to use the Ddosify GitHub Action to periodically test the latency of our target endpoints from 60+ cities worldwide. By configuring the action to run on a schedule, we can ensure that the performance of our locations is consistently monitored. If the latency of any of our locations exceeds the expected value, we will receive an email notification alerting us to the issue. By using this action, we can proactively identify and address potential performance issues before they impact our users.

Prerequisites

  • Ddosify API Key. Here are the instructions to create one.
  • A GitHub repository to store the workflow file.

Step 1: Store the Ddosify API Key as a Secret

To store the Ddosify API key as a secret, follow these steps:

  1. Copy the Ddosify API key from the Ddosify Cloud account settings page.
  2. Go to the repository settings page.
  3. Click on the Secrets - Actions tab.
  4. Click on the New repository secret button.
  5. Enter DDOSIFY_API_KEY as the name of the secret.
  6. Enter the Ddosify API key as the value of the secret.
  7. Click on the Add secret button.

Ddosify API Key Secret

Step 2: Create a Workflow File

Create a new file named ddosify-latency-testing.yml in the .github/workflows directory of your repository. Different configurations are available in this repository.

.github/workflows/ddosify-latency-testing.yml
name: "Ddosify Latency Testing"

on:
schedule:
- cron: '0 * * * *' # Every one hour. The shortest interval is once every 5 minutes

jobs:
latency-test:
runs-on: ubuntu-latest

steps:
- name: Ddosify Latency Test
uses: ddosify/ddosify-latency-[email protected]
with:
api_key: ${{ secrets.DDOSIFY_API_KEY }}
target: "https://app.servdown.com"
locations: '["*"]'
failIf: "EU.*>50"

The on section defines the event that triggers the workflow. In this example, the workflow is scheduled to run every hour. The uses section defines the action to run. In this example, we use the ddosify/[email protected] action. The with section defines the inputs to the action. In this example, we define the following inputs:

  • api_key: The API key to authenticate with Ddosify. We use the GitHub Secrets feature to store the API key. The API key is stored in the DDOSIFY_API_KEY secret.
  • target: The target endpoint to test. You can use any valid URL or IP address.
  • locations: The locations to test. In this example, we use ["*"] to test all the 60+ cities worldwide. We will show the usage examples of the locations object on the locations section.
  • failIf: The condition to fail the test. In this example, we use EU.*>50 to fail the test if the latency of any city on Europe continent exceeds 50ms. We will show the usage examples of the failIf object on the failIf section.

After you push the workflow file to the repository, the workflow will be triggered. You can check the workflow status on the repository actions page. An example output of the workflow is shown below.

Ddosify Latency Action Result

This actions is failed because the latency of the EU locations exceeds the expected value.

info

You can check the detailed results of the test on the repository action page. You must be logged in to the GitHub to view the logs.

Input Examples

locations

The following table shows some examples of the locations input. Supported locations are accessible via Ddosify API or you can get the location codes from the example output. We suggest accessing it from Ddosify API since we are adding new locations continuously. You can use the locations input to test the latency of your target endpoint from a specific locations.

ExampleDescription
'["*"]'All over the world (60+ cities)
'["NA.*"]'All the available cities from North America (NA) Continent
'["EU.DE.*"]'All the available cities from Germany
'["EU.GB.ENG.LO"]'From London

failIf

The following table shows some examples of the failIf input. You can use the failIf input to fail the test if the latency of any location exceeds the expected value. The failIf input supports the following examples:

ExampleDescription
"any>100"Fail if any of the locations is greater than 100ms latency
"EU.*>80"Fail if any of the locations from Europe (EU) Continent is greater than 80ms latency
"NA.US.TX.*>120"Fail if any of the locations from Texas is greater than 120ms latency
"NA.US.TX.DA>120"Fail if Dallas is greater than 120ms latency

Example Output

The following table shows an example output of the action. You can access the location codes from this table or from the Ddosify API. The Fail If column shows the condition to fail the test. The test is failed if the latency of any location exceeds the expected value. In this example, the test is failed because the latency of the Europe locations exceeds the expected value.

Fail if:   EU.*>100 
Target: https://app.servdown.com
Locations: *
┌────────────────────────────────────────────────────────────────────────────────────┐
| Location | Location Code | Status Code | Latency (ms) | Fail If (ms) |
├────────────────────────────────────────────────────────────────────────────────────┤
| Las Vegas | NA.US.NV.LV | 200 | 196 | |
| Oslo | EU.NO.OS | 200 | 63 | >100 |
| Boston | NA.US.MA.BO | 200 | 126 | |
| Seoul | AS.KR.SE | 200 | 288 | |
| Istanbul | AS.TR.IS | 200 | 56 | |
| Cape Town | AF.ZA.WC.CT | 200 | 169 | |
| San Antonio | NA.US.TX.SA | 200 | 138 | |
| Denver | NA.US.CO.DE | 200 | 154 | |
| Hamburg | EU.DE.HA.HA | 200 | 28 | >100 |
| Chicago | NA.US.IL.CH | 200 | 116 | |
| Hyderabad | AS.IN.TG.HY | 200 | 145 | |
| Salt Lake City | NA.US.UT.SLC | 200 | 139 | |
| Amsterdam | EU.NL.NH.AM | 200 | 31 | >100 |
| Hong Kong | AS.CN.HCW.HK | 200 | 205 | |
| Minneapolis | NA.US.MN.MI | 200 | 117 | |
| Sao Paulo | SA.BR.SA | 200 | 231 | |
| Denizli | AS.TR.DE | 200 | 81 | |
| Sydney | OC.AU.NSW.SY | 200 | 313 | |
| Dublin | EU.IE.L.DU | 200 | 35 | >100 |
| New Delhi | AS.IN.DL.ND | 200 | 272 | |
| Lappeenranta | EU.FI.SK.LA | 200 | 55 | >100 |
| Stockholm | EU.SE.ST | 200 | 32 | >100 |
| Des Moines | NA.US.IA.DM | 200 | 127 | |
| Los Angeles | NA.US.CA.LA | 200 | 184 | |
| Montreal | NA.CA.QC.MO | 200 | 114 | |
| Pune | AS.IN.MH.PU | 200 | 139 | |
| Houston | NA.US.TX.HO | 200 | 131 | |
| Johannesburg | AF.ZA.GP.JO | 200 | 189 | |
| Miami | NA.US.FL.MI | 200 | 158 | |
| New York | NA.US.NJ.NY | 200 | 96 | |
| Dallas | NA.US.TX.DA | 200 | 162 | |
| Melbourne | OC.AU.VIC.ME | 200 | 310 | |
| Philadelphia | NA.US.PA.PH | 200 | 102 | |
| Quincy | NA.US.WA.QU | 200 | 163 | |
| Toronto | NA.CA.ON.TO | 200 | 114 | |
| Frankfurt | EU.DE.HE.FR | 200 | 21 | >100 |
| Milan | EU.IT.25.MI | 200 | 44 | >100 |
| Taipei | AS.TW.TP | 200 | 268 | |
| Warsaw | EU.PL.MZ.WA | 200 | 28 | >100 |
| Ankara | AS.TR.AN | 200 | 62 | |
| Mumbai | AS.IN.MH.MU | 200 | 145 | |
| North Charleston | NA.US.SC.NC | 200 | 112 | |
| Doha | AS.QA.DA.DO | 200 | 132 | |
| Seattle | NA.US.WA.SE | 200 | 160 | |
| Atlanta | NA.US.GA.AT | 200 | 118 | |
| Paris | EU.FR.IDF.PA | 200 | 64 | >100 |
| Ashburn | NA.US.VA.AS | 200 | 97 | |
| London | EU.GB.ENG.LO | 200 | 34 | >100 |
| Kansas City | NA.US.MO.KC | 200 | 127 | |
| Jakarta | AS.ID.JK | 200 | 275 | |
| Tel Aviv | AS.IL.TA | 200 | 88 | |
| Phoenix | NA.US.AZ.PH | 200 | 191 | |
| Manama | AS.BH.MA | 200 | 127 | |
| Madrid | EU.ES.MA | 200 | 53 | >100 |
| Osaka | AS.JP.OS | 200 | 243 | |
| Izmir | AS.TR.IZ | 200 | 61 | |
| Dublin | NA.US.OH.DU | 200 | 106 | |
| Tokyo | AS.JP.TO | 200 | 270 | |
| Portland | NA.US.OR.PO | 200 | 178 | |
| Dubai | AS.AE.DU | 200 | 131 | |
| Singapore | AS.SG.01.SI | 200 | 167 | |
| Santiago | SA.CL.RM.SA | 200 | 215 | |
| Zurich | EU.CH.ZH | 200 | 26 | >100 |
| San Jose | NA.US.CA.SJ | 200 | 174 | |

Conclusion

The latency is important for the user experience. You should test your target endpoint's latency periodically to ensure that your users are not experiencing any issues. You can use Ddosify Latency Testing GitHub action to test the latency of your target endpoint periodically. The action will send a request to your target endpoint from 60+ cities and measure the latency. If the latency is higher than the threshold, the action will send a notification to you. So you can take action to fix the issue before your users experience any problems. If you don't want to use Github Actions, you can also use Ddosify Cloud to create periodic city-level latency tests. An example scheduler result for latency testing in Ddosify Cloud is shown below.

Ddosify Cloud Latency Testing Scheduler