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:
[image: 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

tob...@caktusgroup.com
www.caktusgroup.com


On Sun, Mar 31, 2019 at 3:08 PM Tobias McNulty 
wrote:

> On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes  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:
>
> [image: 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.

Re: Use CDN for djangoproject.com

[Tobias McNulty]

On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes  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:

[image: 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.

Re: Use CDN for djangoproject.com

[Adam Johnson]

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  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
>
> tob...@caktusgroup.com
> www.caktusgroup.com
>
>
> On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner 
> 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
>>> '///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 

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

tob...@caktusgroup.com
www.caktusgroup.com


On Mon, Feb 25, 2019 at 10:56 AM Florian Apolloner 
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
>> '///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 '///releases/'
>> and '//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, 

Re: Use CDN for djangoproject.com

[Florian Apolloner]

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 
> '///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 '///releases/' and 
> '//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  > 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 >  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
>>>
>>> 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, python.org does in fact use 
 Fastly:

 $ host www.python.org
 www.python.org is an alias for dualstack.python.map.fastly.net.
 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  wrote:

> I have not had great experience with Fastly in the past and 

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  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 (tob...@caktusgroup.com)
> 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  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,  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, 
>>> 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
 '///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 '///releases/'
 and '//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 

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 (tob...@caktusgroup.com)
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  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,  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, 
>> 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
>>> '///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 '///releases/'
>>> and '//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 
>>> 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 >>>
> Thanks for the test site, Tobias.

Re: Use CDN for djangoproject.com

[Tobias McNulty]

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  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,  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, 
>> 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
>>> '///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 '///releases/'
>>> and '//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 
>>> 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 >>>
> 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
>
> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
> Average Ping: 28ms
>  Browser: 

Re: Use CDN for djangoproject.com

[Tom Forbes]

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,  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,  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
>> '///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 '///releases/'
>> and '//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 
>> 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 >>
 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

 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, python.org does in fact use
> Fastly:
>
> $ host www.python.org
> www.python.org is an alias for dualstack.python.map.fastly.net.
> 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.)

Re: Use CDN for djangoproject.com

[Tom Forbes]

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,  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
> '///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 '///releases/' and
> '//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 
> 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 >
>>> 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
>>>
>>> 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, python.org does in fact use
 Fastly:

 $ host www.python.org
 www.python.org is an alias for dualstack.python.map.fastly.net.
 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  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 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

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
'///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 '///releases/' and
'//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 
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 
>> 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
>>
>> 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, python.org does in fact use
>>> Fastly:
>>>
>>> $ host www.python.org
>>> www.python.org is an alias for dualstack.python.map.fastly.net.
>>> 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  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  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 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

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  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
>
> 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, python.org does in fact use
>> Fastly:
>>
>> $ host www.python.org
>> www.python.org is an alias for dualstack.python.map.fastly.net.
>> 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  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  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  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, <
> in...@markusholtermann.eu> 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 

Re: Use CDN for djangoproject.com

[Cheng C]

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

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, python.org does in fact use Fastly:
>
> $ host www.python.org
> www.python.org is an alias for dualstack.python.map.fastly.net.
> 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 > 
> 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 > > 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 > 
>>> 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, <
 in...@markusholtermann.eu > 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, 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Adam, is there another provider you would recommend instead, that does not
require changing DNS providers? FWIW, python.org does in fact use Fastly:

$ host www.python.org
www.python.org is an alias for dualstack.python.map.fastly.net.
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  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  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  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, 
>>> 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 >>> > > 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 <
 cristianocc...@gmail.com> wrote:
 > >> Consider AWS's cloudfront then :)
 > >>
 > >> El martes, 12 de febrero de 2019, 2:34:09 (UTC-5), Florian
 Apolloner escribió:
 > >>> Especially cloudflare 

Re: Use CDN for djangoproject.com

[Adam Johnson]

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  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  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, 
>> 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 >> > > 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 <
>>> cristianocc...@gmail.com> 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, 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Fastly could be a good fit. I've reached out to see if they'd be willing to
provide a free account. If anyone on this list works at Fastly or knows
someone who does, feel free to email/introduce me off list, too.

Tobias

On Thu, Feb 14, 2019, 5:58 AM Tom Forbes  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, 
> 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 > > > 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 <
>> cristianocc...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com.
>> > >>  To post to this group, send email to
>> django-developers@googlegroups.com.
>> > >>  Visit this group at
>> https://groups.google.com/group/django-developers.
>> > >>  To view this discussion on the web visit
>> 

Re: Use CDN for djangoproject.com

[Josh Smeaton]

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  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, 
> 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 > > > 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 <
>> cristianocc...@gmail.com> 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 

Re: Use CDN for djangoproject.com

[Tom Forbes]

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, 
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  > > 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 <
> cristianocc...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com.
> > >>  To post to this group, send email to
> django-developers@googlegroups.com.
> > >>  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_source=footer
> >.
> > >>  For more options, visit https://groups.google.com/d/optout.
> > >>
> > >
> >
> >
> > >  --
> > >  You received this message because you are subscribed to the 

Re: Use CDN for djangoproject.com

[Florian Apolloner]

On Wednesday, February 13, 2019 at 11:25:37 PM UTC+1, Josh Smeaton wrote:
>
> Why do we not want to use Cloudflare?
>

Last time I checked (if one puts the full site behind cloudflare) you'd 
have nasty checks that usually triggers captchas for Tor users etc. From 
what I can tell there was no way to __fully__ turn it off (this might have 
changed though). Also cloudflare puts cookies on your PC etc, this is not 
something I need from a CDN.

Cheers,
Florian

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/d43a60ca-6281-4238-a023-4fe5c792b0c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Markus Holtermann]

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  > 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  
> > 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 
>  , 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 django-developers+unsubscr...@googlegroups.com.
> >>  To post to this group, send email to django-developers@googlegroups.com.
> >>  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
> >>  
> >> .
> >>  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 django-developers+unsubscr...@googlegroups.com.
> >  To post to this group, send email to django-developers@googlegroups.com.
> >  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
> >  
> > .
> >  For more options, visit https://groups.google.com/d/optout.
> >  
>  
> 
> 
>  -- 
>  You received this message because you are subscribed to the Google 
> Groups 

Re: Use CDN for djangoproject.com

[Tobias McNulty]

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  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 
> 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
 , 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 django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> 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
>> 
>> .
>> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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
> 
> .
> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Kye Russell]

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 
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
>>> , 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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
> 
> .
> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Tom Forbes]

I would highly recommend cloudflare. It's free, can be set up in 15 minutes
and works really, really well.

On Thu, 14 Feb 2019, 00:36 Cristiano Coelho, 
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
>>> , 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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
> 
> .
> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/CAFNZOJNvAvUxZbsi5TGkHzGw3TuXjstMtac-woB9x_1iNZvdhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Cristiano Coelho]

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 
>> , 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Josh Smeaton]

Why do we not want to use Cloudflare?

FWIW I agree that the docs site performance is not great (also from 
melbourne) - but I'd still suffer the performance hit over going via RTD 
mirrors for familiarity.


On Tuesday, 12 February 2019 18:34:09 UTC+11, Florian Apolloner wrote:
>
> 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 
>> , 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/285bd588-44a7-4152-a270-7f1be0e5de29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Florian Apolloner]

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 
> , 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/c1b5a962-a473-4f7f-84e7-fa9fa34c00a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Use CDN for djangoproject.com

[Cheng C]

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 , 
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/450abcbb-9bf9-487b-8376-74a02eb1a779%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.