From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: CDN Test Results - Should We Continue Using a CDN? Date: Tue, 12 Mar 2019 14:38:39 +0100 Message-ID: <877ed4dxgg.fsf@gnu.org> References: <87d0my1380.fsf@gmail.com> <87sgvssycz.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 ([209.51.188.92]:59780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3hpJ-000423-GG for guix-devel@gnu.org; Tue, 12 Mar 2019 09:52:19 -0400 In-Reply-To: <87sgvssycz.fsf@gmail.com> (Maxim Cournoyer's message of "Mon, 11 Mar 2019 20:57:48 -0400") 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: Maxim Cournoyer Cc: guix-devel@gnu.org Hi Maxim, Maxim Cournoyer skribis: > Pardon me for asking, but how does using a CDN frees up resources? > Aren't the usual infrastructure preserved (e.g., ci.guix.info)? It > seems it'd be an extra layer to maintain? One of the motivations for this is that berlin.guixsd.org aka. ci.guix.info is a single machine, the head of our main build farm. If that machine goes down, we have no substitutes. Having a cache like a CDN provides some redundancy: if the build farm goes down, we=E2=80=99ll = at least still have cached substitutes, which leaves us time to fix the build farm. We can have a cache that=E2=80=99s not a CDN, like we did with mirror.hydra.gnu.org, which runs an nginx caching proxy for hydra.gnu.org. However, that=E2=80=99s another machine to take care of (th= at=E2=80=99s not much work in practice, but still, we must be able to quickly respond to outages), and another single point of failure. > The heaviest bandwith usage appear to originate from areas already well > served by the current infrastructure (mirror.hydra.gnu.org -> North > America, ci.guix.info -> Europe), so I'm not sure spending resources on > a CDN is worthwhile in this context. I think the good bandwidth is the second motivation for the CDN, but it=E2=80=99s true that it still benefits the same groups of people; in particular we know that Cloudfront is unavailable in China. Nevertheless the extra performance is welcome IMO. I think substitute delivery plays an important role in the user experience so if we can improve it, the better. > I'd rather see this (even modest) amount put into the hands of a > motivated hacker to work on a distributed solution instead of > encouraging a company which do not share our free software ideals. As discussed before, I definitely sympathize with this. Heck, if someone had told me I=E2=80=99d argue in favor of a CDN after all this time spent filling in CloudFare CAPTCHAs just because CloudFare decided that user privacy doesn=E2=80=99t matter and that Tor users should be penalized,= I=E2=80=99d have laughed. ;-) So it=E2=80=99s definitely not an easy decision. Nevertheless, we have to acknowledge the fact that our current substitute delivery infrastructure is fragile. If people volunteer to maintain a set of mirrors with some load balancing, that=E2=80=99s great, I=E2=80=99m all for it. But for now,= we don=E2=80=99t have that at all, hence the CDN. Longer term, I do hope for IPFS to become our main delivery mechanism. I=E2=80=99ve posted a proof-of-concept that I think should allow us to get started, play with the idea, and find out how that works in practice. Thanks, Ludo=E2=80=99.