What discussion topics are well-addressed here? Which not?

[mcint]

Opening this Discussion as an on-going routing mechanism. Some ideas might be best just to chat about in person and some can benefit from talking through with others on chat channels. This forum seems suited for fleshing out speculative ideas, and creating a topic-based record for newcomers to understand the goals, values, and challenges we're currently pursuing.

[mcint]

Let's talk website performance and uptime.

From

• (possible new) haproxy cache & load balancer (and robust rate limiting)
• to caddy
  • caching
  • new rate limiting, on ips & session identifiers
• to MediaWiki
  • newly adding file caching / final page for anonymous viewers
  • long existing intermediate object caching

to read replica databases to serve traffic, perhaps on another host(s).

[mcint]

Let's discuss ways to simplify the operational overhead of running services, trying new ones in parallel, and performing upgrades, rollbacks, and testing in other environments before deployment.

• I've long, gently called for more deployment by docker 🚢. I would love to have others able to view, deploy, and locally test & tune, the same deployables we run---and in a simple way.

• Some contributors also want to explore other, more declarative deployment specifications: nix 🧊, or guix 🦬.

• Likely not for the website, but for some other services we also have people exploring k8s ☸️, git-ops in ArgoCD 🐀, and other mention Talos 📐.

Do share also if you've had success with one of these, or are willing to lead an independent trial of setting up, deploying, and exploring one/some of these.

[SuperQ]

A load balancer would really only be useful if we were serving from multiple nodes. We could do this, but I feel like it's complication we don't want to introduce into NB infra.

If we need more resources, maybe we can simply grow our VPS node's resources.We could expand from 2 shares to 4 shares pretty easily and get more memory/CPU.

[mcint]

We probably should up the shares.

• $86.25 per slice / yr == 7.1875 / slice / mo -- $14 now to $28, monthly — just for m3

---

I propose it because I specifically notice caddy, not just fastcgi or mysql, crashing since the addition of the rate-limit plugin. There more configuration tuning to do, but in case it's a limitation beyond easy caddy rate-limit plugin configuration, load balance software is designed exactly to help make the load shedding decisions easy to configure.

Honestly, keeping the wiki up and available in the face of random (adaptive, as a collective, at least over days/weeks) / follow-every-link / database heavy (Special:RecentChanges, other Special:RecentChanges, api.php, history, visual edit diffs, Special:MobileDiff) requires better tools, or more effort and thought—and I still rate human time as expensive and these kinds of configuration both fragile and fickle.