If https is supported it would allow querying from a browser page that is https, currently the endpoints only support http and result in a mixed content error.

Free wildcard certificates could be issued via LetsEncrypt and automated to refresh every 3 months.

Cloud Run now supports them: https://cloud.google.com/blog/products/serverless/cloud-run-gets-websockets-http-2-and-grpc-bidirectional-streams

GCLB supports them: https://cloud.google.com/load-balancing/docs/https#websocket_support

• https://godoc.org/github.com/gorilla/websocket

Hello,
Thanks for the wonderful project! There are now 9 regions in asia. I hope you get a chance to add them. Cheers!

Highlight the row, and/or show a headline banner that says "Nearest region: europe-west1"

Maybe show top 3 nearest with gold/silver/bronze medals.

The following GCP regions are missing in the gcpping list

us-west2-a/b/c <--> Los Angeles, California, North America
us-west3-a/b/c <--> Salt Lake City, Utah, North America
us-west4-a/b/c <--> Las Vegas, Nevada, North America

Could you please include them ?

It would be nice to have it included on the list. :)

Might be as simple as adding Cache-Control: max-age=0 on pong responses? The backend-service is already configured with --enable-cdn

• https://cloud.google.com/cdn/docs/

It will be highly appreciatable if we have the region name along with the country name.

https://cloud.google.com/compute/docs/load-balancing/http/backend-service#user-defined-request-headers

By configuring these request headers and echoing them in the response, we should be able to show in the UI where the load balancer thinks you are.

This would require a fairly hefty rewrite of the ping mechanism though, which currently relies on loading an <img> to perform HTTP requests, since IIRC using XMLHttpRequest had more overhead for some reason (though it would contain response headers).

In order to ensure VM images are up-to-date, we should periodically refresh the stack, basically by running setup.sh. This would be possible a few ways:

1.) Have a GAE Flex cron job that literally runs setup.sh
2.) Have a GAE Standard cron job that runs a Go program equivalent to setup.sh
3.) Have a GAE Standard cron job that begins a Deployment Manager deployment (See #5)

Wouldn't it be nice to have fastest zones on top?

Maybe with client-side JS to sort it (since I see the values are updated all the time)?

PS Great job bro! Really impressive in its simplicity and elegance.

I've been meaning to migrate to Cloud Run for a while, and I think the time might be coming sooner rather than later.

Why Cloud Run?

1. Cost: Running 20-some VMs, even f1-micro VMs, with static IP addresses and a global load balancer, incurs a cost in the $150/month range. These VMs are nearly always idle. Cloud Run should reduce VM costs greatly, even using minimum instances to shorten initial request latency.

2. Reproducibility: Though the VMs are simply COS VMs running a container, they occasionally become unreachable and break the site. Restarting the VMs fixes them, and I could just set up a cron job to restart everything ever hour or whatever, but ultimately I'd love to not worry about it. A better option would be a more declarative config bundle that can be applied at any time to update and refresh the site. The setup.sh script has improved a lot in the last ~4 years, but it's still overly imperative and occasionally requires hand edits to add a new region (in particular around static IP addresses). Relying on Cloud Run and making everything driven by a declarative config bundle should make the site more reproducible and able to be run by anybody who wants to run their own copy.

3. HTTPS: It's almost 2021, running an HTTP site is frankly embarrassing. #22 has some ideas about how to support HTTPS, but wouldn't it be nice to just rely on a platform that can only serve HTTPS?

Breaking Changes

1. As part of this migration, absolute latency values will increase -- Cloud Run apps are slightly slower to reach than raw GCE VMs, on the order of a hundred ms or so (TODO: more precise data). The site can still be useful as a relative latency dashboard ("which region is closest to me"), so long as we compare apples to apples. As part of this migration, the page should make it clearer what the intentions and limitations are, to avoid confusion.

2. Some users have taken a dependency on http://www.gcping.com/config.js as a source of IP addresses expected to be up in a number of regions. I intend to make a new config.js available pointing to regional Cloud Run service addresses, but they won't be HTTP IP addresses, they'll be HTTPS host names. I don't know what everyone's depending on, and this might break people. (see https://www.hyrumslaw.com/)

3. Cloud Run is not yet available in every GCP region, but I believe it intends to be. As new regions come online GCPing should auto-update to include them.

Plan

I plan to mostly start fresh from the image ko-built from ./cmd/ping and the frontend JS in index.html. The rest can be configs to deploy Cloud Run Services for every available region, and generate config.js which plugs into the frontend JS. I'll fork a branch from the latest GCE VM version in case people are interested in using that.

We'll still need a global IP and load balancer, with a serverless NEG to route to Cloud Run backends.

I'd like to update the frontend to actually use XHR instead of <img onload> (now that lowering absolute latency isn't a goal, readability/maintainability can take over), which would let the global row show which backend it reached.

