Re^6: Perlmonks site has become far too slow

If you log out, you'll notice that someone, I suppose Corion is experimenting with caching this thread (only?)

Try https://www.perlmonks.net/?node_id=11166139 (or whatever domain logs you out)

One problem is immanent, it's not enough to disable/delete a single node on update, but the parent chain too, because of the sub-thread view showing replies. (Your and Bliako's reply are missing)

Since we are working with multiple servers I'm pessimistic about using the filesystem for caching, I think it's far easier to implement in the database server.

FWIW I took a look into the Everything code yesterday, and while it's hard to tell without testing environment (my usual grievance) how it really works, I found that there is a central method

getNodebyID which occasionally does caching if called with the according flags.

There is a whole Cache class blessed to $DB to handle it.

There is also an updateNode method.

So in theory this should be easily done, alas only Gods can dev and test especially if the core Everything:: modules are concerned, which can't be patched by pmdevs.

Pmdevs like me are reduced to smartass comments here. (I can't even tell if the online versions of Everything:: really show the currently productive code)

Update

In hindsight caching of getNodeById won't be sufficient, I don't think it returns already html

If you are interested in the gory details please check out the original documentation of Everything, (i.e. before it was heavily patched into Perlmonks)

The Everything Bible

Cheers Rolf
_{(addicted to the Perl Programming Language :)

see Wikisyntax for the Monastery}

Comment on Re^6: Perlmonks site has become far too slow Select or Download Code

Replies are listed 'Best First'.
Re^7: Perlmonks site has become far too slow (AnoServer/Load Balancer) by LanX (Saint) on Aug 30, 2025 at 23:23 UTC
> Since we are working with multiple servers I'm pessimistic about using the filesystem for caching, I think it's far easier to implement in the database server. Unless it's possible to direct all AnoMonk requests to one server only. This would have the huge advantage that other web-servers wouldn't be impacted by increased bot activities. OTOH update events could happen on other servers and would need to be logged via the DB, so that the "Ano-Server" could discard the cached page. update Or storing the cache in a shared file system, unfortunately I have no experience to tell how efficient this is. But in this case the Ano-Server wouldn't need to run Everything, just a web-server (apache/Nginx/...) distributing static files. The updates of the static files are comparatively rare and could be easily handled by the dynamic servers. Alas some pages can't be static like log-in, chatterbox, other users. So the load-balancer or a redirection rule has to bring Ano-monks to the real servers. Anyway ... no matter if it's a static or dynamic server, setting up a dedicated server for Anomonks would improve many issues instantly. Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply]
Re^8: Perlmonks site has become far too slow (Reverse Proxies) by LanX (Saint) on Sep 03, 2025 at 13:11 UTC
Regarding the "macro" caching of anonymously viewed pages. After some searching I think the most robust approach is to set up one or more reverse proxies to handle the bots and SEO. They can cache all static requests locally and rules can check the cookies and relay logged in users to the upstream servers for dynamic content. Cache management is also included, nginx for instance can receive "purge" requests of cached urls remotely via web requests, which means those proxies don't even need to be on the same box. And this doesn't even need to be triggered directly from inside the Everything engine. Running an external cronjob checking for new nodes via XML ticker (like every x minutes) could be implemented immediately and update all proxies. š So no need to patch anything inside the monastery except server settings. I think "Micro caching" to speed up the engine's most frequent evals and queries is also possible but would certainly require patching the Everything codebase. But this would require good benchmarking and is less relevant for our "bot war". Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery} š) of course querying the DB directly for new and updated nodes and votes would be even better. My point is to show how flexible and available this strategy would be while immediately shielding off our engines from DNS attacks.	[reply]
Re^7: Perlmonks site has become far too slow by choroba (Cardinal) on Aug 31, 2025 at 19:11 UTC
> Since we are working with multiple servers I'm not sure this is still true. Can Corion clarify? `map{substr$_->[0],$_->[1]\|\|0,1}[\\|\|{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^ARGV,3]`	[reply] [d/l]
Re^8: Perlmonks site has become far too slow by Corion (Patriarch) on Sep 01, 2025 at 06:37 UTC
We are using only one webserver, behind a single IP address.	[reply]
Re^9: Perlmonks site has become far too slow by Discipulus (Canon) on Sep 01, 2025 at 12:08 UTC
Hello Corion, > ..a single IP address.. which one? `https://www.whatsmydns.net/#A/perlmonks.org` gives the 66.39.54.27 but both still respond to my pm-monitor.pl `perlmonks.org @ https://66.39.54.27/index.pl? 200 OK 21.6182 + Kb (22137 bytes) in 9.123193 seconds 2.3696 Kb/s perlmonks.org @ https://216.92.34.251/index.pl? 200 OK 21.6182 + Kb (22137 bytes) in 0.974809 seconds 22.1768 Kb/s` [download] As side note (but this might be error on my part) when I connect with the browser to the above IPs I get the certificate for `css.perlmonks.org` and the same from chrome: a certificate named `css.perlmonks.org` and no Subject nor CNs. Similarly from commandline: `openssl s_client -showcerts -connect perlmonks.org:443 CONNECTED(00000264) depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Ne +twork, CN = USERTrust RSA Certification Authority verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s: <------ weird + to be empty i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USER +Trust RSA Domain Validation Secure Server CA ...` [download] L* There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.	[reply] [d/l] [select]
Re^10: Perlmonks site has become far too slow by choroba (Cardinal) on Sep 01, 2025 at 12:49 UTC
Re^9: Perlmonks site has become far too slow by LanX (Saint) on Sep 01, 2025 at 10:09 UTC
OK strange, did I totally misremember this or did it change recently? I seem to remember having discussions about 2 servers having different certificates. Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply]
Re^10: Perlmonks site has become far too slow by choroba (Cardinal) on Sep 01, 2025 at 10:50 UTC
Re^11: Perlmonks site has become far too slow by LanX (Saint) on Sep 01, 2025 at 14:28 UTC