Use CDN for djangoproject.com

372 views
Skip to first unread message

Cheng C

unread,
Feb 12, 2019, 12:43:41 AM2/12/19
to Django developers (Contributions to Django itself)
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:

 Average Ping: 245ms
 Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 1.16s, Load: 1.48s

 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. 

Florian Apolloner

unread,
Feb 12, 2019, 2:34:09 AM2/12/19
to Django developers (Contributions to Django itself)
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

Josh Smeaton

unread,
Feb 13, 2019, 5:25:37 PM2/13/19
to Django developers (Contributions to Django itself)
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.

Cristiano Coelho

unread,
Feb 13, 2019, 7:36:35 PM2/13/19
to Django developers (Contributions to Django itself)
Consider AWS's cloudfront then :)

Tom Forbes

unread,
Feb 13, 2019, 7:45:55 PM2/13/19
to django-d...@googlegroups.com
I would highly recommend cloudflare. It's free, can be set up in 15 minutes and works really, really well.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.

Kye Russell

unread,
Feb 13, 2019, 7:48:03 PM2/13/19
to django-d...@googlegroups.com
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. 

--

Tobias McNulty

unread,
Feb 13, 2019, 8:22:37 PM2/13/19
to django-developers
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


Markus Holtermann

unread,
Feb 14, 2019, 1:32:08 AM2/14/19
to Django developers
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 <m...@kye.id.au wrote:
> > I’ve been hearing that there are other CDN providers that offer a very comparable service for a fraction of the cost of CloudFront.
> >
> > Anyways, at this stage let’s not get bogged down on provider decisions. I’m curious if anyone has any general objections to a CDN of any kind.
> >
> > It shouldn’t be that big a deal to automatically invalidate when the docs are updated. But I’m sure there’s something I’m missing.
> >
> > On Thu, 14 Feb 2019 at 8:36 am, Cristiano Coelho <cristia...@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-develop...@googlegroups.com.
> >> To post to this group, send email to django-d...@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&utm_source=footer>.
> >> For more options, visit https://groups.google.com/d/optout.
> >>
> >
>
>
> > --
> > You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> > To post to this group, send email to django-d...@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 <https://groups.google.com/d/msgid/django-developers/CANK-yknQ1Auf6CFD-%2B94qoATQ2K%2By0poLw%3DaxyJYjO3PaHOQWA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-develop...@googlegroups.com.
> To post to this group, send email to
> django-d...@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 <https://groups.google.com/d/msgid/django-developers/CAMGFDKTAVv_3HJCTHqd-vSOFt9-WUvUDEGR8sYuawyVT7MAotQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Florian Apolloner

unread,
Feb 14, 2019, 2:37:39 AM2/14/19
to Django developers (Contributions to Django itself)


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

Tom Forbes

unread,
Feb 14, 2019, 5:58:41 AM2/14/19
to django-d...@googlegroups.com
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.

Josh Smeaton

unread,
Feb 14, 2019, 6:16:57 AM2/14/19
to django-d...@googlegroups.com
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. 

You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/UovZxrUPWLU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

Tobias McNulty

unread,
Feb 14, 2019, 8:07:55 AM2/14/19
to django-developers
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

Adam Johnson

unread,
Feb 14, 2019, 8:26:38 AM2/14/19
to django-d...@googlegroups.com
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.


For more options, visit https://groups.google.com/d/optout.


--
Adam

Tobias McNulty

unread,
Feb 14, 2019, 10:09:09 PM2/14/19
to django-developers
Adam, is there another provider you would recommend instead, that does not require changing DNS providers? FWIW, python.org does in fact use Fastly:

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

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

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

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

Cheers,
Tobias

Cheng C

unread,
Feb 14, 2019, 11:48:51 PM2/14/19
to Django developers (Contributions to Django itself)
Thanks for the test site, Tobias. 

Tested from Melbourne, Australia: 

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

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

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

Tobias McNulty

unread,
Feb 15, 2019, 7:14:19 AM2/15/19
to django-developers
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

Tobias McNulty

unread,
Feb 23, 2019, 7:00:50 PM2/23/19
to django-developers
Hi all,

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

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

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

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

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

So, some questions for the list:

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

Tobias

Tom Forbes

unread,
Feb 23, 2019, 7:10:51 PM2/23/19
to django-d...@googlegroups.com
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.

Tom Forbes

unread,
Feb 23, 2019, 7:15:11 PM2/23/19
to django-d...@googlegroups.com
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.

Tobias McNulty

unread,
Feb 24, 2019, 9:35:59 AM2/24/19
to django-developers
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


Tom Forbes

unread,
Feb 24, 2019, 10:40:12 AM2/24/19
to django-d...@googlegroups.com

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.

Tobias McNulty

unread,
Feb 24, 2019, 2:40:50 PM2/24/19
to django-developers
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



Florian Apolloner

unread,
Feb 25, 2019, 10:56:39 AM2/25/19
to Django developers (Contributions to Django itself)
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

Tobias McNulty

unread,
Mar 11, 2019, 9:07:06 AM3/11/19
to django-developers
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



Adam Johnson

unread,
Mar 11, 2019, 9:18:02 AM3/11/19
to django-d...@googlegroups.com
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


For more options, visit https://groups.google.com/d/optout.


--
Adam

Tobias McNulty

unread,
Mar 30, 2019, 4:42:08 PM3/30/19
to django-developers
Thanks, Adam! Agreed our usage is fairly simple.

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

Screenshot 2019-03-30 14.52.23.png


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

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

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

Cheers,

Tobias McNulty
Chief Executive Officer

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


Josh Smeaton

unread,
Mar 30, 2019, 7:14:49 PM3/30/19
to django-d...@googlegroups.com
Thanks for running with the idea, and so quickly too! 

Tom Forbes

unread,
Mar 30, 2019, 7:32:20 PM3/30/19
to django-d...@googlegroups.com

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

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

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

Tobias McNulty

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

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

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

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

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

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

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

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

Cheers,
Tobias

Tobias McNulty

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

Cheers,

Tobias McNulty
Chief Executive Officer

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


Reply all
Reply to author
Forward
0 new messages