https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances#monitoring_groups

If a VM fails to respond to /ping, GCE can automatically restart the VM.

us-west2
us-west3
us-west4

seem to be missing from the service.

Each region's VM would respond with their region name, UI would display that...somehow.

This would necessitate using a real XHR instead of the <img onload=...> we do now, but maybe that would be useful somehow.

Material Design, flashy colors, real actual CSS.

Expertise welcome :)

Kudos! This is neat.

De-reference gcping-1369

Some browsers can report network information observed over time by the browser like estimated download bandwidth, estimated connection type (wifi, cellular) and estimated observed RTT. This could be useful to show alongside estimated observed latency to GCP locations, and if we ever collect data in BigQuery that would be useful to record alongside any measurements.

• https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation

https://cloud.google.com/blog/topics/sustainability/sharing-carbon-free-energy-percentage-for-google-cloud-regions

https://github.com/GoogleCloudPlatform/region-carbon-info/blob/main/data/yearly/2019.csv

It was showing the other day, but now it's not.
I know nothing else.
I thought you might want to know in case you haven't noticed it yet.

There is available new region in Warsaw (Poland) europe-central2, which is not yet included in GCP ping. I think Cloud Run is not supported there yet, though.

There is a new region in Delhi (India - asia-south2), which is not yet included in GCP ping. Also, Cloud Run is supported in this region.

TL;DR: https error on https://gcping.com. Cert common name says it's for "*.storage.googleapis.com" instead of "gcping.com" or "www.gcping.com"

Hi!

First off, thanks for the useful site! It's great to see things like this popping up. 🙂

I noticed that the certificate that the ssl certificate for gcping.com doesn't match the domain name (specifically Chrome saying "net::ERR_CERT_COMMON_NAME_INVALID).

Steps to repro:

1. Navigate to https://www.gcping.com/

Expected outcome:
2. SSL certificate common name matches and the site appears like magic over ssl

Actual outcome:
2. Notice the error page Chrome serves up
3. Inspect the certificate to notice "*.storage.googleapis.com" as the common name instead of "gcping.com"

Suggested fix:
Ok, I'm going to be making some guesses based on what I see, so please feel free to correct me or ignore me.

A) It looks like you're serving directly from a gStorage bucket (via this https://cloud.google.com/storage/docs/hosting-static-website ?), so I suggest running it through a load balancer following this: https://cloud.google.com/load-balancing/docs/https/adding-a-backend-bucket-to-content-based-load-balancing (and adding ssl on your way through)

