The server host is limiting the site performance, saying it is caused by slow queries, then pointing to wpForo as the cause.
This is from a chat with the host:
The forum is not just slow for one visitor. The logs show a repeated pattern:
- Many
GET /forum/requests take approximately 16–83 minutes to finish.- Several end with HTTP 500 after roughly 45–86 minutes.
- Other requests return HTTP 200 but still take an abnormally long time.
- Bingbot requests are also hitting
/forum/; several were rate-limited with HTTP 429.That means the forum page is triggering a long-running WordPress operation. The most likely sources are the forum plugin itself, its database queries, or an attached feature such as Better Messages, not the basic hosting connection and not your
SELECT 1test.The access logs cannot reveal the exact SQL statement or plugin function, but they do establish that
/forum/is repeatedly tying up server resources. This makes the forum stack the leading suspect behind the slow-query protection and CPU pressure.
Hi @codings,
Those response times (16–83 minutes for GET requests, with some timing out at 45–86 minutes) are definitely concerning and point to a serious bottleneck. The fact that you're seeing this pattern repeatedly across multiple requests suggests this isn't a one-off issue but rather a systemic problem. The good news is that this is usually diagnosable and fixable once you identify the root cause.
Based on the troubleshooting guide, here's a step-by-step approach to pinpoint what's happening:
- Install Query Monitor – This is your first diagnostic tool. Add the Query Monitor plugin to your WordPress installation. Once activated, it will show you exactly which database queries are running slowly (anything over 0.1 seconds is worth investigating). Pay special attention to wpForo-related queries and check the total query count on your forum pages.
- Check for database optimization issues – Your hosting provider mentioned this could be related to table indexes and optimization. Run a database repair and optimization. Most hosting panels (cPanel, Plesk, etc.) have tools for this, or you can use phpMyAdmin to check and repair your tables. Look specifically at wpForo tables for corruption or missing indexes.
- Review server resources during forum access – While someone is accessing the forum (or simulate traffic), check your server's CPU, memory, and I/O usage. If memory is maxing out or disk I/O is pegged, that could explain the extreme slowness. This information helps determine if it's a resource limitation or a query efficiency problem.
- Examine Bingbot activity – You mentioned Bingbot is also hitting /forum/. If the bot is crawling aggressively without proper throttling, it could be overwhelming your database. Check your robots.txt and consider adding crawl-delay directives for bots.
Once you've run Query Monitor and identified which specific queries are slow, share those details here and we can dig deeper into whether it's a wpForo configuration issue, a hosting limitation, or corrupted data. What does Query Monitor show as your slowest queries?
This is still an ongoing issue, now with more information from the server host:
"wpForo’s periodic forum AJAX request is being processed slowly and concurrently for multiple visitors. The CPU spike comes from the cumulative PHP/database work behind that wpForo request, not from admin-ajax.php itself.
What is the component in wpForo that is causing this "live polling" and consistent usage of admin-ajax.php? And how can it be stopped or reduced?
The site is experiencing it even when visitors are not on forum pages. Could it be caused by the wpForo widget that is on every page to display recent posts?
Also, Ultimate Member is used to manage forum profiles, and wpForo User Profile/Notification widget is in use.
@codings the main source for WPForo's Live User notifications feature you are probably seeing is:
wpForo → Settings → Forum Notification → Enable User Notification Live Update
Go to: WordPress Admin → wpForo → Settings → Forum Notification → Turn off
Clear all caches—especially server cache, your WordPress caching plugin, and any CDN cache.
@deepvyas Thank you