Re: [xml2rfc] xml2rfc.tools.ietf.org site availability

[Mark Nottingham <[e-mail]>]

> On 14 Oct 2020, at 4:34 am, Robert Sparks <[e-mail]> wrote:
> 
> The server xml2rfc.tools.ietf.org has been under a few waves of highly distributed nuisance load, particularly at the end of last week.
> 
> I am watching xml2rfc with newrelic synthetic monitors, and generally the service is performing reasonably. (newrelic does not make it easy to create live public graphs, but I'm attaching some manually captured ones).
> 
> We are already looking at reimplementing the bibxml generators, and the service that provides them using more modern infrastructure. I expect that to be something that comes together next year.
> 
> I'll ask about the difficulty of adding an explicit Cache-control to what we have now, and look at whether fronting the existing site with cloudflare is reasonable.

That's good to hear - thanks.


> 
> RjS
> 
> These graphs are for a monitor that watches 
> 
> https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml
> 
> <aljaikppjnnbilil.png>
> 
> 
> 
> 
> 
> 
> 
> <lodkhhabfeckpnii.png>
> 
> This image shows the worst behavior during last weeks crunch.<eijjgbphpegekmoc.png>There is an SLA report you should be able to see at https://synthetics.newrelic.com/report/pQBOZ
> 
> 
> 
> On 10/13/20 12:49 AM, Carsten Bormann wrote:
>> I’m wondering whether kramdown-rfc should be using more of the datatracker features here, as in
>> 
>> 
>> https://datatracker.ietf.org/doc/bibxml3/draft-ietf-core-groupcomm-bis/xml
>>  (*)
>> 
>> Pro: datatracker might have a higher reliability
>> Pro: datatracker is faster in having the data available for new I-Ds
>> Con: that solves only part of the problem (only works for I-Ds, other bibxmls including RFCs would still need to be taken from xml2rfc.tools.ietf.org).
>> 
>> (The fetch timeout currently is 60 s for new fetches; I don’t think adding to that will make a difference.)
>> 
>> Grüße, Carsten
>> 
>> (*) Oh: 
>> https://redbot.org/?id=87dhdaee
>> 
>> 
>> 
>> 
>>> On 2020-10-13, at 03:07, Mark Nottingham <[e-mail]>
>>>  wrote:
>>> 
>>> Hello,
>>> 
>>> The xml2rfc Web site's availability has been causing errors in the HTTP WG document builds (and elsewhere, anecdotally) for a little while now.
>>> 
>>> For example:
>>> 
>>> ~~~
>>> 68 /github/home/.cache/xml2rfc/reference.RFC.7234.xml: fetching
>>> 69  *** execution expired while fetching 
>>> https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml
>>> 
>>> 70  *** No such file or directory @ rb_sysopen - /github/home/.cache/xml2rfc/reference.RFC.7234.xml for /github/home/.cache/xml2rfc/reference.RFC.7234.xml
>>> 71  make: *** [draft-ietf-httpbis-client-hints.xml] Error 66
>>> ~~~
>>> 
>>> at 
>>> <https://github.com/httpwg/http-extensions/runs/1244800935?check_suite_focus=true#step:6:68>
>>> . This has been happening fairly often in the last month or two.
>>> 
>>> Does the Tools team have some sense of why this is? E.g., is the site monitored? Can it be put behind a CDN to improve availability?
>>> 
>>> Also, looking at the responses served (e.g., 
>>> <https://redbot.org/?id=2n90ryy0>
>>> ), I notice that there isn't explicit freshness on them, which means that some caches won't store them, while others will choose their own freshness lifetime. It would be better to set an explicit one, e.g., `Cache-Control: max-age=3600`.
>>> 
>>> Cheers,
>>> 
>>> 
>>> --
>>> Mark Nottingham   
>>> https://www.mnot.net/
>>> 
>>> 
>>> _______________________________________________
>>> xml2rfc mailing list
>>> 
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/xml2rfc
>> _______________________________________________
>> xml2rfc mailing list
>> 
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xml2rfc

--
Mark Nottingham   https://www.mnot.net/