B) If, instead, you already have a load balancer on the front end (something like this? https://cloud.google.com/load-balancing/docs/https/adding-a-backend-bucket-to-content-based-load-balancing), I'd suggest adding a custom ssl certificate by following the ssl parts of this guide: https://cloud.google.com/load-balancing/docs/https/content-based-example#configuring_the_load_balancing_service

Remarks
Again, this is a lot of guessing based on what I'm seeing and I could be completely wrong in my "Suggested fix" section. Let me know if I can help in any way!

Perhaps:

BUCKET=${CLOUDSDK_CORE_PROJECT}

Since that should preserve uniqueness (and keeps it simple)

https://cloud.google.com/deployment-manager/docs/

I think everything in setup.sh can be expressed as a deployment in YAML, then refreshing everything would just be a single gcloud invocation. That might also make it easier to schedule a periodic refresh to ensure up-to-date VM images.

Periodically ping between regions and record latency somewhere (BigQuery too?).

I think it may be broken.

ping:1 GET http://35.186.221.153/ping 502 (Bad Gateway)
Image (async)
(anonymous) @ (index):316
104.155.201.52/ping:1 GET http://104.155.201.52/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
104.198.86.148/ping:1 GET http://104.198.86.148/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
35.220.162.209/ping:1 GET http://35.220.162.209/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
35.200.186.152/ping:1 GET http://35.200.186.152/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
34.65.3.254/ping:1 GET http://34.65.3.254/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
35.198.10.68/ping:1 GET http://35.198.10.68/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
104.197.165.8/ping:1 GET http://104.197.165.8/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
104.196.161.21/ping:1 GET http://104.196.161.21/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
35.186.168.152/ping:1 GET http://35.186.168.152/ping net::ERR_CONNECTION_TIMED_OUT
Image (async)
(anonymous) @ (index):316
104.199.116.74/ping:1 

https://github.com/ImJasonH/gcping/blob/master/config.js

Is it allowed for other project to use the URLs for latency checking?

https://github.com/inada-s/gdxsv
We have a gaming server which dynamically allocate Google Cloud Compute Engine for players, and I'm seeking the possibility to know the latency between players and server first, before allocating the server successfully.

Thanks!

ERROR: (gcloud.compute.networks.create) mode has been removed. Please use subnet-mode instead.

Before

# Create network with subnets and firewall rule..
  gcloud compute networks create $NETWORK_NAME \
    --mode=custom \
    --description="Non-default network"

After

# Create network with subnets and firewall rule..
  gcloud compute networks create $NETWORK_NAME \
    --subnet-mode=custom \
    --description="Non-default network"

https://github.com/ImJasonH/gcping/blob/2301d893339bf801b33e6826ec60d95099edfd19/setup.sh#L34

index.html references endpoints from (I assume) gcping-1369 rather than the user's project:

const _URLS = {
  'gce-us-central1':          'http://104.197.165.8/ping',
  'gce-us-east1':             'http://104.196.161.21/ping',
  'gce-us-east4':             'http://35.186.168.152/ping',
  'gce-us-west1':             'http://104.199.116.74/ping',
  'gce-europe-west1':         'http://104.199.82.109/ping',
  'gce-europe-west2':         'http://35.189.67.146/ping',
  'gce-asia-east1':           'http://104.155.201.52/ping',
  'gce-asia-northeast1':      'http://104.198.86.148/ping',
  'gce-asia-southeast1':      'http://35.185.179.198/ping',
  'gce-australia-southeast1': 'http://35.189.6.113/ping',
  'gce-global':               'http://35.186.221.153/ping',
}

Ask user to opt-in, ask for JS geolocation, record coarse latlng, region, latency and time. Might enable some kind of interesting analysis if there are enough datapoints.

When loading gcping for the first time, some locations take 1s+ to return, because they weren't running before I hit them and Cloud Run had to start them up.

It would be nice if the initial cold start request was somehow signalled to the client and could be ignored or retried to get more accurate data. This wouldn't improve the actual experience of loading the page for the first time, but it might help reduce confusion seeing a 1s+ latency then having it immediately be replaced by a 100ms result the next time around.

I tried to do this in 279c799 but it doesn't seem to actually work. The X-First-Request header isn't being seen by the client.

Though it's an easy solution to implement, the service shouldn't be running 24/7 with min-instances (💰💰💰), so some cold start is inevitable.

The service is about as minimal as possible, so I don't think it's worth exploring how to reduce that much right now.