12 ms·
Noticing when an app is only hosted in us-east-1
- rozenmd 3y agoIt shows up if you need a CDN pretty clearly when you monitor uptime from around the world. The response time for Bitbucket for example is: 100ms from us-east 300ms from us-west 400ms from eu-central 600ms from tokyo 800ms from sydney (numbers from OnlineOrNot)
- sk0g 3y agoIronic for an Australian co's GitHub alternative to be less responsive than GitHub itself in Australia.
- re-thc 3y agoAdd to that Github is also in the same region as Bitbucket.
- deleted 3y ago[deleted]
- rozenmd 3y agoGitHub appears to distribute their traffic between us-east and eu-central: US East (N. Virginia) 62ms 200 OK Europe (Frankfurt) 62ms 200 OK US West (N. California) 175ms 200 OK Asia Pacific (Sydney) 359ms 200 OK Asia Pacific (Tokyo) 662ms 200 OK
- re-thc 3y agoWhat happened to Tokyo? :(
- rozenmd 3y agoActually I just built a tool to visualise this if you want to check it out: https://onlineornot.com/do-i-need-a-cdn?url=https://bitbucket.org/ https://onlineornot.com/do-i-need-a-cdn?url=https://bitbucke...
- citrin_ru 3y agoDo they test full rendering time or only RTT? Also it would be useful to know IP addresses from which test request are being made. Tested a site hosted in Hetzner and got 135ms latency from Frankfurt which is unexpectedly high. Ping RTT from some US east networks to this site is around 120-150ms, how it shows the same latency within DE?
- rozenmd 3y agoJust RTT - it downloads the whole webpage content (equivalent of running curl <url>) I run the checks via AWS Lambda for now, might put it somewhere more stable like Hetzner/DigitalOcean for better accuracy.
- h1fra 3y agoNice, thanks for showing it! I tested on my sass that has a CDN and got scared a little bit, but then did a second call and cache hit everywhere, thank god.
- jwally 3y agoI'm dense and just saw this. Its awesome fwiw! If you could do something simple in the style of POSTMAN, but with less options - I'd pay fwiw. Not a lot, but if it existed - I'd want it! Send a POST request to ${url} with ${headers} and ${body} and tell me how long it took from your servers...that'd be awesome!
- rozenmd 3y agoThat's actually a feature of the underlying platform I work on: https://onlineornot.com/api-monitoring https://onlineornot.com/api-monitoring If it doesn't quite match what you expect I'd be happy to add additional features!
- jrockway 3y agoThe speed of light in a fiber optic cable is slower than light in a vacuum, about 2.14e8 m/s. If you feel latency, it's probably not the one-direction or round-trip latency, but rather the MANY round trips that are typically required for an HTTP request. DNS is probably 2 round trips (CNAME then A), and that has to cross the ocean via your resolver of choice (8.8.8.8 or whatever) to get to the authoritative server if it's not already cached (or distributed; big DNS providers will serve your zone in many regions). Then you have to set up a TCP session, which is 1.5 round trips. Then you have to set up TLS, which varies, and make an HTTP request, and wait for the response. (I counted 5 total round trips until you see the response.) So basically if you calculate the speed of light between two points, multiply that by 2*(2+5) = 14 in the worst case to see your time to first byte. Doing something 14 times is always going to be slow. The underlying issue here is not so much the distance, but rather that TCP, TLS, and HTTP don't care about latency at all. (I'll ignore the application layer, which probably wants to redirect you to /verify-session-cookie and then /hey-you-logged-in for some reason. And yes, TLS1.3 has 0RTT handshakes now too, eliminating some trips.) This is the problem that HTTP/3 aims to fix; one round trip replaces the TCP handshake, TLS handshake, and HTTP request. You shoot out a packet, you get back an HTTP response. (You still have to do the DNS lookup, so we'll call this 3 round trips total.)
- re-thc 3y ago> DNS is probably 2 round trips (CNAME then A), and that has to cross the ocean via your resolver of choice I hope your DNS doesn't have to do that. Most anycast DNS should have lots of PoPs (regions) and are really fast. CDNs usually solve a lot of the static asset issues. The main issue is the database.
- kiwijamo 3y agoPeople should use their ISP's DNS as well which is often <5ms. I've never bothered using an off-net DNS provider for this reason given how much faster is it to use an on-net caching DNS resolver provided by my ISP.
- 3y ago
- Rauchg 3y agoGood article! I always notice this same effect when I visit my parents in Argentina or I'm in Europe. > Using a global CDN can help get your assets to your users quicker, and most companies by this point are using something like Cloudflare or Vercel, but many still only serve static or cached content this way. Very frequently the origin server will still be a centralized monolith deployed in only one location, or there will only be a single database cluster. Notably: even if the source of truth is single-region, there's a lot that can be done to improve the experience by flushing parts of the page at the edge. Check out https://how-is-this-not-illegal.vercel.app/ https://how-is-this-not-illegal.vercel.app/ where the layout.tsx[1] file is edge-rendered right away with placeholders, and then the edge renderer streams the content when the single-region database responds. Furthermore, consider that parts of the page (like the CMS content) can also be cached and pushed to the edge more easily than, say, a shipping estimate or personalized product recommendations, so you can have content as part of that initial placeholder flush. We have an e-commerce example that shows this[2]. [1] https://github.com/rauchg/how-is-this-not-illegal/blob/main/app/layout.tsx https://github.com/rauchg/how-is-this-not-illegal/blob/main/... [2] https://app-router.vercel.app/streaming/edge/product/1 https://app-router.vercel.app/streaming/edge/product/1
- mabbo 3y agoAnother way that a global cdn helps is that your HTTPS negotiation takes place closer by. There are (in http 1.1 at least) many back and forth steps to negotiating the HTTPS connection, the encryption key, etc. A global cdn into a cloud service (CloudFront is the example I know best) lets the user do those back and forths with a server very close to them, then handle the long haul to where the request is handled in one round trip. Eg: putting CloudFront in front of your API calls can make them faster! Great video by slack on the topic: https://m.youtube.com/watch?v=oVaTiRl9-v0 https://m.youtube.com/watch?v=oVaTiRl9-v0
- TekMol 3y agoI don't buy this. Hacker News is one of the most responsive websites I know. And it is run on a single server somewhere in the USA. While I am in Europe. If you have users in Sydney, Australia ... ... you are floored at 104ms of latency for your request When I open AirBnB with a clean browser cache, it takes several seconds until I see something useful. Those 104ms of latency don't make a dent. Reddit takes over 5 seconds until the cookie banner is ready for me to click it away. Twitter takes 6 seconds to load the homepage and display the single tweet which fits on it. preview images take a little longer to load Preview images of what? Images usually should be routed through a CDN which caches them directly in the user's country. It's extremely cheap and easy to set up. Nothing compared to running an application in multiple datacenters.
- progval 3y agoBrowsing HN only needs one round-trip (fetch the HTML), maybe two if you don't have it cached (fetch the CSS). Many apps need more round-trips, by loading assets sequentially. For example: fetch the HTML, then the JS, then the JS downloads its config, then the JS fetches some assets. Latency accumulates with every round-trip.
- TekMol 3y agoNo, HN is not just one request, it is 7. And no, latency does not accumulate. Because the browser requests assets in parallel as it loads the html. Also, assets can easily be routed through a CDN.
- senttoschool 3y agoTrue and not true. In modern apps, there's often additional assets loaded from Javscript calling endpoints or calling for more assets. If you do server side rendering, there are usually fewer roundtrips.
- samwillis 3y agoLatency absolutely does accumulate for code as the parent described that cannot make a request until the previous one has returned (images linked from css files for example, or a spa with poorly chunked code). There is a lot of that code out there. "Modern" tooling and practices reduce that, but it not a solved problem for the majority of legacy code.
- snailtrail 3y ago[flagged]
- aerio 3y agoSounds like you didn't read the article properly and missed the authors argument that using CDN's are more important than people think. Better luck next time!
- ketchupdebugger 3y agoThe author is not correct though, as with any webapp these are not static content that you can host on a cdn. These are dynamic content that needs to be loaded. Adding a mutliregion architecture is complicated. As a side note, I also know which apps are hosted on us-east-1. I just need to look at the us-east-1 aws incident from last month and which apps were affected.
- r24y 3y agoThis article brought to mind a different but related scenario. I live on an island that was recently affected by a typhoon. Internet speeds are usually pretty good, but in the aftermath of the storm cable internet has been up-and-down depending on the day, and the cell towers are very spotty. I've found that most modern apps depend on a high-speed connection, and give a very poor experience otherwise. Of course this seems obvious in hindsight, but it's a different experience living through it.
- js2 3y agoI've been doing this long enough that I remember when all the big web sites were hosted in California. In fact, my company had its web farm in Sunnyvale which we managed over frame relay from Atlanta. Whenever I'd visit the west coast, I was shocked how much faster the web seemed. So I sympathize with the sentiment. Thing is though, the entire web feels pretty sluggish to me these days. And that's with us-east-1 less than 300 miles away from me. Because most web sites aren't slow due to where they're hosted, but rather because of how bloated with crap most of them have become.
- StanislavPetrov 3y ago>Sunnyvale https://www.retro-gaming.it/videogiochi_img/movie_wargames/wargames16.jpg https://www.retro-gaming.it/videogiochi_img/movie_wargames/w...
- deleted 3y ago[deleted]
- lordnacho 3y ago> Thing is though, the entire web feels pretty sluggish to me these days. And that's with us-east-1 less than 300 miles away from me. Because most web sites aren't slow due to where they're hosted, but rather because of how bloated with crap most of them have become. It doesn't seem much faster than it seemed in 1995 when I first got online. There's much more stuff, but the latency doesn't really seem much better. It's probably commercial: people don't mind wasting 3-4 seconds at a time loading Reddit/FB/etc and in that time a whole bunch of code that's useful to the website operator is loaded. All the stuff that tracks what you're up to.
- sgt 3y agoI've even seen sites that don't load properly or aren't usable before the cookie banner renders, which may be loaded inefficiently from somewhere else. It's tragic!
- lionkor 3y agoIf you want a smooth experience that is easy to set up, you can provide a download link (gasp) and serve that over a CDN, and just have your app be native. You'll only pay for backend queries, not for every single button style
- rahimnathwani 3y agoRelated: https://news.ycombinator.com/item?id=36506865 https://news.ycombinator.com/item?id=36506865 Particularly the part quoted in this comment: https://news.ycombinator.com/item?id=36507013 https://news.ycombinator.com/item?id=36507013 But tbh I think this is mainly a problem for apps that have a long chain of dependent requests. If you make 3 requests one after the other, it's probably fine. If the DOM isn't stable until after a series of 10 requests, any amount of latency is noticeable.
- the_mitsuhiko 3y agoI mostly notice edge hosted apps as a problem now. Some newfangled sites have horrible cold start times if they are not too busy in Europe.
- rightbyte 3y agoOh the hubris of adding another level of indirection ... or maybe it is layer of abstraction. Not sure.
- shubhamgrg04 3y agous-east-1 is the Silicon Valley of cloud regions. Overcrowded yet irresistible!
- londons_explore 3y agoAs a European, visiting the USA, you certainly find that most of the internet just works better. However I think a bug chunk of the effect is that European mobile networks seem to take a second or two to 'connect' - ie. If you take your phone from your pocket and open an app, the first network request takes 2-3 seconds. Whereas for whatever reason, the same phone in the USA doesn't seem to have such a delay.
- deleted 3y ago[deleted]
- chrismsimpson 3y agoTo counter the top comment at the moment, being from Sydney, Australia, I totally do buy it. It also works both ways, if you want to build something with global reach but host it locally you’re immediately going to be penalised by the perceptions that come with latency. Also, I might add that the latency builds up non linearly the more throughput you’re attempting to achieve (e.g. streaming video). Disclaimer: I am currently working for a startup attempting to build a video creation and distribution platform with global reach.
- landgenoot 3y agoI think the peering agreements of the local ISP are likely to be a factor as well. When I moved inside Europe I suddenly noticed slow connections to Github pages. I expected that it had something to the physical location of the Github pages servers. However, when I connected to the VPN of my previous location it all was snappy again. That eliminated the physical distance as a cause.
- dncornholio 3y agoFunny, I can pinpoint players location based on their pings pretty accurately too. 300ms + is Asia, 350+ is Australia, Americans are 120+, South America 170+. Ping towards USA has lowered the most. This used to be 225ms in the earlier online days.
- 867-5309 3y agono mention, or realisation, of the storage and bandwidth requirements for hosting anything other than text. html, js and database queries are cheap to stick on a global CDN, but when it comes to larger multimedia files, such as images and videos, the costs soon skyrocket
- Jamie9912 3y agoEven if you have gigabit in Australia, the latency when browsing Youtube and clicking through menus is a world of difference when you compare it to the US
- marcyb5st 3y agoIs it the same while watching videos (i.e. a lot of buffering or similar)? I thought that YT caches popular content close to end users [1]. [1] https://peering.google.com/#/infrastructure https://peering.google.com/#/infrastructure -> Under the edge nodes part
- sargun 3y agoAFAIK, there is no generic datastore that does multi-region, with moving around the leader for a given subset of data available. Something like what's written in the Spanner paper would be amazing (microshards, and moving around microshards based on user access) if it was accessible.
- thih9 3y agoThere’s also the device speed. It might provide a different reference point for different users. If you’re opening a website on a low end smartphone with an outdated system, the network latency might be not noticeable (because the UX of the device is so slow anyway).
- SergeAx 3y agoFunny enough, the blog is not opening for me at all, despite being a static side, which should be proxied via CDN all the time.
- burntcaramel 3y agoAs an Australian, I agree that I usually prefer when a service is hosted nearby. Yet… 200ms latency, that’s pretty good actually. For some real data, I just tried `ping ec2.us-east-1.amazonaws.com` and time is 240ms. That’s in Tasmania, NBN over Wifi. I’m happy with that! But the problem, like many of the other commenters are saying, is for a single request us-east-1 is actually fine. But for a modern web app but many requests, that compounds real quick. I actually think living here is an advantage as a web developer because it’s like those athletes that only train at high altitudes — living in a high latency environment means you notice problems easily.
- sgt 3y agoThat puts things into perspective for us in South Africa*. My RTT to Europe is about 170-180ms. It used to be a bit better, not sure what happened. But the point is that it's just barely within what I would consider "fast" in relation to Europe. (*) Similar to AU, we're also in the middle of "nowhere"
- mduggles 3y agoIt’s a solvable problem if you optimize for multiple regions from day 1 of the app but migrating an existing stack to multi-region after the fact is often a large enough undertaking that you pick the region of the majority of users and go with it. The process of setting up an active passive region with the db is becoming more common but an active/active design is still relatively rare outside of apps designed for massive scale.
- reportgunner 3y agoI think this is mainly a (first world) problem for americans using american websites when they are abroad.
- preinheimer 3y agoFor more pings check out: https://wondernetwork.com/pings https://wondernetwork.com/pings I believe that’s the source he’s using.
- neurostimulant 3y agoI usually get ~300ms ping from my home to us-east-1. You can absolutely feel the latency, especially on SPAs that performs many small xhr sequentially which compounds the latency even more. Apps that felt almost instant when used in network with <10ms latency are suddenly felt pretty sluggish. Some of my worst experience was being forced to use SFTP to transfer thousands of small files to a server in us-east-1, which can take hours due to latency alone compared to transferring the same set of files using rsync / compressed archive which finish in minutes, and using RDP to access a remote windows machine behind a VPN, then run putty there to access a Linux server (the VPN only allows RDP traffics), and then I need to transfer thousands of files to the Linux server as well (my solution was to punch a hole through their shitty VPN via an intermediary bastion host I fully control, which allows me to use rsync).
- withinboredom 3y agoI remember when we first moved to the cloud from a datacenter. It was in us-east-1, and literally the day after the switch over (before we started configuring multi-region) was the first time us-east-1 had its major outage. The owners were pissed that it had gone down and it wasn't that it went down, it was that we were basically sitting around with our thumbs up our ass. When things went down in our DC, we just fixed them or at least we could give an ETA until things went back to normal. We had absolutely nothing. We couldn't access anything, and AWS was being slow in acknowledging an issue even existed. That was a good lesson that day: the cloud is not necessarily better.
- makeworld 3y ago> In reality, the ping you’ll experience will be worse, at around 215ms (which is a pretty amazing feat in and of itself - all those factors above only double the time it takes to get from Sydney to the eastern US). Isn't it double just because ping measures round trip time?
- josephcsible 3y agoNo, that was already accounted for. 52ms is the one-way time and 104ms is the round-trip time in the theoretical best case.
- jwally 3y agoDoes anyone know of an out-of-the-box solution for measuring regional latency? If not, please somebody make and productize it. I'd love to know how my sites behave in Frankfurt, Mumbai, SF, Sydney, etc.
- RGBCube 3y agoNgl, a website where you input a URL and it checks the latency around the world would be interesting. Bonus points for tying to guess where it's hosted.
- jwally 3y agohttps://onlineornot.com/do-i-need-a-cdn?url=https://www.google.com https://onlineornot.com/do-i-need-a-cdn?url=https://www.goog... Is pretty interesting. If someone set up a postman style clone, but I could drop-down and run it from a server in ${wherever} - that might be worth something...?
- RGBCube 3y agoThat is great, almost what I was imagining. I think it needs more places to ping from and a map in the webpage. Suggestions aside, look at the difference between HN and Google (measured in milliseconds): us-east: 39 HN, 40 GGL us-west: 128 HN, 118 GGL europe: 186 HN, 109 GGL tokyo: 291 HN, 143 GGL sydney: 405 HN, 303 GGL Kind of interesting, did not expect Googles latency to be that high in Sydney.
- throwawaymobule 3y agoThe tab of browser devtools that let you simulate slow connections should probably add simulation of this kind of latency, as well as a 'simulate AWS outage' toggle if that's even possible. (don't know enough DNS to know how hard the latter is) I guessed from the title that this would focus on redundancy, but I guess that's rarely noticable.