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

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Oct 2020 12:07:33 +1100

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/

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Oct 2020 07:49:03 +0200

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 <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Oct 2020 12:34:24 -0500

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.

RjS

These graphs are for a monitor that watches

https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml

This image shows the worst behavior during last weeks crunch.There is an 
SLA report you should be able to see at 
https://synthetics.newrelic.com/report/pQBOZ

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Oct 2020 09:49:40 +1100

> On 14 Oct 2020, at 4:34 am, Robert Sparks <[email-masked]> 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.

> This image shows the worst behavior during last weeks crunch.There is an SLA report you should be able to see at https://synthetics.newrelic.com/report/pQBOZ
> 
> 
> 
>>> 69  *** execution expired while fetching 
>>> https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml
>>> 
>>> 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.
>>> 
>>> 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/
>>> 
>>>