I think it's that the server(s) know when I am unavailable. This morning I have 30 minutes to look after them, but they are working again...

But I'm happy to report that the German Perl Workshop is going well and we have 50+ attendees, which brings os to the limit of the room (with the current seating plan).

This morning I have 30 minutes to look after them, but they are working again...

Yes, all back to normal today after being pretty much unusable yesterday when each page load took minutes. Hopefully there's something obvious in the logs when you have a chance to look. Without doing any real telemetry yesterday (was having to fight other fires here, unfortunately) I can report that it was taking a long time to connect and then a long time to retrieve the page on top of that. Seemed pretty low level - maybe TCP or TLS - rather than within the application but that's just gut feel.

---

🦛

PerlMonks has been unreachable for me for the last six hours, although pings to 66.39.54.27 and 216.92.34.251 were successful during that time.

And this morning, it's usually responding, but slow -- https://www.isitdownrightnow.com/perlmonks.org.html has been giving 4-6 second response time, when normally for "good" it's on the order of 30ms. And just now, while I was trying to do a couple to get a good range, at least some of the time, it says "no response" instead of slow response.

I've checked from my side (chatterbot worker), it seems to work normally atm. And i've checked if it accidentaly does too many webcalls, but that, too, seems not to be the case.

I'm planning to add additional logging in the future, to log timeouts and such.

The site was essentially ususable for me yesterday. From Firefox, I got timeouts (after 30 seconds); using GET from the command line ..

tab@music4:~ 16:16:13 $ time !!
time HEAD https://perlmonks.org/
200 OK
Connection: close
Date: Mon, 15 Apr 2024 20:17:20 GMT
Accept-Ranges: bytes
ETag: "a347-616284ad46c31"
Server: Apache
Content-Length: 41799
Content-Type: text/html
Last-Modified: Mon, 15 Apr 2024 20:16:10 GMT
Client-Date: Mon, 15 Apr 2024 20:17:20 GMT
Client-Peer: 66.39.54.27:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=Sectig
+o Limited/CN=Sectigo RSA Domain Validation Secure Server CA
Client-SSL-Cert-Subject: 
Client-SSL-Cipher: TLS_AES_256_GCM_SHA384
Client-SSL-Socket-Class: IO::Socket::SSL


real    0m59.471s
user    0m0.171s
sys     0m0.028s
tab@music4:~ 16:17:20 $ time HEAD https://perlmonks.org/
200 OK
Connection: close
Date: Mon, 15 Apr 2024 20:37:08 GMT
Accept-Ranges: bytes
ETag: "a45f-616288c0b1b9e"
Server: Apache
Content-Length: 42079
Content-Type: text/html
Last-Modified: Mon, 15 Apr 2024 20:34:24 GMT
Client-Date: Mon, 15 Apr 2024 20:37:08 GMT
Client-Peer: 66.39.54.27:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=Sectig
+o Limited/CN=Sectigo RSA Domain Validation Secure Server CA
Client-SSL-Cert-Subject: 
Client-SSL-Cipher: TLS_AES_256_GCM_SHA384
Client-SSL-Socket-Class: IO::Socket::SSL


real    1m10.827s
user    0m0.172s
sys     0m0.024s
tab@music4:~ 16:37:08 $
[download]

The site is live now, but I'm seeing response times in the 35-40 seconds range, which suggests there's still something happening that's slowing things down.

I had some timeouts today, after the parent post was made. About an hour ago.

Usually I consider we antipodeans are ahead of the curve.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Usually I consider we antipodeans are ahead of the curve.

Heh ... yes, I used to look at it that way, too.
Then, early one Saturday back in September 2016, I sat in my hotel room in Kirkwall (Orkneys) and listened to a radio broadcast (on my laptop) of the AFL Grand Final being played in Melbourne.
At the end of the game it occurred to me that those at the ground had to wait until around 5pm on Saturday afternoon to find out the result, whereas I knew the result at around 7.30 am on Saturday morning.
I felt very privileged ;-)

Cheers,
Rob