From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: CDN performance Date: Sun, 09 Dec 2018 16:59:13 +0100 Message-ID: <871s6qzo6m.fsf_-_@gnu.org> References: <20181203154335.10366-1-ludo@gnu.org> <87tvju6145.fsf@gnu.org> <87ftv7l6gy.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gW1UL-0003Gg-U3 for guix-devel@gnu.org; Sun, 09 Dec 2018 10:59:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gW1UH-0007GH-BE for guix-devel@gnu.org; Sun, 09 Dec 2018 10:59:25 -0500 In-Reply-To: <87ftv7l6gy.fsf@gmail.com> (Chris Marusich's message of "Sat, 08 Dec 2018 19:33:17 -0800") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: Hartmut Goebel , guix-devel@gnu.org, 33600@debbugs.gnu.org Hello Chris, Chris Marusich skribis: > Regarding DNS, it would be nice if we could use an official GNU > subdomain. If we can't use a GNU subdomain, we should at least make > sure we have some kind of DNS auto-renewal set up so that nobody can > poach our domain names. And the operators should take appropriate > precautions when sharing any credentials used for managing it all. Agreed. Regarding the GNU sub-domain, as I replied to Meiyo, I=E2=80=99m in favor o= f it, all we need is someone to champion setting it up. > Regarding CDNs, I definitely think it's worth a try! Even Debian is > using CloudFront (cloudfront.debian.net). In fact, email correspondence > suggests that as of 2013, Amazon may even have been paying for it! > > https://lists.debian.org/debian-cloud/2013/05/msg00071.html (Note that debian.net is not Debian, and =E2=80=9Cthere=E2=80=99s no cloud,= only other people=E2=80=99s computer=E2=80=9D as the FSFE puts it.) > Although I don't doubt that a CDN will perform better than what we have > now, I do think it would be good to measure the performance so that we > know for sure the money spent is actually providing a benefit. It would > be nice to have some data before and after to measure how availability > and performance have changed. Apart from anecdotes, what data do we > have to determine whether performance has improved after introducing a > CDN? For example, the following information could be useful: > > * Network load on the origin server(s) > * Clients' latency to (the addresses pointed to by) ci.guix.info > * Clients' throughput while downloading substitutes from ci.guix.info Note that performance is one aspect; another one is availability (we=E2=80= =99ve seen that with the recent hydra.gnu.org outage!). We know we=E2=80=99ll al= ways win in terms of availability by having a CDN in front of our servers. That said, measuring performance is very useful and it=E2=80=99s great that= we can benefit from your expertise here! > Here, it took 0.459667 - 0.254210 =3D 0.205457 seconds (about 205 ms) to > establish the TCP connection after the DNS lookup. The average > throughput was 1924285 bytes per second (about 40 megabits per second, > where 1 megabit =3D 10^6 bits). It seems my connection to berlin is > already pretty good! Indeed. The bandwidth problem on berlin is when you=E2=80=99re the first to download a nar and it=E2=80=99s not been cached by nginx yet. In that case= , you get very low bandwidth (like 10 times less than when the item is cached by nginx.) I=E2=80=99ve looked into it, went as far as strace=E2=80=99ing = nginx, but couldn=E2=80=99t find the reason of this. Do you any idea? > Establishing the TCP connection took about 21 ms (which matches the mtr > output), and the throughput was about 79 megabits per second. (On this > machine, 100 Mbps is the current link speed, according to dmesg output.) > This means that in my case, when using CloudFront the latency is 10x > lower, and the throughput (for a cache hit) is 2x higher, than using > berlin.guixsd.org directly! Impressive. > It would be interesting to see what the performance is for others. I=E2=80=99ve tried this from home (in France, with FTTH): --8<---------------cut here---------------start------------->8--- $ measure_get https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz= 2s5yac-linux-libre-4.19 2>/dev/null url_effective: https://berlin.guixsd.org/nar/gzip/1bq783rbkzv9z9zdhivbvfzhs= z2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 141.80.181.40 remote_port: 443 size_download: 69899433 B speed_download: 1522001.000 B/s time_appconnect: 0.178892 s time_connect: 0.049649 s time_namelookup: 0.000422 s time_pretransfer: 0.178934 s time_redirect: 0.000000 s time_starttransfer: 0.278312 s time_total: 45.926021 s $ measure_get https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zd= hivbvfzhsz2s5yac-linux-libre-4.19 2>/dev/null url_effective: https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9z= dhivbvfzhsz2s5yac-linux-libre-4.19 http_code: 200 num_connects: 1 num_redirects: 0 remote_ip: 2600:9000:2116:6e00:c:49d4:5a80:93a1 remote_port: 443 size_download: 69899433 B speed_download: 20803402.000 B/s time_appconnect: 0.552008 s time_connect: 0.482477 s time_namelookup: 0.467598 s time_pretransfer: 0.552157 s time_redirect: 0.000000 s time_starttransfer: 0.735758 s time_total: 3.360500 s --8<---------------cut here---------------end--------------->8--- Wall-clock time is less than a tenth; woow. Thanks for sharing your insight and scripts! Ludo=E2=80=99.