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 <tob...@caktusgroup.com> wrote: > 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 > <https://daniel.haxx.se/blog/2016/08/18/http2-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.
