3 ms·
Yup, and that's why for thereg we started using Cloudflare's Railgun… with it, the connection to the servers (hosted in the UK) is "bearable"… without, it's aby
by mfontani 10y ago
Yup, and that's why for thereg we started using Cloudflare's Railgun… with it, the connection to the servers (hosted in the UK) is "bearable"… without, it's abysmal:
From a VPS in Sydney, with a Good Enough bandwidth:
root@sydney:~# speedtest-cli 2>&1 | grep -e Download: -e Upload:
Download: 721.20 Mbits/s
Upload: 117.89 Mbits/s
… doing the request through Railgun is "quite bearable":
root@sydney:~# ./rg-diag -json https://www.theregister.co.uk/ | grep -e elapsed_time -e cloudflare_time -e origin_response_time
"elapsed_time": "0.539365s",
"origin_response_time": "0.045138s",
"cloudflare_time": "0.494227s",
Despite our "origin" server being quick enough, the main chunk of time is really "bytes having to travel half the world".
Why does railgun help? Because this is what a user would get otherwise; the "whitepapers" site is hosted in the UK, and doesn't use Cloudflare or Railgun – it only uses Cloudflare for DNS:
./rg-diag -json http://whitepapers.theregister.co.uk/ | grep elapsed_time
"elapsed_time": "0.706277s",
… so that's ~200ms more, and _on http_.
How much would https add, if it were done without Cloudflare's https and Railgun? That's easy to check, as our the whitepapers site has TLS (although admittedly not http/2):
root@sydney:~# ./rg-diag -json https://whitepapers.theregister.co.uk/ | grep elapsed_time
"elapsed_time": "1.559860s",
that's quite a huge chunk of time that Cloudfalre HTTPS + Railgun just saves/shaves for us. Recommend it highly!
- pbarnes_1 10y agoDid you try CloudFlare without Railgun? That would be interesting.
- mfontani 10y agoSure, let's do just that… from the same location in Sydney; origin server hosting the content is in UK. This domain is on their "free" plan, as it gets hardly any traffic. root@sydney:~# ./rg-diag -json https://thereglabs.com/ | grep -e elapsed_time "elapsed_time": "0.863677s", So that's from Sydney to the UK, with https served by Cloudflare. The webapp serving that isn't the sharpest knife in the drawer, but when tested on localhost it replies in 0.015s – the rest is time taken moving bytes across the world. root@sydney:~# time curl -sH 'Host: thereglabs.com' -H 'Cf-Visitor: {"scheme":"https"}' http://THE_ORIGIN_SERVER/ -o/dev/null real 0m0.821s … and this is plain HTTP to the origin server: the free plan is great for offloading HTTPS at basically no cost in time added. We've got another domain on the business plan… so let's try that one. This is an _image_ request, which is _cached by cloudflare at the edge_: root@sydney:~# ./rg-diag -json https://regmedia.co.uk/2016/11/09/hypnotist_magician_smaller.jpg | grep elapsed_time "elapsed_time": "0.239641s", Lovely, the "local caching" of their CDN helps a ton! … compared to if we were to request the same file from the ORIGIN_SERVER over HTTP: root@sydney:~# ./rg-diag -json http://ORIGIN_SERVER/2016/11/09/hypnotist_magician_smaller.jpg | grep elapsed_time "elapsed_time": "0.704458s", … but our "origin server" _also_ is likely to have the image in the "memory cache"… … and that image was likely in their cache; so… let's add a parameter so they _will_ have to ask the origin server: $ pwgen 30 2 Eehacoh2phoo1Ooyengu6ohReWic2I Zeeyoe8ohpeeghie3doyeegoowiCei There you go… two new randomly generated values… root@sydney:~# ./rg-diag -json 'https://regmedia.co.uk/2016/11/09/hypnotist_magician_smaller.jpg?Eehacoh2phoo1Ooyengu6ohReWic2I=Zeeyoe8ohpeeghie3doyeegoowiCei' | grep elapsed_time "elapsed_time": "1.198940s", Yup, took quite a bit longer than the 200ms it took when the image URL was fully in their cache. All in all, from the point of view of being able to _easily_ serve people on the other side of the world with a "good enough" (not great, mind you!) response time, both "standard" Cloudflare, the "pro" offering _and specifically_ the "business" offering are just effin AWESOME.