Please correct me if I'm wrong.

I take it that many outages here are caused by misbehaving bots effectively causing a denial of service attack. Especially those bots ignoring no-follow settings.

Now often nodes here are linked not by ID but by name [name]

If the exact name is missing as node title, they cause a supersearch for all node titles containing the words (in any order).

These searches are very slow and I suppose expensive, since the results aren't cached.

Nodelets, which are constantly shown, contain many such links, especially behind ? marks, which until recently were missing real targets.

Now the question:

Could it be that such named-links turning into searches contribute to outages in the monastery?

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re: Bots, missing nodes and outages
by Corion (Patriarch) on Jan 09, 2025 at 20:59 UTC

    No, the recent outages were due to network issues.

      I can't connect from home, but when I run a remote desktop at work, I can connect from there.

      traceroute from work:

      1 # Redacted 2 195.113.69.5 0.366ms 0.307ms 0.289ms 3 195.113.69.169 0.360ms 0.299ms 0.343ms 4 195.113.67.5 0.462ms 0.445ms 0.458ms 5 195.113.69.54 1.265ms 1.079ms 1.081ms 6 * * * 7 80.249.212.170 14.305ms 14.304ms 14.158ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 204.16.241.181 128.520ms 116.818ms 118.734ms 16 204.16.243.217 122.314ms 113.822ms 111.790ms 17 * * * 18 66.39.54.27 137.129ms 128.118ms 109.758ms

      traceroute from home:

      1 192.168.100.1 (192.168.100.1) 1.701 ms 1.659 ms 1.639 ms 2 10.21.32.1 (10.21.32.1) 9.593 ms 9.574 ms 9.546 ms 3 switch-bb-pha-stodulky-switch-gpon-pha-stodulky.ptp.poda.network ( +10.11.185.25) 9.462 ms 9.443 ms 9.425 ms 4 static-3248824331.poda.cz (193.165.32.11) 9.560 ms 9.452 ms 9.5 +23 ms 5 static-3248824321.poda.cz (193.165.32.1) 9.350 ms 9.331 ms 9.37 +8 ms 6 datacamp-fra-2.peering.cz (185.0.20.200) 11.132 ms datacamp-fra-1 +.peering.cz (185.0.20.28) 11.202 ms datacamp-fra-2.peering.cz (185.0 +.20.200) 11.174 ms 7 unn-169-150-192-197.cdn77.com (169.150.192.197) 14.477 ms unn-169 +-150-192-199.cdn77.com (169.150.192.199) 17.906 ms 17.876 ms 8 * * * 9 204.16.241.168 (204.16.241.168) 108.787 ms * * 10 204.16.241.183 (204.16.241.183) 108.113 ms * 108.694 ms 11 204.16.243.219 (204.16.243.219) 108.675 ms * * 12 * * * 13 * 204.16.243.219 (204.16.243.219) 109.318 ms * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

      So, 204.16.243.217 knows the way, but 204.16.243.219 doesn't. whois returns exactly the same details about both the addresses.

      map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
        For me, at $work: on Friday, my experiments agreed with choroba's traceroutes above, where 204.16.243.219 was causing a hard-stop whereas 204.16.243.217 was skipping one but eventually making it to a perlmonks server. But today, whichever perlmonks IP I am tracing to, it is going through .219 but is connecting.

        Over the weekend at $home, I could never get a connection using my home network. But if I took my phone off wifi and tried to connect with my phone's data provider instead, it could get a response and let me read posts.

        And when I try https://www.isitdownrightnow.com/perlmonks.org.html, they say it's been down "~6 days" at this point.

        It looks like it's highly dependent on where you are trying to access from whether or not you'll be able to get a route to a perlmonks server.

      I am still unable to connect from home (you have my data). Now replying from another network using ssh -X


      Enjoy, Have FUN! H.Merijn
      IIRC there were times when one was able to directly run a complicated super search by clicking a link.

      AFAIR this was deactivated for performance reasons. Now we need to additionally click the [Search] button after "preloading"

      Hence having links which automatically run searches can't be a desired situation.

      Especially when dealing with bots.

      Update

      Probably some confusion, I'm not talking about the recent outages. I didn't experience any when I started this thread, tho it seems to be drifting in that direction.

      I'm interested to know if fixing named links would improve performance notably.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

Re: Bots, missing nodes and outages
by talexb (Chancellor) on Feb 18, 2025 at 16:12 UTC
      tab@music4:~ 10:37:34 $ traceroute perlmonks.org traceroute to perlmonks.org (66.39.54.27), 64 hops max 1 192.168.2.1 4.968ms 0.826ms 0.840ms 2 142.124.37.96 3.226ms 2.761ms 1.831ms 3 * * * 4 * * * 5 64.230.59.182 15.342ms 15.096ms 12.061ms 6 * * * 7 64.230.79.87 15.144ms 14.969ms 14.928ms 8 66.208.216.145 15.893ms 14.909ms 14.695ms 9 96.110.37.17 18.235ms 18.024ms 17.979ms 10 96.110.34.118 26.730ms 26.739ms 25.853ms 11 71.25.197.218 28.125ms 27.762ms 28.166ms 12 * * * 13 204.16.241.168 29.563ms 28.629ms 28.015ms 14 204.16.241.183 28.123ms 28.075ms 26.793ms 15 100.90.63.35 25.467ms 24.944ms 24.828ms 16 100.90.63.6 22.362ms 23.018ms 21.750ms 17 * * * 18 66.39.54.27 29.945ms 30.011ms 29.651ms tab@music4:~ 10:38:35 $

    That's my latest traceroute to perlmonks.org. Ubuntu/Firefox gives me a blank page, but Ubuntu/Chrome works fine. OSX/Chrome also works fine.

    Alex / talexb / Toronto

    For a long time, I had a link in my .sig going to Groklaw. I heard that as of December 2024, this link is dead. Still, thanks to PJ for all your work, we owe you so much. RIP Groklaw -- 2003 to 2013.