Use CDN for djangoproject.com

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Tom Forbes

Awesome work! For my location (Lisbon, Portugal) it takes about 130ms to retrieve the HTML for a docs page (https://django-docs.global.ssl.fastly.net/en/2.1/intro/reusable-apps/ to be specific). The same page on docs.djangoproject.com responds in 800–900ms.




On 24 February 2019 at 14:35:55, Tobias McNulty ([hidden email]) wrote:

Hi Tom,

Thanks for your message. I think we'll end up with Fastly since it would be free, but I'm waiting to see their sponsorship contract. CloudFront would work too but I don't know of any such open source sponsorship options with AWS.

I will say wildcard purging looks a bit simpler in CloudFront, but your idea purging the whole cache only for non-dev builds could work (provided we have a lower cache timeout or a single wildcard purge condition set up for the dev builds, I guess).

Feel free to test and post any feedback about Fastly prior to the potential transition here: https://django-docs.global.ssl.fastly.net/en/2.1/ (this is set up on a free dev account, so no custom SSL)

For the sake of comparison I'm working on getting a distribution set up for CloudFront too, but it won't be so simple to test (without a DNS or server configuration change) since I don't think CloudFront supports passing a custom Host header to the origin like Fastly does (i.e., you'll probably need to edit /etc/hosts).

Cheers,
Tobias


On Sat, Feb 23, 2019, 7:15 PM Tom Forbes <[hidden email]> wrote:
Sorry, I did not completely grok your message. I would be in favour of just invalidating the whole cache if needed, it seems the simplest solution. Invalidating most of the cache on every non-dev deploy would also be OK I think.

On Sun, 24 Feb 2019, 00:10 Tom Forbes, <[hidden email]> wrote:
Which CDN are we going to use? Fastly has awesome sub 100ms global invalidation which we can trigger on every deploy, and cloudflare has something similar.

On Sun, 24 Feb 2019, 00:00 Tobias McNulty, <[hidden email]> wrote:
Hi all,

