MariaDB Tuning complete

• Tweaked tmp_table_size   = 64M and max_heap_table_size = 64M
• Tweaked query_cache - however, this is contrary to the views of the MariaDB devs - their view is that it doesn’t scale well with multi-core concurrency with a view that Redis/Memcached are more efficient. They even removed it in the next version of MariaDB after my installed version.

The modules table is quite big - too big to include a screenshot... so a ChatGPT summary analysis of the data is below. But before getting tothat, let me share some thoughts on what we have.

This is the Discussions home page. Within the data, we see the popular discussions list That should be a single count by category SQL query, that should be almost zero seconds to render. Instead, almost 2 seconds. Then the full discussions list. While I ahve 1727 posts, the app only displays 12 entries with associated profile icons, and count of replies and topic images. Render of that data if the SQL is well optimised should be very low.

The data here is on the discussions-home .... My home page has similar issues. But it would be good to focus here for now - since its worse...

Modules Breakdown (7.869 sec total)

1. Discussions Module

• serviceBrowseLatest → 2.8113 sec
• serviceBrowsePopular → 1.9864 sec
• ➡️ Subtotal: 4.7977 sec (~61% of all module time)

2. Persons Module

• 38 serviceProfileUnit calls in the 0.15–0.18 sec range, plus many in the 0.05–0.11 sec range, and smaller ~0.02 sec sub-calls.
• When summed across this run, they add up to ~2.97 sec.
• ➡️ That is ~38% of all module time.

3. Everything Else

• System services, meta tags, categories, injections, featured discussions, etc.
• Together under 0.1 sec (<1%).

Key Observations

• Discussions + Persons combined = ~7.77 sec (~99% of module time).
• Discussions is heavier per call (nearly 5 sec in just two queries).
• Persons is death-by-a-thousand-cuts: no single call is catastrophic, but ~3 sec total comes from repeated profile lookups.