Cloud Ping | Hacker News Reader

Cloud Ping

awsping.com

62 pointsmleonhard27 comments

Just an FYI. To the best of my knowledge Amazon does not permit the use of their trademarked services within the domain of the URL. I'm working on a project that augments EC2 and ended up having to change my domain name to err on the side of caution.

IANAL but do checkout http://aws.amazon.com/trademark-guidelines/ and read section 9 and section 11.

Thanks for pointing this out. I just renamed the site to cloudping.info.

Would pg or another admin be so kind as to change the URL to http://www.cloudping.info/ ?

You should be able to do a URL redirect from http://awsping.com/ to http://www.cloudping.info/ for now.

Cool tool btw!

Thanks! Redirect added.

I originally wrote the HTTP ping tool for this blog entry: http://blog.restbackup.com/how-to-use-amazon-ec2-as-your-des...

But Posterous doesn't allow JavaScript, so I had to cut it out. Today I decided to put it online and try out several technologies:

  * My DNS Registrar's domain forwarding feature, to forward
    http://awsping.com/ to http://www.awsping.com/
  * Amazon S3's new index document feature
  * Amazon CloudFront

I'm happy to say that they all work great. But the ping script doesn't work in Opera.

I'm also trying out Google Analytics for the first time. I'm still waiting for some data to show up in Analytics. They say it can take 24 hours.

Capturing and recording these latency measurements and associating them with the user's location would be fairly easy with MaxMind's free GeoIP databases and Apache module mod_geoip.

This is a pretty awesome tool.

You should consider recording everyone's times + their IP/Location. Displaying that information would be very cool.

You can sort of get that from: http://www.cloudelay.com/cdn-cloudfront.htm

There doesn't seem to be any information on how the map is generated unfortunately. I suppose DUB2 is Ireland, NRT4 Japan, SIN2 Singapore, IAD2 Virginia, and SFO4/LAX1 California.

The locations are based on airport codes.

we do that for 233 countries and 32,000 networks: http://cedexis.com/data/charts.html?country=223&provider...

We also throw away the end-user IP.

Yes, the best way to do that is by using tracking script in websites.

How are you getting around same-origin-policy issues with this script? I noticed the javascript debugger is reporting failures for every request: "Origin http://www.cloudping.info is not allowed by Access-Control-Allow-Origin.". Are you just counting on the request failing, but recording the time that it takes to do so anyway?

I'm using jQuery's ajax() function to make the request. The same origin policy prevents the script from receiving the data returned by the request or even seeing whether it succeeded or not. But timing is not hidden, so I can see how long the request takes.

Personally, I think JavaScript in the browser is a really ugly way to program. What could have been a simple loop or tail-recursive iteration over a list ended up requiring three continuations.

I just created a very similar http-based ping based on this, but with the following difference:

* Use JSON-P to avoid same-origin-policy request failures (this also fixed the Opera failures) * Repeat request 6 times (1 warmup + 5 measured) and display mean, median, min and max latency measurements * Allow ping against 40 different provides including 4 AWS regions

http://cloudharmony.com/ping

This is really very interesting.

My best ping time is 41ms to the Europe region. But a typical ping to our colo servers is 18ms. AWS isn't a high performance option.

Unless all of your users are working from your desk, you're 'typical ping' is worthless.

This ping tool would be far more valuable if you could see the ping times from different clients over time. Then you could actually make a judgement call if AWS is or isn't a high performance option.

Sorry, my phrasing was unclear. My AWS ping time is from my desk, the "typical ping" to our colo is from anywhere in the south of the UK where all our clients are.

Since you'll probably run these tests several times to get a true picture, it'll be helpful if the previous results are not over-written in the UI when the tests are run again.

This is great, very close approximation to actual latency. We had a similar need on our cloud speedtest http://cloudharmony.com/speedtest and implemented using a Java applet that executed and screenscraped an OS ping to capture latency. We've been wanting to replace this with a less intrusive javascript approach.

It seems the tool is broken. In Europe, I get 6 ms to Ireland, but 1 ms to asia. I have been pinging my nearest hop, and I get 100-300 ms, with a lot of packet loss. I'm on really flaky wifi, and I think your ping returns 0ms when no result?

It might be possible

Yeah, some failures are not detected as failures. When failures happen instantly, you get impossibly low timings.

Please feel free to play around with the source code and see if you can improve it. I'd be glad to merge your diff.

Are you behind a proxy server by any chance?

Nice tool! It is the perfect addition to this AWS load time test: http://www.alertfox.com/Tools/LoadTime/

This is great. It would also be nice to see ping time to S3 vs CloudFront.

of similar nature (for CloudFront locations): http://www.cloudelay.com/cdn-cloudfront.htm

Reply on news.ycombinator.com