An implementation question has come up regarding cache lifetime (see this PR). Right now, the whole site (including docs) has the site-wide Django cache enabled, with a timeout of 5 minutes. A couple docs views (search_suggestions and search_description) views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except for the release notes section and any (likely minor) related updates to the docs themselves. To get the most benefit out of a CDN, it would obviously be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs is desired, and waiting an hour or more for any cached pages to expire may cause significant confusion, for example, in conjunction with a security release for which stubbed (non-final) release notes may have already been pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any time there's a docs build that has changes. It would be pretty easy to piggyback off of the existing business logic for avoiding a rebuild if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching '/<lang>/<version>/releases/*' and perhaps the development docs) that would keep a shorter cache timeout of 5-10 minutes. All URLs not specifically requiring this special treatment would get a longer timeout, perhaps somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '/<lang>/<version>/releases/' and '/<lang>/dev/' that might update frequently and merit some combination of invalidation and/or a shorter cache time? And what's a good cache timeout for such pages?
* How long are we comfortable waiting for other (not frequently updated) pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty <[hidden email]> wrote:
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C <[hidden email] wrote:
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 1.37s, Load: 1.68s

Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, python.org does in fact use Fastly:

dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a contract which I guess the DSF would need to review and sign, if it's acceptable.

In the meantime, feel free to give this a try and let me know if you see any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for permanent use, obviously; you'll get a cert warning, and some pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in #django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson <[hidden email]> wrote:
I have not had great experience with Fastly in the past and would avoid them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton <[hidden email]> wrote:
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so that DNS alone can decide to hit cdn or origin. 

Anyway, it seems weird to me to dismiss a CDN offhand “because security”. Especially considering the size of the providers and the expertise their teams have. 

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” providers. I would probably go as far to say that putting a CDN in front of both the docs and the release packages would likely be a net improvement in security for users. 

On Thu, 14 Feb 2019 at 21:58, Tom Forbes <[hidden email]> wrote:
That makes sense, but in this case we are only talking about potentially yielding control of the docs subdomain which is not used to serve sensitive build artefacts?

Another option is fastly.com, who support other large open source projects for free. They essentially give you geographically distributed HAProxy instances and you have a lot more control over them. I believe several large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to do this for the whole domain to get any benefit. The Django docs are text/html heavy with very few, if any, images. So the real speed benefit will have to come from serving that, which requires TLS termination (and therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <[hidden email]> wrote:
Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts from the djangoproject.com website. And we would like to ensure that the TLS termination happens by us and not some random service provider. After all, Django is used by enterprises that do have some restrictions on where you're allowed to download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require us to hand over control of DNS, I guess we could be interested in moving the docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and
> re-encrypt all our data). This may be less of an issue for the docs
> site, *if* we don't have to assign DNS authority for the whole domain
> to the CDN provider.
>
> Tobias
>
>
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell <[hidden email] wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <[hidden email]> wrote:
> >> Consider AWS's cloudfront then :)
> >>
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN.
> >>>
> >>> Cheers,
> >>> Florian
> >>>
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >>>> Hi,
> >>>>
> >>>> Is it possible to utilize a CDN service for djangoproject.com, or at least on docs.djangoproject.com? The site is actually quite fast for me but I think there is still room for improvement. Cloudflare sponsored dozens of open source projects <https://developers.cloudflare.com/sponsorships/>, probably they can provide free service for django as well.
> >>>>
> >>>> Tested from Melbourne, Australia:
> >>>>
> >>>> https://www.djangoproject.com/
> >>>>  Average Ping: 245ms
> >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s
> >>>>
> >>>> https://git-scm.com/
> >>>>  Average Ping: 5ms
> >>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 564ms, Load: 699ms
> >>>>
> >>>> Tested on Chrome with "Disable cache" checked (but not the first time visit, so DNS query time might not be included).
> >>>>
> >>>> Best regards and thanks for all your great work.
> >> 
>
>
> >>  --
> >>  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >>  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >>  To post to this group, send email to [hidden email].
> >>  Visit this group at https://groups.google.com/group/django-developers.
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>  For more options, visit https://groups.google.com/d/optout.
> >> 
> > 
>
>
> >  --
> >  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >  To post to this group, send email to [hidden email].
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >  For more options, visit https://groups.google.com/d/optout.
> > 

>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>  To post to this group, send email to
> [hidden email].
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRVHxL82tNOuknMm1UhvJ9-fpknpAa%3DwMbsaMghEHhcAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJM4AppwiAMdbHkaJ7d%3Dbc02j%3D5zPZ6RMs4p81FGaO2D4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKT8G6BvBANW-_weObNrX1faPV_QE-gjK2gn9qSbbsRdFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJMM%2B7p3d4Ujmz8zbLy1rVRL1%2BZjm-s3wa_8_P%3D7y47FOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Tobias McNulty
Tom,

That's great! Thanks for the feedback.

I've updated the PR with something along the lines of what you suggested (along with the corresponding configuration in Fastly).

Take a look and let me know what you think.

Cheers,
Tobias



On Sun, Feb 24, 2019 at 10:40 AM Tom Forbes <[hidden email]> wrote:

Awesome work! For my location (Lisbon, Portugal) it takes about 130ms to retrieve the HTML for a docs page (https://django-docs.global.ssl.fastly.net/en/2.1/intro/reusable-apps/ to be specific). The same page on docs.djangoproject.com responds in 800–900ms.




On 24 February 2019 at 14:35:55, Tobias McNulty ([hidden email]) wrote:

Hi Tom,

Thanks for your message. I think we'll end up with Fastly since it would be free, but I'm waiting to see their sponsorship contract. CloudFront would work too but I don't know of any such open source sponsorship options with AWS.

I will say wildcard purging looks a bit simpler in CloudFront, but your idea purging the whole cache only for non-dev builds could work (provided we have a lower cache timeout or a single wildcard purge condition set up for the dev builds, I guess).

Feel free to test and post any feedback about Fastly prior to the potential transition here: https://django-docs.global.ssl.fastly.net/en/2.1/ (this is set up on a free dev account, so no custom SSL)

For the sake of comparison I'm working on getting a distribution set up for CloudFront too, but it won't be so simple to test (without a DNS or server configuration change) since I don't think CloudFront supports passing a custom Host header to the origin like Fastly does (i.e., you'll probably need to edit /etc/hosts).

Cheers,
Tobias


On Sat, Feb 23, 2019, 7:15 PM Tom Forbes <[hidden email]> wrote:
Sorry, I did not completely grok your message. I would be in favour of just invalidating the whole cache if needed, it seems the simplest solution. Invalidating most of the cache on every non-dev deploy would also be OK I think.

On Sun, 24 Feb 2019, 00:10 Tom Forbes, <[hidden email]> wrote:
Which CDN are we going to use? Fastly has awesome sub 100ms global invalidation which we can trigger on every deploy, and cloudflare has something similar.

On Sun, 24 Feb 2019, 00:00 Tobias McNulty, <[hidden email]> wrote:
Hi all,

An implementation question has come up regarding cache lifetime (see this PR). Right now, the whole site (including docs) has the site-wide Django cache enabled, with a timeout of 5 minutes. A couple docs views (search_suggestions and search_description) views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except for the release notes section and any (likely minor) related updates to the docs themselves. To get the most benefit out of a CDN, it would obviously be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs is desired, and waiting an hour or more for any cached pages to expire may cause significant confusion, for example, in conjunction with a security release for which stubbed (non-final) release notes may have already been pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any time there's a docs build that has changes. It would be pretty easy to piggyback off of the existing business logic for avoiding a rebuild if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching '/<lang>/<version>/releases/*' and perhaps the development docs) that would keep a shorter cache timeout of 5-10 minutes. All URLs not specifically requiring this special treatment would get a longer timeout, perhaps somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '/<lang>/<version>/releases/' and '/<lang>/dev/' that might update frequently and merit some combination of invalidation and/or a shorter cache time? And what's a good cache timeout for such pages?
* How long are we comfortable waiting for other (not frequently updated) pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty <[hidden email]> wrote:
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C <[hidden email] wrote:
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 1.37s, Load: 1.68s

Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, python.org does in fact use Fastly:

dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a contract which I guess the DSF would need to review and sign, if it's acceptable.

In the meantime, feel free to give this a try and let me know if you see any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for permanent use, obviously; you'll get a cert warning, and some pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in #django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson <[hidden email]> wrote:
I have not had great experience with Fastly in the past and would avoid them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton <[hidden email]> wrote:
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so that DNS alone can decide to hit cdn or origin. 

Anyway, it seems weird to me to dismiss a CDN offhand “because security”. Especially considering the size of the providers and the expertise their teams have. 

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” providers. I would probably go as far to say that putting a CDN in front of both the docs and the release packages would likely be a net improvement in security for users. 

On Thu, 14 Feb 2019 at 21:58, Tom Forbes <[hidden email]> wrote:
That makes sense, but in this case we are only talking about potentially yielding control of the docs subdomain which is not used to serve sensitive build artefacts?

Another option is fastly.com, who support other large open source projects for free. They essentially give you geographically distributed HAProxy instances and you have a lot more control over them. I believe several large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to do this for the whole domain to get any benefit. The Django docs are text/html heavy with very few, if any, images. So the real speed benefit will have to come from serving that, which requires TLS termination (and therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <[hidden email]> wrote:
Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts from the djangoproject.com website. And we would like to ensure that the TLS termination happens by us and not some random service provider. After all, Django is used by enterprises that do have some restrictions on where you're allowed to download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require us to hand over control of DNS, I guess we could be interested in moving the docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and
> re-encrypt all our data). This may be less of an issue for the docs
> site, *if* we don't have to assign DNS authority for the whole domain
> to the CDN provider.
>
> Tobias
>
>
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell <[hidden email] wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <[hidden email]> wrote:
> >> Consider AWS's cloudfront then :)
> >>
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN.
> >>>
> >>> Cheers,
> >>> Florian
> >>>
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >>>> Hi,
> >>>>
> >>>> Is it possible to utilize a CDN service for djangoproject.com, or at least on docs.djangoproject.com? The site is actually quite fast for me but I think there is still room for improvement. Cloudflare sponsored dozens of open source projects <https://developers.cloudflare.com/sponsorships/>, probably they can provide free service for django as well.
> >>>>
> >>>> Tested from Melbourne, Australia:
> >>>>
> >>>> https://www.djangoproject.com/
> >>>>  Average Ping: 245ms
> >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s
> >>>>
> >>>> https://git-scm.com/
> >>>>  Average Ping: 5ms
> >>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 564ms, Load: 699ms
> >>>>
> >>>> Tested on Chrome with "Disable cache" checked (but not the first time visit, so DNS query time might not be included).
> >>>>
> >>>> Best regards and thanks for all your great work.
> >> 
>
>
> >>  --
> >>  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >>  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >>  To post to this group, send email to [hidden email].
> >>  Visit this group at https://groups.google.com/group/django-developers.
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>  For more options, visit https://groups.google.com/d/optout.
> >> 
> > 
>
>
> >  --
> >  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >  To post to this group, send email to [hidden email].
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >  For more options, visit https://groups.google.com/d/optout.
> > 

>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>  To post to this group, send email to
> [hidden email].
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRVHxL82tNOuknMm1UhvJ9-fpknpAa%3DwMbsaMghEHhcAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJM4AppwiAMdbHkaJ7d%3Dbc02j%3D5zPZ6RMs4p81FGaO2D4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKT8G6BvBANW-_weObNrX1faPV_QE-gjK2gn9qSbbsRdFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJMM%2B7p3d4Ujmz8zbLy1rVRL1%2BZjm-s3wa_8_P%3D7y47FOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTtg5KWKf9ZzFxOwkC0U7kE78RuYKfY-jy-QKdLKhu_1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Florian Apolloner
In reply to this post by Tobias McNulty
Hi Tobias,

I think a cache of something like a day will most certainly not hurt anyone. If the need arises we can still manually purge the cache as needed.

Cheers,
Florian

On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
Hi all,

An implementation question has come up regarding cache lifetime (see <a href="https://github.com/django/djangoproject.com/pull/870" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fpull%2F870\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_GI4L71SHRBY9UBP9mj6A-OGTdQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fpull%2F870\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE_GI4L71SHRBY9UBP9mj6A-OGTdQ&#39;;return true;">this PR). Right now, the whole site (including docs) has the <a href="https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/prod.py#L43-L45" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdjangoproject%2Fsettings%2Fprod.py%23L43-L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNESfnqEiIkCVfKtLw4PzkumPUWPbQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdjangoproject%2Fsettings%2Fprod.py%23L43-L45\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNESfnqEiIkCVfKtLw4PzkumPUWPbQ&#39;;return true;">site-wide Django cache enabled, with a <a href="https://github.com/django/djangoproject.com/blob/master/djangoproject/settings/common.py#L27" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdjangoproject%2Fsettings%2Fcommon.py%23L27\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGD8wNRx130dU3BZ0-c66D1WBBVYg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdjangoproject%2Fsettings%2Fcommon.py%23L27\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGD8wNRx130dU3BZ0-c66D1WBBVYg&#39;;return true;">timeout of 5 minutes. A couple docs views (<a href="https://github.com/django/djangoproject.com/blob/master/docs/views.py#L248-L250" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdocs%2Fviews.py%23L248-L250\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGAwwcoNw23jvz9OfBrOZpPL7QkZQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdocs%2Fviews.py%23L248-L250\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGAwwcoNw23jvz9OfBrOZpPL7QkZQ&#39;;return true;">search_suggestions and <a href="https://github.com/django/djangoproject.com/blob/master/docs/views.py#L272-L274" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdocs%2Fviews.py%23L272-L274\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHRxndGS0mxlKTuzrwiWzZw-zle6A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdocs%2Fviews.py%23L272-L274\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHRxndGS0mxlKTuzrwiWzZw-zle6A&#39;;return true;">search_description) views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except for the release notes section and any (likely minor) related updates to the docs themselves. To get the most benefit out of a CDN, it would obviously be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs is desired, and waiting an hour or more for any cached pages to expire may cause significant confusion, for example, in conjunction with a security release for which stubbed (non-final) release notes may have already been pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any time there's a docs build that has changes. It would be pretty easy to piggyback off of the <a href="https://github.com/django/djangoproject.com/blob/master/docs/management/commands/update_docs.py#L86-L93" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdocs%2Fmanagement%2Fcommands%2Fupdate_docs.py%23L86-L93\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHt6tAQVqHz5sAdjPe2qfStJbiGNA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdjangoproject.com%2Fblob%2Fmaster%2Fdocs%2Fmanagement%2Fcommands%2Fupdate_docs.py%23L86-L93\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHt6tAQVqHz5sAdjPe2qfStJbiGNA&#39;;return true;">existing business logic for avoiding a rebuild if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching '/<lang>/<version>/releases/*' and perhaps the development docs) that would keep a shorter cache timeout of 5-10 minutes. All URLs not specifically requiring this special treatment would get a longer timeout, perhaps somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '/<lang>/<version>/releases/' and '/<lang>/dev/' that might update frequently and merit some combination of invalidation and/or a shorter cache time? And what's a good cache timeout for such pages?
* How long are we comfortable waiting for other (not frequently updated) pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Dgwxu3Q3AwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">tob...@...> wrote:
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to use it: <a href="https://django-docs.global.ssl.fastly.net/en/2.1/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdjango-docs.global.ssl.fastly.net%2Fen%2F2.1%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGYVx3hKFPofJuLtdMt7aNuVTO8Ew&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdjango-docs.global.ssl.fastly.net%2Fen%2F2.1%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGYVx3hKFPofJuLtdMt7aNuVTO8Ew&#39;;return true;">https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Dgwxu3Q3AwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">coupo...@... wrote:
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

<a href="https://docs.djangoproject.com/en/2.1/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.1%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG79LmjyoKa48PyA6uq-c1872ezLQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.1%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG79LmjyoKa48PyA6uq-c1872ezLQ&#39;;return true;">https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 1.37s, Load: 1.68s

<a href="https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com.global.prod.fastly.net%2Fen%2F2.1%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF_4sI_lSqwGk2XsEM2DRZmzd_Ijw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com.global.prod.fastly.net%2Fen%2F2.1%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF_4sI_lSqwGk2XsEM2DRZmzd_Ijw&#39;;return true;">https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, <a href="http://python.org" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpython.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF558DEk4MojQmCDwPIrITw2rjEQA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpython.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF558DEk4MojQmCDwPIrITw2rjEQA&#39;;return true;">python.org does in fact use Fastly:

$ host <a href="http://www.python.org" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.python.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG74OuMTvzzPIKV7127cEKaZabdUw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.python.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG74OuMTvzzPIKV7127cEKaZabdUw&#39;;return true;">www.python.org
<a href="http://www.python.org" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.python.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG74OuMTvzzPIKV7127cEKaZabdUw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.python.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG74OuMTvzzPIKV7127cEKaZabdUw&#39;;return true;">www.python.org is an alias for <a href="http://dualstack.python.map.fastly.net" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdualstack.python.map.fastly.net\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6U-7XC0TFEGsyQQpRnlCZ86Gr4Q&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdualstack.python.map.fastly.net\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6U-7XC0TFEGsyQQpRnlCZ86Gr4Q&#39;;return true;">dualstack.python.map.fastly.net.
<a href="http://dualstack.python.map.fastly.net" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdualstack.python.map.fastly.net\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6U-7XC0TFEGsyQQpRnlCZ86Gr4Q&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdualstack.python.map.fastly.net\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6U-7XC0TFEGsyQQpRnlCZ86Gr4Q&#39;;return true;">dualstack.python.map.fastly.net has address 151.101.248.223
<a href="http://dualstack.python.map.fastly.net" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdualstack.python.map.fastly.net\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6U-7XC0TFEGsyQQpRnlCZ86Gr4Q&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdualstack.python.map.fastly.net\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG6U-7XC0TFEGsyQQpRnlCZ86Gr4Q&#39;;return true;">dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a contract which I guess the DSF would need to review and sign, if it's acceptable.

In the meantime, feel free to give this a try and let me know if you see any issues: <a href="https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com.global.prod.fastly.net%2Fen%2F2.1%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF_4sI_lSqwGk2XsEM2DRZmzd_Ijw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com.global.prod.fastly.net%2Fen%2F2.1%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF_4sI_lSqwGk2XsEM2DRZmzd_Ijw&#39;;return true;">https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for permanent use, obviously; you'll get a cert warning, and some pages will redirect you back to <a href="https://docs.djangoproject.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHWq9NY9CTxY49qB7_OQJiLUUoOsA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHWq9NY9CTxY49qB7_OQJiLUUoOsA&#39;;return true;">https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in #django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson <[hidden email]> wrote:
I have not had great experience with Fastly in the past and would avoid them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton <[hidden email]> wrote:
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so that DNS alone can decide to hit cdn or origin. 

Anyway, it seems weird to me to dismiss a CDN offhand “because security”. Especially considering the size of the providers and the expertise their teams have. 

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” providers. I would probably go as far to say that putting a CDN in front of both the docs and the release packages would likely be a net improvement in security for users. 

On Thu, 14 Feb 2019 at 21:58, Tom Forbes <[hidden email]> wrote:
That makes sense, but in this case we are only talking about potentially yielding control of the docs subdomain which is not used to serve sensitive build artefacts?

Another option is <a href="http://fastly.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Ffastly.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGqPMH_ZYGcWKpd-CCMwOQD6MXqEw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Ffastly.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGqPMH_ZYGcWKpd-CCMwOQD6MXqEw&#39;;return true;">fastly.com, who support other large open source projects for free. They essentially give you geographically distributed HAProxy instances and you have a lot more control over them. I believe several large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to do this for the whole domain to get any benefit. The Django docs are text/html heavy with very few, if any, images. So the real speed benefit will have to come from serving that, which requires TLS termination (and therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <[hidden email]> wrote:
Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts from the <a href="http://djangoproject.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdjangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEUzTJD1JYiEvNPHf2Ki4_Tp34BMQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdjangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEUzTJD1JYiEvNPHf2Ki4_Tp34BMQ&#39;;return true;">djangoproject.com website. And we would like to ensure that the TLS termination happens by us and not some random service provider. After all, Django is used by enterprises that do have some restrictions on where you're allowed to download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require us to hand over control of DNS, I guess we could be interested in moving the docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and
> re-encrypt all our data). This may be less of an issue for the docs
> site, *if* we don't have to assign DNS authority for the whole domain
> to the CDN provider.
>
> Tobias
>
>
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell <[hidden email] wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <[hidden email]> wrote:
> >> Consider AWS's cloudfront then :)
> >>
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN.
> >>>
> >>> Cheers,
> >>> Florian
> >>>
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >>>> Hi,
> >>>>
> >>>> Is it possible to utilize a CDN service for <a href="http://djangoproject.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdjangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEUzTJD1JYiEvNPHf2Ki4_Tp34BMQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdjangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEUzTJD1JYiEvNPHf2Ki4_Tp34BMQ&#39;;return true;">djangoproject.com, or at least on <a href="http://docs.djangoproject.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdocs.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE2WgQ8IZS5NnMit3FRV26Zt9rLqA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdocs.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE2WgQ8IZS5NnMit3FRV26Zt9rLqA&#39;;return true;">docs.djangoproject.com? The site is actually quite fast for me but I think there is still room for improvement. Cloudflare sponsored dozens of open source projects <<a href="https://developers.cloudflare.com/sponsorships/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdevelopers.cloudflare.com%2Fsponsorships%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG0ri7MUumLJdqZk0ZxybT15xMnIQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdevelopers.cloudflare.com%2Fsponsorships%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG0ri7MUumLJdqZk0ZxybT15xMnIQ&#39;;return true;">https://developers.cloudflare.com/sponsorships/>, probably they can provide free service for django as well.
> >>>>
> >>>> Tested from Melbourne, Australia:
> >>>>
> >>>> <a href="https://www.djangoproject.com/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.djangoproject.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHSU1ZCMW_LBb5E3mdq2QDIAj8M4g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.djangoproject.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHSU1ZCMW_LBb5E3mdq2QDIAj8M4g&#39;;return true;">https://www.djangoproject.com/
> >>>>  Average Ping: 245ms
> >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s
> >>>>
> >>>> <a href="https://git-scm.com/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgit-scm.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHwEiXJLFEIUYzJ_50ipYJuiUThKw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgit-scm.com%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHwEiXJLFEIUYzJ_50ipYJuiUThKw&#39;;return true;">https://git-scm.com/
> >>>>  Average Ping: 5ms
> >>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 564ms, Load: 699ms
> >>>>
> >>>> Tested on Chrome with "Disable cache" checked (but not the first time visit, so DNS query time might not be included).
> >>>>
> >>>> Best regards and thanks for all your great work.
> >> 
>
>
> >>  --
> >>  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >>  To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> >>  To post to this group, send email to [hidden email].
> >>  Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
> >>  To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com&#39;;return true;">https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com <<a href="https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>  For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
> >> 
> > 
>
>
> >  --
> >  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> >  To post to this group, send email to [hidden email].
> >  Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com <<a href="https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >  For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
> > 

>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to django-develop...@googlegroups.com.
>  To post to this group, send email to
> [hidden email].
>  Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> <a href="https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com <<a href="https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/fbb5c67a-8803-43ce-8fe3-ee6f42251d8a%40www.fastmail.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/fbb5c67a-8803-43ce-8fe3-ee6f42251d8a%40www.fastmail.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/fbb5c67a-8803-43ce-8fe3-ee6f42251d8a%40www.fastmail.com&#39;;return true;">https://groups.google.com/d/msgid/django-developers/fbb5c67a-8803-43ce-8fe3-ee6f42251d8a%40www.fastmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe&#39;;return true;">https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="Dgwxu3Q3AwAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="Dgwxu3Q3AwAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0fc6fd9b-82ce-4ffe-a46c-b42767e19cb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Tobias McNulty
Hi all,

These changes have been deployed (though we're not yet using a CDN for the primary domain, docs.djangoproject.com, so you shouldn't notice a change).

The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/) will now cache docs pages for up to a week, and the hourly docs rebuilds will trigger a cache purge of (a) nothing if there have been no changes in the last hour, (b) just the dev docs if that's all that's changed or (c) the entire docs site if a release branch has changed. I've tested this a few times and everything seems to be working as it should, but please let me know if you see anything out of order.

Currently we're waiting on the DSF/Fastly contract to be executed. Once that's done I think we'll be ready to move static.djangoproject.com and docs.djangoproject.com to Fastly.

I did set up a CloudFront distribution for these domains as well, but given Fastly will give us the bandwidth for free we're having a hard time justifying using CloudFront instead. Of course, if anyone has a connection to $2000+ a year or so in AWS credits for the foreseeable future, let me know. :-)

Finally, in preparation for the switch, I set up a status page (https://docs-status.djangoproject.com) that, at the time I wrote this email, at least, shows the following average response times to the docs site from around the world:
  • Mumbai: 1968 ms
  • Singapore: 1895 ms
  • Sydney: 2015 ms
  • Tokyo: 1490 ms
  • Canada (Central): 224 ms
  • Ireland: 705 ms
  • London: 525 ms
  • Sao Paulo: 911 ms
  • US East (N. Virginia): 149 ms
  • US West (Oregon): 721 ms
You can click on an individual region to see the variability over time. I'm on the east coast in the US so I don't have a good way to confirm or deny most of these. They are HTTPS checks, and I believe the numbers represent the time to connect and retrieve the page content (for https://docs.djangoproject.com/en/2.1/).

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner <[hidden email]> wrote:
Hi Tobias,

I think a cache of something like a day will most certainly not hurt anyone. If the need arises we can still manually purge the cache as needed.

Cheers,
Florian

On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
Hi all,

An implementation question has come up regarding cache lifetime (see this PR). Right now, the whole site (including docs) has the site-wide Django cache enabled, with a timeout of 5 minutes. A couple docs views (search_suggestions and search_description) views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except for the release notes section and any (likely minor) related updates to the docs themselves. To get the most benefit out of a CDN, it would obviously be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs is desired, and waiting an hour or more for any cached pages to expire may cause significant confusion, for example, in conjunction with a security release for which stubbed (non-final) release notes may have already been pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any time there's a docs build that has changes. It would be pretty easy to piggyback off of the existing business logic for avoiding a rebuild if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching '/<lang>/<version>/releases/*' and perhaps the development docs) that would keep a shorter cache timeout of 5-10 minutes. All URLs not specifically requiring this special treatment would get a longer timeout, perhaps somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '/<lang>/<version>/releases/' and '/<lang>/dev/' that might update frequently and merit some combination of invalidation and/or a shorter cache time? And what's a good cache timeout for such pages?
* How long are we comfortable waiting for other (not frequently updated) pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty <[hidden email]> wrote:
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C <[hidden email] wrote:
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 1.37s, Load: 1.68s

Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, python.org does in fact use Fastly:

dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a contract which I guess the DSF would need to review and sign, if it's acceptable.

In the meantime, feel free to give this a try and let me know if you see any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for permanent use, obviously; you'll get a cert warning, and some pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in #django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson <[hidden email]> wrote:
I have not had great experience with Fastly in the past and would avoid them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton <[hidden email]> wrote:
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so that DNS alone can decide to hit cdn or origin. 

Anyway, it seems weird to me to dismiss a CDN offhand “because security”. Especially considering the size of the providers and the expertise their teams have. 

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” providers. I would probably go as far to say that putting a CDN in front of both the docs and the release packages would likely be a net improvement in security for users. 

On Thu, 14 Feb 2019 at 21:58, Tom Forbes <[hidden email]> wrote:
That makes sense, but in this case we are only talking about potentially yielding control of the docs subdomain which is not used to serve sensitive build artefacts?

Another option is fastly.com, who support other large open source projects for free. They essentially give you geographically distributed HAProxy instances and you have a lot more control over them. I believe several large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to do this for the whole domain to get any benefit. The Django docs are text/html heavy with very few, if any, images. So the real speed benefit will have to come from serving that, which requires TLS termination (and therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <[hidden email]> wrote:
Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts from the djangoproject.com website. And we would like to ensure that the TLS termination happens by us and not some random service provider. After all, Django is used by enterprises that do have some restrictions on where you're allowed to download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require us to hand over control of DNS, I guess we could be interested in moving the docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and
> re-encrypt all our data). This may be less of an issue for the docs
> site, *if* we don't have to assign DNS authority for the whole domain
> to the CDN provider.
>
> Tobias
>
>
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell <[hidden email] wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <[hidden email]> wrote:
> >> Consider AWS's cloudfront then :)
> >>
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN.
> >>>
> >>> Cheers,
> >>> Florian
> >>>
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >>>> Hi,
> >>>>
> >>>> Is it possible to utilize a CDN service for djangoproject.com, or at least on docs.djangoproject.com? The site is actually quite fast for me but I think there is still room for improvement. Cloudflare sponsored dozens of open source projects <https://developers.cloudflare.com/sponsorships/>, probably they can provide free service for django as well.
> >>>>
> >>>> Tested from Melbourne, Australia:
> >>>>
> >>>> https://www.djangoproject.com/
> >>>>  Average Ping: 245ms
> >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s
> >>>>
> >>>> https://git-scm.com/
> >>>>  Average Ping: 5ms
> >>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 564ms, Load: 699ms
> >>>>
> >>>> Tested on Chrome with "Disable cache" checked (but not the first time visit, so DNS query time might not be included).
> >>>>
> >>>> Best regards and thanks for all your great work.
> >> 
>
>
> >>  --
> >>  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >>  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >>  To post to this group, send email to [hidden email].
> >>  Visit this group at https://groups.google.com/group/django-developers.
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>  For more options, visit https://groups.google.com/d/optout.
> >> 
> > 
>
>
> >  --
> >  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >  To post to this group, send email to [hidden email].
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >  For more options, visit https://groups.google.com/d/optout.
> > 

>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>  To post to this group, send email to
> [hidden email].
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0fc6fd9b-82ce-4ffe-a46c-b42767e19cb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRUffq4u%2BuH9iYRh%3DeJ40WaVP%3DaAWsPS%3DfAMoPaCh4F3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Adam Johnson-2
Looking good! Thanks for your work Tobias.

I get 30ms through CDN instead of 230ms from here in London, UK.

I take back my bad comments about Fastly, since they are giving free credits :) If you don't need custom Varnish code they are quite easy to configure and easy to contact on IRC.n

On Mon, 11 Mar 2019 at 13:06, Tobias McNulty <[hidden email]> wrote:
Hi all,

These changes have been deployed (though we're not yet using a CDN for the primary domain, docs.djangoproject.com, so you shouldn't notice a change).

The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/) will now cache docs pages for up to a week, and the hourly docs rebuilds will trigger a cache purge of (a) nothing if there have been no changes in the last hour, (b) just the dev docs if that's all that's changed or (c) the entire docs site if a release branch has changed. I've tested this a few times and everything seems to be working as it should, but please let me know if you see anything out of order.

Currently we're waiting on the DSF/Fastly contract to be executed. Once that's done I think we'll be ready to move static.djangoproject.com and docs.djangoproject.com to Fastly.

I did set up a CloudFront distribution for these domains as well, but given Fastly will give us the bandwidth for free we're having a hard time justifying using CloudFront instead. Of course, if anyone has a connection to $2000+ a year or so in AWS credits for the foreseeable future, let me know. :-)

Finally, in preparation for the switch, I set up a status page (https://docs-status.djangoproject.com) that, at the time I wrote this email, at least, shows the following average response times to the docs site from around the world:
  • Mumbai: 1968 ms
  • Singapore: 1895 ms
  • Sydney: 2015 ms
  • Tokyo: 1490 ms
  • Canada (Central): 224 ms
  • Ireland: 705 ms
  • London: 525 ms
  • Sao Paulo: 911 ms
  • US East (N. Virginia): 149 ms
  • US West (Oregon): 721 ms
You can click on an individual region to see the variability over time. I'm on the east coast in the US so I don't have a good way to confirm or deny most of these. They are HTTPS checks, and I believe the numbers represent the time to connect and retrieve the page content (for https://docs.djangoproject.com/en/2.1/).

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner <[hidden email]> wrote:
Hi Tobias,

I think a cache of something like a day will most certainly not hurt anyone. If the need arises we can still manually purge the cache as needed.

Cheers,
Florian

On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
Hi all,

An implementation question has come up regarding cache lifetime (see this PR). Right now, the whole site (including docs) has the site-wide Django cache enabled, with a timeout of 5 minutes. A couple docs views (search_suggestions and search_description) views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except for the release notes section and any (likely minor) related updates to the docs themselves. To get the most benefit out of a CDN, it would obviously be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs is desired, and waiting an hour or more for any cached pages to expire may cause significant confusion, for example, in conjunction with a security release for which stubbed (non-final) release notes may have already been pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any time there's a docs build that has changes. It would be pretty easy to piggyback off of the existing business logic for avoiding a rebuild if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching '/<lang>/<version>/releases/*' and perhaps the development docs) that would keep a shorter cache timeout of 5-10 minutes. All URLs not specifically requiring this special treatment would get a longer timeout, perhaps somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '/<lang>/<version>/releases/' and '/<lang>/dev/' that might update frequently and merit some combination of invalidation and/or a shorter cache time? And what's a good cache timeout for such pages?
* How long are we comfortable waiting for other (not frequently updated) pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty <[hidden email]> wrote:
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C <[hidden email] wrote:
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 1.37s, Load: 1.68s

Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, python.org does in fact use Fastly:

dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a contract which I guess the DSF would need to review and sign, if it's acceptable.

In the meantime, feel free to give this a try and let me know if you see any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for permanent use, obviously; you'll get a cert warning, and some pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in #django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson <[hidden email]> wrote:
I have not had great experience with Fastly in the past and would avoid them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton <[hidden email]> wrote:
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so that DNS alone can decide to hit cdn or origin. 

Anyway, it seems weird to me to dismiss a CDN offhand “because security”. Especially considering the size of the providers and the expertise their teams have. 

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” providers. I would probably go as far to say that putting a CDN in front of both the docs and the release packages would likely be a net improvement in security for users. 

On Thu, 14 Feb 2019 at 21:58, Tom Forbes <[hidden email]> wrote:
That makes sense, but in this case we are only talking about potentially yielding control of the docs subdomain which is not used to serve sensitive build artefacts?

Another option is fastly.com, who support other large open source projects for free. They essentially give you geographically distributed HAProxy instances and you have a lot more control over them. I believe several large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to do this for the whole domain to get any benefit. The Django docs are text/html heavy with very few, if any, images. So the real speed benefit will have to come from serving that, which requires TLS termination (and therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <[hidden email]> wrote:
Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts from the djangoproject.com website. And we would like to ensure that the TLS termination happens by us and not some random service provider. After all, Django is used by enterprises that do have some restrictions on where you're allowed to download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require us to hand over control of DNS, I guess we could be interested in moving the docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and
> re-encrypt all our data). This may be less of an issue for the docs
> site, *if* we don't have to assign DNS authority for the whole domain
> to the CDN provider.
>
> Tobias
>
>
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell <[hidden email] wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <[hidden email]> wrote:
> >> Consider AWS's cloudfront then :)
> >>
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN.
> >>>
> >>> Cheers,
> >>> Florian
> >>>
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >>>> Hi,
> >>>>
> >>>> Is it possible to utilize a CDN service for djangoproject.com, or at least on docs.djangoproject.com? The site is actually quite fast for me but I think there is still room for improvement. Cloudflare sponsored dozens of open source projects <https://developers.cloudflare.com/sponsorships/>, probably they can provide free service for django as well.
> >>>>
> >>>> Tested from Melbourne, Australia:
> >>>>
> >>>> https://www.djangoproject.com/
> >>>>  Average Ping: 245ms
> >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s
> >>>>
> >>>> https://git-scm.com/
> >>>>  Average Ping: 5ms
> >>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 564ms, Load: 699ms
> >>>>
> >>>> Tested on Chrome with "Disable cache" checked (but not the first time visit, so DNS query time might not be included).
> >>>>
> >>>> Best regards and thanks for all your great work.
> >> 
>
>
> >>  --
> >>  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >>  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >>  To post to this group, send email to [hidden email].
> >>  Visit this group at https://groups.google.com/group/django-developers.
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>  For more options, visit https://groups.google.com/d/optout.
> >> 
> > 
>
>
> >  --
> >  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >  To post to this group, send email to [hidden email].
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >  For more options, visit https://groups.google.com/d/optout.
> > 

>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>  To post to this group, send email to
> [hidden email].
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0fc6fd9b-82ce-4ffe-a46c-b42767e19cb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRUffq4u%2BuH9iYRh%3DeJ40WaVP%3DaAWsPS%3DfAMoPaCh4F3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2Etz6Mg1Rzvth5A56wodN2eEsMAtVt7xuHta2t08OsFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Tobias McNulty
Thanks, Adam! Agreed our usage is fairly simple.

I switched the DNS for docs.djangoproject.com to Fastly just after 1pm UTC today, so all traffic for docs (and static, though that's been enabled for a couple weeks) is now going through Fastly. It appears to have had the desired effect; the global average response time dropped from ~700ms to ~160ms:

Screenshot 2019-03-30 14.52.23.png


So far our hit ratio is averaging around 55% (this is just for docs, static not surprisingly is close to 99%):
Screenshot 2019-03-30 14.49.06.png
The dip just after the DNS change was due to a commit on the 2.2 & 2.1 branches that (as hoped) triggered a docs rebuild and subsequent 'purge_all' to Fastly.

Of course, let me know if you see any issues. After switching the DNS for static, for example, Mariusz noticed Firefox sending HTTP/2 requests for www to Fastly despite its DNS not changing (if you're curious, see https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/). With help from Fastly folks on IRC we identified and fixed this fairly quickly, but I wouldn't be surprised if a couple other gotchas show up once this runs for a bit.

In any case, a big thank you to everyone who helped with brainstorming, PR reviews, and accommodating my numerous questions -- esp. Tim, Markus, and Florian whose contributions were not visible on this list. :)

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Mon, Mar 11, 2019 at 9:17 AM Adam Johnson <[hidden email]> wrote:
Looking good! Thanks for your work Tobias.

I get 30ms through CDN instead of 230ms from here in London, UK.

I take back my bad comments about Fastly, since they are giving free credits :) If you don't need custom Varnish code they are quite easy to configure and easy to contact on IRC.n

On Mon, 11 Mar 2019 at 13:06, Tobias McNulty <[hidden email]> wrote:
Hi all,

These changes have been deployed (though we're not yet using a CDN for the primary domain, docs.djangoproject.com, so you shouldn't notice a change).

The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/) will now cache docs pages for up to a week, and the hourly docs rebuilds will trigger a cache purge of (a) nothing if there have been no changes in the last hour, (b) just the dev docs if that's all that's changed or (c) the entire docs site if a release branch has changed. I've tested this a few times and everything seems to be working as it should, but please let me know if you see anything out of order.

Currently we're waiting on the DSF/Fastly contract to be executed. Once that's done I think we'll be ready to move static.djangoproject.com and docs.djangoproject.com to Fastly.

I did set up a CloudFront distribution for these domains as well, but given Fastly will give us the bandwidth for free we're having a hard time justifying using CloudFront instead. Of course, if anyone has a connection to $2000+ a year or so in AWS credits for the foreseeable future, let me know. :-)

Finally, in preparation for the switch, I set up a status page (https://docs-status.djangoproject.com) that, at the time I wrote this email, at least, shows the following average response times to the docs site from around the world:
  • Mumbai: 1968 ms
  • Singapore: 1895 ms
  • Sydney: 2015 ms
  • Tokyo: 1490 ms
  • Canada (Central): 224 ms
  • Ireland: 705 ms
  • London: 525 ms
  • Sao Paulo: 911 ms
  • US East (N. Virginia): 149 ms
  • US West (Oregon): 721 ms
You can click on an individual region to see the variability over time. I'm on the east coast in the US so I don't have a good way to confirm or deny most of these. They are HTTPS checks, and I believe the numbers represent the time to connect and retrieve the page content (for https://docs.djangoproject.com/en/2.1/).

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner <[hidden email]> wrote:
Hi Tobias,

I think a cache of something like a day will most certainly not hurt anyone. If the need arises we can still manually purge the cache as needed.

Cheers,
Florian

On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
Hi all,

An implementation question has come up regarding cache lifetime (see this PR). Right now, the whole site (including docs) has the site-wide Django cache enabled, with a timeout of 5 minutes. A couple docs views (search_suggestions and search_description) views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except for the release notes section and any (likely minor) related updates to the docs themselves. To get the most benefit out of a CDN, it would obviously be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs is desired, and waiting an hour or more for any cached pages to expire may cause significant confusion, for example, in conjunction with a security release for which stubbed (non-final) release notes may have already been pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any time there's a docs build that has changes. It would be pretty easy to piggyback off of the existing business logic for avoiding a rebuild if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching '/<lang>/<version>/releases/*' and perhaps the development docs) that would keep a shorter cache timeout of 5-10 minutes. All URLs not specifically requiring this special treatment would get a longer timeout, perhaps somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '/<lang>/<version>/releases/' and '/<lang>/dev/' that might update frequently and merit some combination of invalidation and/or a shorter cache time? And what's a good cache timeout for such pages?
* How long are we comfortable waiting for other (not frequently updated) pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty <[hidden email]> wrote:
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C <[hidden email] wrote:
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 1.37s, Load: 1.68s

Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, python.org does in fact use Fastly:

dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a contract which I guess the DSF would need to review and sign, if it's acceptable.

In the meantime, feel free to give this a try and let me know if you see any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for permanent use, obviously; you'll get a cert warning, and some pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in #django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson <[hidden email]> wrote:
I have not had great experience with Fastly in the past and would avoid them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton <[hidden email]> wrote:
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so that DNS alone can decide to hit cdn or origin. 

Anyway, it seems weird to me to dismiss a CDN offhand “because security”. Especially considering the size of the providers and the expertise their teams have. 

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” providers. I would probably go as far to say that putting a CDN in front of both the docs and the release packages would likely be a net improvement in security for users. 

On Thu, 14 Feb 2019 at 21:58, Tom Forbes <[hidden email]> wrote:
That makes sense, but in this case we are only talking about potentially yielding control of the docs subdomain which is not used to serve sensitive build artefacts?

Another option is fastly.com, who support other large open source projects for free. They essentially give you geographically distributed HAProxy instances and you have a lot more control over them. I believe several large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to do this for the whole domain to get any benefit. The Django docs are text/html heavy with very few, if any, images. So the real speed benefit will have to come from serving that, which requires TLS termination (and therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <[hidden email]> wrote:
Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts from the djangoproject.com website. And we would like to ensure that the TLS termination happens by us and not some random service provider. After all, Django is used by enterprises that do have some restrictions on where you're allowed to download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require us to hand over control of DNS, I guess we could be interested in moving the docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and
> re-encrypt all our data). This may be less of an issue for the docs
> site, *if* we don't have to assign DNS authority for the whole domain
> to the CDN provider.
>
> Tobias
>
>
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell <[hidden email] wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <[hidden email]> wrote:
> >> Consider AWS's cloudfront then :)
> >>
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN.
> >>>
> >>> Cheers,
> >>> Florian
> >>>
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >>>> Hi,
> >>>>
> >>>> Is it possible to utilize a CDN service for djangoproject.com, or at least on docs.djangoproject.com? The site is actually quite fast for me but I think there is still room for improvement. Cloudflare sponsored dozens of open source projects <https://developers.cloudflare.com/sponsorships/>, probably they can provide free service for django as well.
> >>>>
> >>>> Tested from Melbourne, Australia:
> >>>>
> >>>> https://www.djangoproject.com/
> >>>>  Average Ping: 245ms
> >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s
> >>>>
> >>>> https://git-scm.com/
> >>>>  Average Ping: 5ms
> >>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 564ms, Load: 699ms
> >>>>
> >>>> Tested on Chrome with "Disable cache" checked (but not the first time visit, so DNS query time might not be included).
> >>>>
> >>>> Best regards and thanks for all your great work.
> >> 
>
>
> >>  --
> >>  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >>  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >>  To post to this group, send email to [hidden email].
> >>  Visit this group at https://groups.google.com/group/django-developers.
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>  For more options, visit https://groups.google.com/d/optout.
> >> 
> > 
>
>
> >  --
> >  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >  To post to this group, send email to [hidden email].
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >  For more options, visit https://groups.google.com/d/optout.
> > 

>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>  To post to this group, send email to
> [hidden email].
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0fc6fd9b-82ce-4ffe-a46c-b42767e19cb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRUffq4u%2BuH9iYRh%3DeJ40WaVP%3DaAWsPS%3DfAMoPaCh4F3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2Etz6Mg1Rzvth5A56wodN2eEsMAtVt7xuHta2t08OsFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKSSZJm-R3cWgbd9fcBu7vUL7_AkrqW7yY5sHZjdBJr6cg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Josh Smeaton
Thanks for running with the idea, and so quickly too! 

On Sun, 31 Mar 2019 at 07:42, Tobias McNulty <[hidden email]> wrote:
Thanks, Adam! Agreed our usage is fairly simple.

I switched the DNS for docs.djangoproject.com to Fastly just after 1pm UTC today, so all traffic for docs (and static, though that's been enabled for a couple weeks) is now going through Fastly. It appears to have had the desired effect; the global average response time dropped from ~700ms to ~160ms:

Screenshot 2019-03-30 14.52.23.png


So far our hit ratio is averaging around 55% (this is just for docs, static not surprisingly is close to 99%):
Screenshot 2019-03-30 14.49.06.png
The dip just after the DNS change was due to a commit on the 2.2 & 2.1 branches that (as hoped) triggered a docs rebuild and subsequent 'purge_all' to Fastly.

Of course, let me know if you see any issues. After switching the DNS for static, for example, Mariusz noticed Firefox sending HTTP/2 requests for www to Fastly despite its DNS not changing (if you're curious, see https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/). With help from Fastly folks on IRC we identified and fixed this fairly quickly, but I wouldn't be surprised if a couple other gotchas show up once this runs for a bit.

In any case, a big thank you to everyone who helped with brainstorming, PR reviews, and accommodating my numerous questions -- esp. Tim, Markus, and Florian whose contributions were not visible on this list. :)

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Mon, Mar 11, 2019 at 9:17 AM Adam Johnson <[hidden email]> wrote:
Looking good! Thanks for your work Tobias.

I get 30ms through CDN instead of 230ms from here in London, UK.

I take back my bad comments about Fastly, since they are giving free credits :) If you don't need custom Varnish code they are quite easy to configure and easy to contact on IRC.n

On Mon, 11 Mar 2019 at 13:06, Tobias McNulty <[hidden email]> wrote:
Hi all,

These changes have been deployed (though we're not yet using a CDN for the primary domain, docs.djangoproject.com, so you shouldn't notice a change).

The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/) will now cache docs pages for up to a week, and the hourly docs rebuilds will trigger a cache purge of (a) nothing if there have been no changes in the last hour, (b) just the dev docs if that's all that's changed or (c) the entire docs site if a release branch has changed. I've tested this a few times and everything seems to be working as it should, but please let me know if you see anything out of order.

Currently we're waiting on the DSF/Fastly contract to be executed. Once that's done I think we'll be ready to move static.djangoproject.com and docs.djangoproject.com to Fastly.

I did set up a CloudFront distribution for these domains as well, but given Fastly will give us the bandwidth for free we're having a hard time justifying using CloudFront instead. Of course, if anyone has a connection to $2000+ a year or so in AWS credits for the foreseeable future, let me know. :-)

Finally, in preparation for the switch, I set up a status page (https://docs-status.djangoproject.com) that, at the time I wrote this email, at least, shows the following average response times to the docs site from around the world:
  • Mumbai: 1968 ms
  • Singapore: 1895 ms
  • Sydney: 2015 ms
  • Tokyo: 1490 ms
  • Canada (Central): 224 ms
  • Ireland: 705 ms
  • London: 525 ms
  • Sao Paulo: 911 ms
  • US East (N. Virginia): 149 ms
  • US West (Oregon): 721 ms
You can click on an individual region to see the variability over time. I'm on the east coast in the US so I don't have a good way to confirm or deny most of these. They are HTTPS checks, and I believe the numbers represent the time to connect and retrieve the page content (for https://docs.djangoproject.com/en/2.1/).

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner <[hidden email]> wrote:
Hi Tobias,

I think a cache of something like a day will most certainly not hurt anyone. If the need arises we can still manually purge the cache as needed.

Cheers,
Florian

On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
Hi all,

An implementation question has come up regarding cache lifetime (see this PR). Right now, the whole site (including docs) has the site-wide Django cache enabled, with a timeout of 5 minutes. A couple docs views (search_suggestions and search_description) views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except for the release notes section and any (likely minor) related updates to the docs themselves. To get the most benefit out of a CDN, it would obviously be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs is desired, and waiting an hour or more for any cached pages to expire may cause significant confusion, for example, in conjunction with a security release for which stubbed (non-final) release notes may have already been pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any time there's a docs build that has changes. It would be pretty easy to piggyback off of the existing business logic for avoiding a rebuild if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching '/<lang>/<version>/releases/*' and perhaps the development docs) that would keep a shorter cache timeout of 5-10 minutes. All URLs not specifically requiring this special treatment would get a longer timeout, perhaps somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '/<lang>/<version>/releases/' and '/<lang>/dev/' that might update frequently and merit some combination of invalidation and/or a shorter cache time? And what's a good cache timeout for such pages?
* How long are we comfortable waiting for other (not frequently updated) pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty <[hidden email]> wrote:
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C <[hidden email] wrote:
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 1.37s, Load: 1.68s

Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, python.org does in fact use Fastly:

dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a contract which I guess the DSF would need to review and sign, if it's acceptable.

In the meantime, feel free to give this a try and let me know if you see any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for permanent use, obviously; you'll get a cert warning, and some pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in #django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson <[hidden email]> wrote:
I have not had great experience with Fastly in the past and would avoid them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton <[hidden email]> wrote:
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so that DNS alone can decide to hit cdn or origin. 

Anyway, it seems weird to me to dismiss a CDN offhand “because security”. Especially considering the size of the providers and the expertise their teams have. 

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” providers. I would probably go as far to say that putting a CDN in front of both the docs and the release packages would likely be a net improvement in security for users. 

On Thu, 14 Feb 2019 at 21:58, Tom Forbes <[hidden email]> wrote:
That makes sense, but in this case we are only talking about potentially yielding control of the docs subdomain which is not used to serve sensitive build artefacts?

Another option is fastly.com, who support other large open source projects for free. They essentially give you geographically distributed HAProxy instances and you have a lot more control over them. I believe several large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to do this for the whole domain to get any benefit. The Django docs are text/html heavy with very few, if any, images. So the real speed benefit will have to come from serving that, which requires TLS termination (and therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <[hidden email]> wrote:
Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts from the djangoproject.com website. And we would like to ensure that the TLS termination happens by us and not some random service provider. After all, Django is used by enterprises that do have some restrictions on where you're allowed to download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require us to hand over control of DNS, I guess we could be interested in moving the docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and
> re-encrypt all our data). This may be less of an issue for the docs
> site, *if* we don't have to assign DNS authority for the whole domain
> to the CDN provider.
>
> Tobias
>
>
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell <[hidden email] wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <[hidden email]> wrote:
> >> Consider AWS's cloudfront then :)
> >>
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN.
> >>>
> >>> Cheers,
> >>> Florian
> >>>
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >>>> Hi,
> >>>>
> >>>> Is it possible to utilize a CDN service for djangoproject.com, or at least on docs.djangoproject.com? The site is actually quite fast for me but I think there is still room for improvement. Cloudflare sponsored dozens of open source projects <https://developers.cloudflare.com/sponsorships/>, probably they can provide free service for django as well.
> >>>>
> >>>> Tested from Melbourne, Australia:
> >>>>
> >>>> https://www.djangoproject.com/
> >>>>  Average Ping: 245ms
> >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s
> >>>>
> >>>> https://git-scm.com/
> >>>>  Average Ping: 5ms
> >>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 564ms, Load: 699ms
> >>>>
> >>>> Tested on Chrome with "Disable cache" checked (but not the first time visit, so DNS query time might not be included).
> >>>>
> >>>> Best regards and thanks for all your great work.
> >> 
>
>
> >>  --
> >>  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >>  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >>  To post to this group, send email to [hidden email].
> >>  Visit this group at https://groups.google.com/group/django-developers.
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>  For more options, visit https://groups.google.com/d/optout.
> >> 
> > 
>
>
> >  --
> >  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >  To post to this group, send email to [hidden email].
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >  For more options, visit https://groups.google.com/d/optout.
> > 

>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>  To post to this group, send email to
> [hidden email].
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0fc6fd9b-82ce-4ffe-a46c-b42767e19cb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRUffq4u%2BuH9iYRh%3DeJ40WaVP%3DaAWsPS%3DfAMoPaCh4F3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKSSZJm-R3cWgbd9fcBu7vUL7_AkrqW7yY5sHZjdBJr6cg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0fSnQAEjiUe0bijnFJFUBFWV5-YNd5%2BUxe-KucBA%2B5G8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Tom Forbes
In reply to this post by Tobias McNulty

This is amazing, thank you for your prompt work on this!

I’m a stats nerd, and I think I’m not alone on this list in that respect, would it be possible to share some more numbers after a week of usage? I would be interested in the total bandwidth used/saved, the global distribution of requests and the average requests per second. If I remember correctly fastly has a fantastic live dashboard with all of this info. 

I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate these and forward on http 1.1 requests? Could you elaborate a bit?

On 30 Mar 2019, at 20:41, Tobias McNulty <[hidden email]> wrote:

Thanks, Adam! Agreed our usage is fairly simple.

I switched the DNS for docs.djangoproject.com to Fastly just after 1pm UTC today, so all traffic for docs (and static, though that's been enabled for a couple weeks) is now going through Fastly. It appears to have had the desired effect; the global average response time dropped from ~700ms to ~160ms:




So far our hit ratio is averaging around 55% (this is just for docs, static not surprisingly is close to 99%):
Screenshot 2019-03-30 14.49.06.png
The dip just after the DNS change was due to a commit on the 2.2 & 2.1 branches that (as hoped) triggered a docs rebuild and subsequent 'purge_all' to Fastly.

Of course, let me know if you see any issues. After switching the DNS for static, for example, Mariusz noticed Firefox sending HTTP/2 requests for www to Fastly despite its DNS not changing (if you're curious, see https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/). With help from Fastly folks on IRC we identified and fixed this fairly quickly, but I wouldn't be surprised if a couple other gotchas show up once this runs for a bit.

In any case, a big thank you to everyone who helped with brainstorming, PR reviews, and accommodating my numerous questions -- esp. Tim, Markus, and Florian whose contributions were not visible on this list. :)

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Mon, Mar 11, 2019 at 9:17 AM Adam Johnson <[hidden email]> wrote:
Looking good! Thanks for your work Tobias.

I get 30ms through CDN instead of 230ms from here in London, UK.

I take back my bad comments about Fastly, since they are giving free credits :) If you don't need custom Varnish code they are quite easy to configure and easy to contact on IRC.n

On Mon, 11 Mar 2019 at 13:06, Tobias McNulty <[hidden email]> wrote:
Hi all,

These changes have been deployed (though we're not yet using a CDN for the primary domain, docs.djangoproject.com, so you shouldn't notice a change).

The alternate URL (https://django-docs.global.ssl.fastly.net/en/2.1/) will now cache docs pages for up to a week, and the hourly docs rebuilds will trigger a cache purge of (a) nothing if there have been no changes in the last hour, (b) just the dev docs if that's all that's changed or (c) the entire docs site if a release branch has changed. I've tested this a few times and everything seems to be working as it should, but please let me know if you see anything out of order.

Currently we're waiting on the DSF/Fastly contract to be executed. Once that's done I think we'll be ready to move static.djangoproject.com and docs.djangoproject.com to Fastly.

I did set up a CloudFront distribution for these domains as well, but given Fastly will give us the bandwidth for free we're having a hard time justifying using CloudFront instead. Of course, if anyone has a connection to $2000+ a year or so in AWS credits for the foreseeable future, let me know. :-)

Finally, in preparation for the switch, I set up a status page (https://docs-status.djangoproject.com) that, at the time I wrote this email, at least, shows the following average response times to the docs site from around the world:
  • Mumbai: 1968 ms
  • Singapore: 1895 ms
  • Sydney: 2015 ms
  • Tokyo: 1490 ms
  • Canada (Central): 224 ms
  • Ireland: 705 ms
  • London: 525 ms
  • Sao Paulo: 911 ms
  • US East (N. Virginia): 149 ms
  • US West (Oregon): 721 ms
You can click on an individual region to see the variability over time. I'm on the east coast in the US so I don't have a good way to confirm or deny most of these. They are HTTPS checks, and I believe the numbers represent the time to connect and retrieve the page content (for https://docs.djangoproject.com/en/2.1/).

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner <[hidden email]> wrote:
Hi Tobias,

I think a cache of something like a day will most certainly not hurt anyone. If the need arises we can still manually purge the cache as needed.

Cheers,
Florian

On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
Hi all,

An implementation question has come up regarding cache lifetime (see this PR). Right now, the whole site (including docs) has the site-wide Django cache enabled, with a timeout of 5 minutes. A couple docs views (search_suggestions and search_description) views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except for the release notes section and any (likely minor) related updates to the docs themselves. To get the most benefit out of a CDN, it would obviously be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs is desired, and waiting an hour or more for any cached pages to expire may cause significant confusion, for example, in conjunction with a security release for which stubbed (non-final) release notes may have already been pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any time there's a docs build that has changes. It would be pretty easy to piggyback off of the existing business logic for avoiding a rebuild if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching '/<lang>/<version>/releases/*' and perhaps the development docs) that would keep a shorter cache timeout of 5-10 minutes. All URLs not specifically requiring this special treatment would get a longer timeout, perhaps somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '/<lang>/<version>/releases/' and '/<lang>/dev/' that might update frequently and merit some combination of invalidation and/or a shorter cache time? And what's a good cache timeout for such pages?
* How long are we comfortable waiting for other (not frequently updated) pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty <[hidden email]> wrote:
Thanks for sharing the results.

I did manage to get a domain set up with working SSL, in case you want to use it: https://django-docs.global.ssl.fastly.net/en/2.1/

Tobias

On Thu, Feb 14, 2019, 11:49 PM Cheng C <[hidden email] wrote:
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

https://docs.djangoproject.com/en/2.1/
Average Ping: 268ms
 Browser: 22 requests, 238KB transferred, Finish: 2.72s, DOMContentLoaded: 1.37s, Load: 1.68s

Average Ping: 28ms
 Browser: 22 requests, 240KB transferred, Finish: 947ms, DOMContentLoaded: 627ms, Load: 910ms

Tested on Chrome with "Disable cache" checked, and no render issue was found.

On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, python.org does in fact use Fastly:

dualstack.python.map.fastly.net has address 151.101.248.223
dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

Fastly did write back to say they're happy to help, though there's a contract which I guess the DSF would need to review and sign, if it's acceptable.

In the meantime, feel free to give this a try and let me know if you see any issues: https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for permanent use, obviously; you'll get a cert warning, and some pages will redirect you back to https://docs.djangoproject.com.)

To keep this thread from getting too noisy, you can find me (tobias1) in #django-dev on FreeNode.

Cheers,
Tobias

On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson <[hidden email]> wrote:
I have not had great experience with Fastly in the past and would avoid them. They run an old fork of Varnish which is not fun to configure.

On Thu, 14 Feb 2019 at 11:16, Josh Smeaton <[hidden email]> wrote:
Cloudflare have many SSL options, including fully encrypted and authenticated comms all the way through (terminate and reconnect). Typically done by having a “hidden” origin domain that also hosts a certificate. I’m unsure if it’s possible to have both origin and front hosting the same name so that DNS alone can decide to hit cdn or origin. 

Anyway, it seems weird to me to dismiss a CDN offhand “because security”. Especially considering the size of the providers and the expertise their teams have. 

Cloudflare (fastly, cloudfront, whatever) aren’t some “random TLS” providers. I would probably go as far to say that putting a CDN in front of both the docs and the release packages would likely be a net improvement in security for users. 

On Thu, 14 Feb 2019 at 21:58, Tom Forbes <[hidden email]> wrote:
That makes sense, but in this case we are only talking about potentially yielding control of the docs subdomain which is not used to serve sensitive build artefacts?

Another option is fastly.com, who support other large open source projects for free. They essentially give you geographically distributed HAProxy instances and you have a lot more control over them. I believe several large Linux distributions use them to serve cached apt packages.

Regarding TLS termination, unfortunately any CDN we use will likely need to do this for the whole domain to get any benefit. The Django docs are text/html heavy with very few, if any, images. So the real speed benefit will have to come from serving that, which requires TLS termination (and therefore interception) at their end.

On Thu, 14 Feb 2019, 06:32 Markus Holtermann, <[hidden email]> wrote:
Hi all

to elaborate on what Tobias said: we deliberately have the infrastructure spread across multiple service providers: DNS registry, nameservers, hosting, TLS certificate authority, … None of them have access to everything. The reason is that we offer the download of the release artifacts from the djangoproject.com website. And we would like to ensure that the TLS termination happens by us and not some random service provider. After all, Django is used by enterprises that do have some restrictions on where you're allowed to download software from.

By handing over DNS to some CDN provider, we loose the ability to ensure that happens.

That said, if there's a CDN that works as a reverse proxy and doesn't require us to hand over control of DNS, I guess we could be interested in moving the docs behind that.

/Markus

On Thu, Feb 14, 2019, at 2:22 AM, Tobias McNulty wrote:
> For me it's the trust factor (allowing someone else to decrypt and
> re-encrypt all our data). This may be less of an issue for the docs
> site, *if* we don't have to assign DNS authority for the whole domain
> to the CDN provider.
>
> Tobias
>
>
> On Wed, Feb 13, 2019, 7:47 PM Kye Russell <[hidden email] wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <[hidden email]> wrote:
> >> Consider AWS's cloudfront then :)
> >>
> >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian Apolloner escribió:
> >>> Especially cloudflare is a service we do not want to use. as for the docs only, does the mirror on rtd work better for you? They are probably behind a CDN.
> >>>
> >>> Cheers,
> >>> Florian
> >>>
> >>> On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
> >>>> Hi,
> >>>>
> >>>> Is it possible to utilize a CDN service for djangoproject.com, or at least on docs.djangoproject.com? The site is actually quite fast for me but I think there is still room for improvement. Cloudflare sponsored dozens of open source projects <https://developers.cloudflare.com/sponsorships/>, probably they can provide free service for django as well.
> >>>>
> >>>> Tested from Melbourne, Australia:
> >>>>
> >>>> https://www.djangoproject.com/
> >>>>  Average Ping: 245ms
> >>>>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s
> >>>>
> >>>> https://git-scm.com/
> >>>>  Average Ping: 5ms
> >>>>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 564ms, Load: 699ms
> >>>>
> >>>> Tested on Chrome with "Disable cache" checked (but not the first time visit, so DNS query time might not be included).
> >>>>
> >>>> Best regards and thanks for all your great work.
> >> 
>
>
> >>  --
> >>  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >>  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >>  To post to this group, send email to [hidden email].
> >>  Visit this group at https://groups.google.com/group/django-developers.
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/548db807-647f-4d0b-99c2-f9f229f7175e%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >>  For more options, visit https://groups.google.com/d/optout.
> >> 
> > 
>
>
> >  --
> >  You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> >  To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> >  To post to this group, send email to [hidden email].
> >  Visit this group at https://groups.google.com/group/django-developers.
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> >  For more options, visit https://groups.google.com/d/optout.
> > 

>
>
>  --
>  You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>  To post to this group, send email to
> [hidden email].
>  Visit this group at https://groups.google.com/group/django-developers.
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.
>

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJOpXjJEgq4iEEaiZqYzQDc9XwZ8Jba4-RP2-Lahr7jOgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPbDM0dBnO4_yko9qQVjgR25T758bT8%3DThUMszA3eOb30tuYYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3vZJ6V%2BTvavmDS-rU1JkQcMnWy0FfPpq-%3DY52kepeYjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aa3e7806-f896-4125-afcb-4f886b70ace0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0fc6fd9b-82ce-4ffe-a46c-b42767e19cb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKRUffq4u%2BuH9iYRh%3DeJ40WaVP%3DaAWsPS%3DfAMoPaCh4F3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2Etz6Mg1Rzvth5A56wodN2eEsMAtVt7xuHta2t08OsFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKSSZJm-R3cWgbd9fcBu7vUL7_AkrqW7yY5sHZjdBJr6cg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/F8553E35-BD51-4B0D-B77B-36F91DCA11BF%40tomforb.es.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Tobias McNulty
On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes <[hidden email]> wrote:
I’m a stats nerd, and I think I’m not alone on this list in that respect, would it be possible to share some more numbers after a week of usage? I would be interested in the total bandwidth used/saved, the global distribution of requests and the average requests per second. If I remember correctly fastly has a fantastic live dashboard with all of this info.

For static, I think we'll end up using just under 300 GB a month, or about a quarter of the total bandwidth served by this particular server (which also handles most other djangoproject.com subdomains). I'll see if I can collect some slightly more interesting numbers after a week or two.

I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate these and forward on http 1.1 requests? Could you elaborate a bit?

HTTP/2 supports connection coalescing, where the browser (with varying degrees of aggressiveness, depending on the manufacturer) may reuse existing connections for different subdomains. In our case, Fastly originally provisioned a wildcard SSL cert ('*.djangoproject.com'), so we think that some versions of Firefox were reusing HTTP/2 connections originally established for static.djangoproject.com for requests to www.djangoproject.com, even though there was no overlap in IPs for the two domains. In the browser (courtesy of Mariusz) it looked like this:

Screenshot_20190320_113825.png
Clicking on the cert icon showed the wildcard cert from Fastly, not our Let's Encrypt cert, as well. In other words, it appeared Firefox was ignoring DNS for www.djangoproject.com and assumed that it could send those requests to static.djangoproject.com instead, simply because the server responded with an SSL certificate that matched www.djangoproject.com. I.e., it appeared to be even more aggressive than described under "The Firefox way" in the link above.

I find this explanation entirely dissatisfying (if not altogether frightening), so part of me hopes I've got it wrong. :-\

In any case, after requesting that Fastly de-provision the wildcard cert and include only the specific domains we needed, the issue went away. There is an HTTP status code (421) that can be used to tell the browser it's made such an error, so I believe we also could have solved this by setting up a catchall service in Fastly to return HTTP 421 for any requests received on subdomains we weren't expecting. But avoiding the spurious requests to begin with seemed like a better solution, and provisioning certs only for the domains we need is cleaner to begin with and seems to have fixed the problem.

I was never able to reproduce this in Firefox myself, but I did see evidence of it occurring insofar as we also started getting a very small number of requests to the 'docs.djangoproject.com' service in Fastly after changing the DNS for 'static.djangoproject.com.' Of course, no one would have noticed these because the requests returned successfully, but they should not have been going through Fastly (until the DNS was changed for 'docs', of course). Mariusz may be able to add something about the when/how he saw this; I do think it was fairly intermittent. Anyways, I'm pretty sure this would have gone undiagnosed for weeks if not months if he had not noticed and alerted us to the issue (causing all sorts of frustration and confusion in the meantime), so thank you again, Mariusz!

Cheers,
Tobias

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKREk0NZx93DMxOJdACO%2BHgSjGdoTLVuOLUHY3nFBgHTjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Use CDN for djangoproject.com

Tobias McNulty
Last week we had an average hit ratio of around 63%, including ~10 purges that dropped the rate down temporarily before the cache rebuilt:
Screenshot 2019-04-11 09.37.57.png
In terms of bandwidth, we're averaging around 5 GB/day for docs and 10 GB/day for static. Giving static its own domain may actually be saving us a good bit of bandwidth (previously each subdomain had its own /s/ prefix from which an identical set of static files was served).

Cheers,

Tobias McNulty
Chief Executive Officer

[hidden email]
www.caktusgroup.com



On Sun, Mar 31, 2019 at 3:08 PM Tobias McNulty <[hidden email]> wrote:
On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes <[hidden email]> wrote:
I’m a stats nerd, and I think I’m not alone on this list in that respect, would it be possible to share some more numbers after a week of usage? I would be interested in the total bandwidth used/saved, the global distribution of requests and the average requests per second. If I remember correctly fastly has a fantastic live dashboard with all of this info.

For static, I think we'll end up using just under 300 GB a month, or about a quarter of the total bandwidth served by this particular server (which also handles most other djangoproject.com subdomains). I'll see if I can collect some slightly more interesting numbers after a week or two.

I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate these and forward on http 1.1 requests? Could you elaborate a bit?

HTTP/2 supports connection coalescing, where the browser (with varying degrees of aggressiveness, depending on the manufacturer) may reuse existing connections for different subdomains. In our case, Fastly originally provisioned a wildcard SSL cert ('*.djangoproject.com'), so we think that some versions of Firefox were reusing HTTP/2 connections originally established for static.djangoproject.com for requests to www.djangoproject.com, even though there was no overlap in IPs for the two domains. In the browser (courtesy of Mariusz) it looked like this:

Screenshot_20190320_113825.png
Clicking on the cert icon showed the wildcard cert from Fastly, not our Let's Encrypt cert, as well. In other words, it appeared Firefox was ignoring DNS for www.djangoproject.com and assumed that it could send those requests to static.djangoproject.com instead, simply because the server responded with an SSL certificate that matched www.djangoproject.com. I.e., it appeared to be even more aggressive than described under "The Firefox way" in the link above.

I find this explanation entirely dissatisfying (if not altogether frightening), so part of me hopes I've got it wrong. :-\

In any case, after requesting that Fastly de-provision the wildcard cert and include only the specific domains we needed, the issue went away. There is an HTTP status code (421) that can be used to tell the browser it's made such an error, so I believe we also could have solved this by setting up a catchall service in Fastly to return HTTP 421 for any requests received on subdomains we weren't expecting. But avoiding the spurious requests to begin with seemed like a better solution, and provisioning certs only for the domains we need is cleaner to begin with and seems to have fixed the problem.

I was never able to reproduce this in Firefox myself, but I did see evidence of it occurring insofar as we also started getting a very small number of requests to the 'docs.djangoproject.com' service in Fastly after changing the DNS for 'static.djangoproject.com.' Of course, no one would have noticed these because the requests returned successfully, but they should not have been going through Fastly (until the DNS was changed for 'docs', of course). Mariusz may be able to add something about the when/how he saw this; I do think it was fairly intermittent. Anyways, I'm pretty sure this would have gone undiagnosed for weeks if not months if he had not noticed and alerted us to the issue (causing all sorts of frustration and confusion in the meantime), so thank you again, Mariusz!

Cheers,
Tobias

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKSR32g%2Bib7KSyuYmeajdBDuNuZg%3Di346Ly54MaW1Q1FCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
12