From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: CDN performance Date: Thu, 13 Dec 2018 00:05:06 -0800 Message-ID: <87y38tx365.fsf@gmail.com> References: <20181203154335.10366-1-ludo@gnu.org> <87tvju6145.fsf@gnu.org> <87ftv7l6gy.fsf@gmail.com> <871s6qzo6m.fsf_-_@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXLzm-0007ld-8X for guix-devel@gnu.org; Thu, 13 Dec 2018 03:05:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXLzg-0000wa-2i for guix-devel@gnu.org; Thu, 13 Dec 2018 03:05:22 -0500 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: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Hartmut Goebel , guix-devel@gnu.org, 33600@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s writes: > Regarding the GNU sub-domain, as I replied to Meiyo, I=E2=80=99m in favor= of it, > all we need is someone to champion setting it up. I could help with this. Whom should I contact? >> 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 clou= d, only other > people=E2=80=99s computer=E2=80=9D as the FSFE puts it.) I do try to avoid the term "cloud" whenever possible. It's hard to avoid when it's in the product name, though! A wise man once said, "A cloud in the mind is an obstacle to clear thinking." ;-) You may be right about debian.net. I don't know who owns that domain. It's confusing, since debian.org is definitely owned by the Debian project, and the following page says they're using Amazon CloudFront: https://deb.debian.org/ Maybe Debian still uses Amazon CloudFront, or maybe they don't any more. In any case, I've found the following email thread, which documents a thoughtful discussion regarding whether or not Debian should use a CDN. They discussed many of the same concerns we're discussing here. https://lists.debian.org/debian-project/2013/10/msg00029.html A summary, in the middle of the long thread, is here: https://lists.debian.org/debian-project/2013/10/msg00074.html Later, part of the thread broke off and continued here: https://lists.debian.org/debian-project/2014/02/msg00001.html That's as far as I've read. Judging by that email thread, one of the reasons why Debian considered using a CDN was because they felt that the cost, in terms of people power, of maintaining their own "proto-CDN" infrastructure had grown too great. I believe it! I think it would be ill-advised for the Guix project to expend effort and capital on building and maintaining its own CDN. I think it would be wiser to focus on developing a decentralized substitute solution (GNUnet, IPFS, etc.). That said, I still think that today Guix should provide a third-party CDN option. For many Guix users, a CDN would improve performance and availability of substitutes. Contracting with a third party to provide the CDN service would require much less effort and capital than building and maintaining a CDN from scratch. This would also enable the project to focus more on building a decentralized substitute solution. And once that decentralized solution is ready, it will be easy to just "turn off" the CDN. I also understand Hartmut's concerns. The risks he points out are valid. Because of those risks, even if we make a third-party CDN option available, some people will choose not to use it. For that reason, we should not require Guix users to use a third-party CDN, just as we do not require them to use substitutes from our build farm. However, not everyone shares the same threat model. For example, although some people choose not to trust substitutes from our build farm, still others do. The choice is based on one's own individual situation. Similarly, if we make a third-party CDN option available and explain the risks of using it, Guix users will be able to make an educated decision for themselves about whether or not to use it. >> 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 ca= se, 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=99in= g nginx, but > couldn=E2=80=99t find the reason of this. > > Do you any idea? I made a typo here. The value "1924285" should have been "4945831", which is what measure_get printed. However, the intended result (40 Mbps) is still correct. Actually, I thought 40 megabits per second was pretty great for a single-threaded file transfer that originated in Europe (I think?) and terminated in Seattle (via my residential Comcast downlink). I requested that particular file many times before that final test run, so it was probably already cached by nginx. However, I believe you when you say that it's slow the first time you download the substitute from berlin. What path does the data take from its origin through berlin? If berlin needs to download the initial file from another server, perhaps the connection between berlin and that server is the bottleneck? Maybe we should discuss that in a different email thread, though. > I=E2=80=99ve tried this from home (in France, with FTTH): > > [...] > > speed_download: 20803402.000 B/s Wow, that's 166 megabits per second! I'm jealous. :-) > Wall-clock time is less than a tenth; woow. I expect others will see similar performance improvements, as long as they are close to the edge locations provided by Amazon CloudFront and their local ISP downlink is fast enough to see a benefit. Again, the edge locations are here: https://aws.amazon.com/cloudfront/features/ Here's a direct link to their current map: https://d1.awsstatic.com/global-infrastructure/maps/CloudFront%20Network%20= Map%2010.12.18.59e838df2f373247d2efaeb548076e084fd8993e.png =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlwSErIACgkQ3UCaFdgi Rp2YSw/8CEe20/+GGK08/1cvQz8VKeoDglWValQLJyFNAsuxhEd7W0f+1l5XNRq3 PZhQEvwffPWeM7l65HVeJH7fzJPk6RDTS20ifLG9SpOQ9Oeb1ER3QxOWg829rz9g h9G/KUyoPp7KZORQFI87BeGPBPhJdYjHRoZOOraYUdZzRU6Ve7dq5drn4f0salVI ZaN7AUs1Qwm18Osv3OEEyFa7uorIM0WpHKtiaYvWORQj/Ly4nz38aoAtSNIwg5ju hSZIt2wqjjIVpxjv2IDe7DsNI2j/9cr2ahFkXZje8sKFLOLPtyGQJDpD3VqM/3L7 LIhUowY0iqgUoe8L/2u5Nyc+wNFmQ3YNTbKTeOEms0e48gFW96KO42ED5GnA5pUf au1g8o2NusA5jYA0GTFDLPwvSc7Go9PY3j9gWOTurVA4CqPfsxrQ2nCLtkQ7KHbW z6ebD8WCusUAWQAVe+byNJ3dQvluK2ZhYektt8IhN5588Ys191ljVJLZ5mBThKdl /OhyzC7GzGehzvl38ohA/tcBYTA9QTA/xQXtZHnpI6wJXcnVByG//wmhwvoAEo+t NMk4cue+GOGTrbG0sQGQz0iv90IcY0EZVngOXRWqJvPl2cgiwmPbIOq2FSF0DAVT WRo1DKyPtVn2NgrkKARZActkPwpjyHvNeoJFO2r6NwZ1sSfW1bU= =kuJA -----END PGP SIGNATURE----- --=-=-=--