I am currently investigating the current slow/unresponsive server issues we have been experiencing lately.
I have created a diagnostic real time scanner that collects data continuously for me to isolate what the problem is as at present i don't have enough information. I will update you all when I know what the issue is.
Let me know if and when you experience these issues - please include the time and date of when you experinced it in this topic and then I can compare those times and dates with the logs to try and discern what exactly is slowing the whole server down.
I think I have located the culprit.
When the site was running Buddy press and PhpBB together I used synchronising scripts that allowed content from both sites to communicate with rath other. So when someone posted on Buddypress or PHPBB the posts and comments would display or be posted from either site.
These scripts were still running. Obviously Buddypress no longer exists so phpBB was still trying to communicate.
I deleted these old scripts and Thier cron jobs.
Hopefully that should stop the lag we have been experiencing.
Slow website speeds/non responsive moments
Moderator: atreestump
-
atreestump
- Posts: 924
- Joined: Sun Jun 15, 2025 3:53 pm
Slow website speeds/non responsive moments
Last edited by atreestump on Fri Mar 13, 2026 8:10 pm, edited 2 times in total.
-
kFoyauextlH
- Posts: 1983
- Joined: Sun Jun 15, 2025 3:53 pm
Slow website speeds/non responsive moments
That was awesome and ingenious that you were able to figure that out! I have not been experiencing any issues so far and it has helped speed up things greatly for what I've been trying to do over both sites. Thank you for working on this and fixing it so quickly!
Last edited by kFoyauextlH on Sat Mar 14, 2026 7:31 am, edited 1 time in total.
-
atreestump
- Posts: 924
- Joined: Sun Jun 15, 2025 3:53 pm
Slow website speeds/non responsive moments
[b]Server Performance Investigation – Summary Report[/b]
Over the past several days we carried out an extended diagnostics run on the IndieAgora server to determine the cause of intermittent slowdowns and high CPU usage.
The diagnostics recorded system load, PHP activity, web requests, and database behaviour over many hours so that patterns could be analysed rather than relying on a single moment in time.
[b]Main finding[/b]
The periods of high load were consistently associated with traffic directed at the legacy forum service.
During peak windows, multiple PHP worker processes handling forum requests became active at the same time. When several of these processes ran simultaneously, overall CPU usage temporarily increased and pages elsewhere on the server could appear slower.
Outside those periods the server returned to normal idle levels, confirming that the hardware and operating system themselves are functioning normally.
[b]Automated traffic[/b]
The logs also showed large volumes of automated traffic hitting public forum pages.
This type of traffic typically comes from web crawlers, search indexers, automated scraping tools, and general internet scanners.
Automated systems often generate many short-lived sessions, which can make a forum appear to have hundreds of “guests online” even though they are not real users.
[b]Security checks[/b]
Part of the diagnostics specifically looked for signs of compromise or malicious code execution.
The checks included inspection of running PHP processes, verification of files being accessed by the web server, review of suspicious request patterns, and confirmation that probed filenames do not exist on disk.
No evidence was found that the server or forum software had been compromised.
Some requests attempted to access suspicious filenames, but these were typical internet-wide scanning attempts and did not succeed.
[b]Database behaviour[/b]
Database activity remained stable throughout the monitoring period.
The database did not show signs of runaway queries or abnormal thread counts during peak load windows, which indicates that the slowdown was primarily caused by application-level request handling rather than a database fault.
[b]Current status[/b]
The diagnostics confirm that the server infrastructure itself is healthy, there is no evidence of intrusion, and the high load periods were linked to automated traffic hitting the forum application.
The legacy forum service is scheduled to be retired shortly, which will remove the component responsible for the majority of the observed load spikes.
[b]What users should expect[/b]
Once the forum is retired, overall server load should be significantly lower and page responses should remain consistently fast.
Routine monitoring will continue to ensure the platform remains stable.
Over the past several days we carried out an extended diagnostics run on the IndieAgora server to determine the cause of intermittent slowdowns and high CPU usage.
The diagnostics recorded system load, PHP activity, web requests, and database behaviour over many hours so that patterns could be analysed rather than relying on a single moment in time.
[b]Main finding[/b]
The periods of high load were consistently associated with traffic directed at the legacy forum service.
During peak windows, multiple PHP worker processes handling forum requests became active at the same time. When several of these processes ran simultaneously, overall CPU usage temporarily increased and pages elsewhere on the server could appear slower.
Outside those periods the server returned to normal idle levels, confirming that the hardware and operating system themselves are functioning normally.
[b]Automated traffic[/b]
The logs also showed large volumes of automated traffic hitting public forum pages.
This type of traffic typically comes from web crawlers, search indexers, automated scraping tools, and general internet scanners.
Automated systems often generate many short-lived sessions, which can make a forum appear to have hundreds of “guests online” even though they are not real users.
[b]Security checks[/b]
Part of the diagnostics specifically looked for signs of compromise or malicious code execution.
The checks included inspection of running PHP processes, verification of files being accessed by the web server, review of suspicious request patterns, and confirmation that probed filenames do not exist on disk.
No evidence was found that the server or forum software had been compromised.
Some requests attempted to access suspicious filenames, but these were typical internet-wide scanning attempts and did not succeed.
[b]Database behaviour[/b]
Database activity remained stable throughout the monitoring period.
The database did not show signs of runaway queries or abnormal thread counts during peak load windows, which indicates that the slowdown was primarily caused by application-level request handling rather than a database fault.
[b]Current status[/b]
The diagnostics confirm that the server infrastructure itself is healthy, there is no evidence of intrusion, and the high load periods were linked to automated traffic hitting the forum application.
The legacy forum service is scheduled to be retired shortly, which will remove the component responsible for the majority of the observed load spikes.
[b]What users should expect[/b]
Once the forum is retired, overall server load should be significantly lower and page responses should remain consistently fast.
Routine monitoring will continue to ensure the platform remains stable.