Building the Global Experience Tester with Seaplane

The Global Experience Tester takes an input URL and tests its global latency on all available Seaplane edge resources. Here’s a look at how we built it.

Seaplane

Engineering

Recently, Seaplane was nominated for the Edge Startup of the Year award by Topio Networks as a part of the Edge Computing World Conference! While we didn’t take the top prize (though we heartily congratulate CruxOCM for their victory), it did give us the opportunity to build an edge-focused demo.

Building an interesting and engaging edge infrastructure demo, or any infrastructure demo, can be a serious challenge. Executing a few commands in a terminal isn’t the most visually engaging thing in the world, and there’s no real sense of “tada!” at the end. You have to take the demo-er’s word for it that something interesting is happening in the background.

Obviously there’s nothing wrong with these kinds of demos, but we wanted to take it up a notch with ours. We didn’t want to tell participants Seaplane was doing something cool, we wanted to show them. We wanted to quantify Seaplane’s performance while also giving a bit more color and depth to what’s going on behind those simple terminal commands.

So, we decided to build an interactive application that not only measures the global performance of the Seaplane compute and data services, but also helps participants understand and contextualize their own website’s global performance.

Introducing the Seaplane Global Experience Tester (GET)! This application takes an input URL and tests its global latency on all — currently available — Seaplane edge resources. At the time of building the GET, that represents 64 points of presence but that number is already outdated as we expand.

For each testing location, we also perform a latency test on the Seaplane Metadata Key-Value Store as a point of comparison. The idea is to demonstrate and quantify the performance improvements users could expect if they started deploying with Seaplane.

Let’s take a closer look at the app.

Application Architecture

The GET consists of five key components:

A react front-end with a Flask backend
A URL and data latency tester microservice
The seaplane Metadata Key-Value Store
Google Pubsub
Google Datastore

The Front-End

For the front-end, we kept things simple and went with a react-based application supported by a Flask-based back-end. The front-end allows the user to submit a URL for testing then review the results. Flask provides a simple API with two endpoints; one to submit a new test, and one to pull the results from the database.

PubSub

We decided to use Google Pubsub to connect everything together while Seaplane’s own PubSub product is still in development (you can request early access here). We like to use Seaplane services where possible, but this is a great example of how easily Seaplane integrates with your favorite cloud providers.

We set up PubSub with a single topic <test-requests>. Each URL latency tester microservice registers a new subscriber on creation. The <submit_test> API is the only publisher and publishes a new test request every time the user enters a URL.

Data latency tester microservice

The latency tester microservice is a python-based application running on all available Seaplane locations. We containerized the application and deployed it using the Seaplane command line interface (CLI). Deploying on Seaplane only takes two steps:

First, we create a flight that contains our URL-tester image:

After creating the flight, we can create our formation and deploy our workload globally:

And just like that, our url-tester application runs globally on all available Seaplane resources! If you want to learn more about Seaplane, or deploy your own applications globally, you can read our documentation and request access here.

Inside the URL-testing container we run a simple python script that performs four tests for each URL:

A latency test of the URL the user entered
A latency test for read, write and delete queries to the Seaplane Metadata Key-Value Store

Each test is performed ten times, and the result is stored in the Google Data Store for consumption by the front-end.

Metadata Key-Value Store

Besides showing users how easy it is to deploy a containerized application, we wanted to demonstrate the combined power of Seaplane compute and data. For this reason, every testing container also pings the closest Seaplane Meta-Data Key-Value Store (MDKVS).

Similar to the compute service, Seaplane finds the best location for your data based on end user load and performance. However, due to the limited end user load (just a couple of Seaplane folks and conference attendees!), we had to override that behavior.

The compute container that performs the tests runs in ~64 locations and we want to have our metadata stores run as close as possible to those locations. The best way to achieve that with the MDKVS is by creating directories that are restricted to each of those locations.

To do that, we used the MDKVS API and set up 64 directories all locked to precise locations:

What We Found

Building the Global Experience Tester necessarily meant testing a lot of websites for their global performance, leading to some interesting finds. At the same time, we were also beta testing our MDKVS and made a few intriguing discoveries.

First, we found that one of the hard disks in our compute cluster in India was acting up, resulting in much slower (300ms+) latencies. We have since replaced this disk, and performance is back to normal. Moving forward, we’ll be using a slightly altered version of the GET to beta-test new products.

We also discovered a major speed improvement for our Python SDK that was still in beta. The SDK requested new credentials, with every request drastically slowing down the MDKVS results. We have since moved the authentication to a separate request. The Python SDK now matches the API in speed.

Running the GET also provided some interesting insights into where websites are typically hosted. Take example.com…for example. Based on our results map, it’s safe to assume example.com is exclusively hosted in North America.

Latency isn’t very important for a website like example.com, but chances are good you care a bit more about your end-user experience than they do!

The GET is going to stay a conference exclusive for now, but if you’d like to give it a try please reach out using our contact form in the footer. We’d love to give you a demo and see how your URL stacks up.

You can also read our documentation here or join our edge and platform community on Discord.

Thank you for flying with Seaplane!

‍