Subject: [Tools-discuss] tools.ietf.org slow first load of htmlized drafts

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Feb 2021 09:18:46 -0800

For the past few weeks I've been seeing very long page load times (ca. 90
seconds) for many or most htmlized drafts that I try to load from
tools.ietf.org.  Subsequent loads are the expected (fast) speed, and
anecdotally it is possible for another user to "prime the cache" and spare
me the long wait.

I recognize that tools is a volunteer provided service and am willing to
take this as a prod to move to the datatracker-hosted version, but I wanted
to ask if others are seeing this and/or it's a known issue.

Thanks,

Ben

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Feb 2021 01:00:02 +0100

On 2021-02-01, at 18:18, Benjamin Kaduk <[email-masked]> wrote:
> tools.ietf.org.  

You are not the only one seeing this.

> Subsequent loads are the expected (fast) speed, and

I’m not seeing this, though — I see the browser cache, but then doing a curl on the same URI again takes a long time (real 1m16.825s), as does another curl, but then a third delivers in a second, and a fourth takes 1m16.516s.  (Maybe I just got three different servers, though.)

The long delays are consistent enough that it looks like they are programmed.

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Feb 2021 16:08:32 -0800

> You are not the only one seeing this.

Thanks for confirming.

To elucidate a bit more on my remark about the datatracker-hosted version,
I believe that translating https://tools.ietf.org/html/<draft> to
https://datatracker.ietf.org/doc/html/<draft> will provide a similar,
albeit less familiar, experience without the loading delay.

> The long delays are consistent enough that it looks like they are programmed.

It is possible that some of what I'm seeing is browser cache.
But I definitely did not have draft-ietf-masque-ip-proxy-reqs in cache when
I asked my friend to load an arbitrary draft, and it loaded quickly for
both him and then shortly thereafter for me as well.

-Ben

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 02 Feb 2021 11:08:43 +1100

I'm seeing similarly slow results, but in the order of 35s.  A great deal of time (32 seconds, I think) goes by before the response begins, then it is reasonably fast getting the content.  Some brief investigation shows that the TLS handshake is taking extra time (my TLS client times out), so maybe that explains what you are both seeing.

On Tue, Feb 2, 2021, at 11:00, Carsten Bormann wrote:
> I’m not seeing this, though — I see the browser cache, but then doing a 
> curl on the same URI again takes a long time (real 1m16.825s), as does 
> another curl, but then a third delivers in a second, and a fourth takes 
> 1m16.516s.  (Maybe I just got three different servers, though.)
> 
> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: 
> [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe): 
> https://www.ietf.org/mailman/listinfo/tools-discuss
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Feb 2021 01:21:37 +0100

Oh.  I looked more closely:

time curl -vI https://tools.ietf.org/html/draft-liu-dyncast-ps-usecases-00
*   Trying 4.31.198.61...
* TCP_NODELAY set

(Here is the long delay!)

* Connection failed
* connect to 4.31.198.61 port 443 failed: Operation timed out
*   Trying 4.31.198.62...
* TCP_NODELAY set
* Connected to tools.ietf.org (4.31.198.62) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
[…]

$ host tools.ietf.org
tools.ietf.org has address 4.31.198.62
tools.ietf.org has address 64.170.98.42
tools.ietf.org has address 4.31.198.61
[…]

Grüße, Carsten

---

From: Jay Daley <[email-masked]>
Date: Tue, 2 Feb 2021 13:30:23 +1300

Apologies for this.  AFAIK one of the tools servers, 4.31.198.61, had died and cannot be restarted and it has not been removed from the DNS.  I have asked for it to be removed.

For info, the tools.ietf.org <http://tools.oietf.org/> servers are donated boxes under Henrik’s admin control and located in the AMS office.  Clearly, all production services need to move off them.

Jay

> On 2/02/2021, at 1:21 PM, Carsten Bormann <[email-masked]> wrote:
> 
> * Report datatracker and mailarchive bugs to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Tue, 2 Feb 2021 13:54:11 +1300

> On 2/02/2021, at 1:30 PM, Jay Daley <[email-masked]> wrote:
> 

It turns out that the DNS is also controlled by Henrik and while we can just undelegate and replicate it on the main DNS servers, I am loathe to do that without understanding the consequences.  This will therefore have to wait until tomorrow.

My apologies again.

Jay

>> On 2/02/2021, at 1:21 PM, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> time curl -vI https://tools.ietf.org/html/draft-liu-dyncast-ps-usecases-00 <https://tools.ietf.org/html/draft-liu-dyncast-ps-usecases-00>
>> *   Trying 4.31.198.61...
>> * TCP_NODELAY set
>> 
>> * Connected to tools.ietf.org <http://tools.ietf.org/> (4.31.198.62) port 443 (#0)
>> * ALPN, offering h2
>> $ host tools.ietf.org <http://tools.ietf.org/>
>> tools.ietf.org <http://tools.ietf.org/> has address 4.31.198.62
>> tools.ietf.org <http://tools.ietf.org/> has address 64.170.98.42
>> tools.ietf.org <http://tools.ietf.org/> has address 4.31.198.61
>> […]
>> 
>> Grüße, Carsten
>> 
>> Tools-discuss mailing list - [email-masked] <mailto:[email-masked]>
>> * Report datatracker and mailarchive bugs to: [email-masked] <mailto:[email-masked]>
>> * Report tools.ietf.org <http://tools.ietf.org/> bugs to: [email-masked] <mailto:[email-masked]>
>> * Report all other bugs or issues to: [email-masked] <mailto:[email-masked]>
>> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss <https://www.ietf.org/mailman/listinfo/tools-discuss>
> 
> -- 
> Jay Daley
> IETF Executive Director
> [email-masked] <mailto:[email-masked]>
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Feb 2021 02:09:43 +0100

> It turns out that the DNS is also controlled by Henrik and while we can just undelegate and replicate it on the main DNS servers, I am loathe to do that without understanding the consequences.  Thi…

I don’t remember how often I have had to set up an emergency box (or an IP address on an existing box) for cases like this that has just a TCP forwarder to a live one.
Each time, there was no canned software that could do that forwarding so I had to write that forwarder from scratch as well.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Feb 2021 02:15:20 +0100

> Each time, there was no canned software that could do that forwarding so I had to write that forwarder from scratch as well.

The universe has advanced.

http://www.rinetd.com <http://www.rinetd.com/>

brew install rinetd

Grüße, Carsten