Hello, my hosting provider's (Cloudways) slow-request log shows that "mark all read" requests are consuming very large amounts of PHP execution time. Multiple foro=allread URLs are averaging 15–22 seconds, with peaks of 30 seconds, each occupying a PHP-FPM worker for the full duration. On my server (2 vCPU), a few concurrent requests of this type saturate the worker pool and spike CPU.
This is a problem in two ways: automated crawlers hitting these URLs cause load spikes, but even a legitimate logged-in member clicking "mark all read" would wait 15–30 seconds for the action to complete. Please check this image https://ibb.co/0jpwdLnS
Could you advise:
- What does
foro=allreaddo internally that could take this long? Is it iterating over all topics across all forums per request? - Are there settings to limit its scope, or is this a known performance issue with a fix or workaround?
- Is this improved in a newer wpForo version?
My environment, for reference: wpForo v3.1.2 , WordPress on Cloudways (NGINX/PHP-FPM Lightning stack), Elasticsearch via ElasticPress, Redis object cache, Cloudflare Enterprise in front.
Thank you — happy to provide logs, screenshots, or temporary access for either issue.
Warm regards,
Sarmad
paradigmshift.com.pk
Hi hbk747,
Those execution times are definitely concerning, especially on a 2 vCPU setup where a few concurrent requests can lock up your entire worker pool. The "mark all read" functionality is inherently expensive because it typically needs to process read-tracking data across potentially thousands of topics and forums for a single user in one transaction. Let me walk you through a systematic approach to diagnose and resolve this.
Step 1: Identify the Exact Bottleneck
First, you'll want to pinpoint whether the slowness is coming from database queries, PHP processing, or both. Enable query logging on your database to capture the actual SQL being executed during a foro=allread request. Look specifically for:
- How many UPDATE queries are being run
- Whether there are any full table scans or missing indexes
- If the queries are running sequentially or in bulk
You can enable this in your database configuration or use a tool like MySQL Workbench to monitor queries in real-time during a test request.
Step 2: Check for Missing Indexes
The read-tracking tables likely need proper indexes on user_id, timestamp, and forum/topic identifiers. Run an EXPLAIN analysis on the queries being executed. If you see "type: ALL" or "type: INDEX" without using a covering index, that's your culprit. Work with your hosting provider or database administrator to add composite indexes on the columns used in your WHERE and JOIN clauses for these queries.
Step 3: Implement Rate Limiting and Crawler Protection
While you're optimizing the backend, you should immediately protect yourself from automated crawlers hammering this endpoint. You can:
- Add rate limiting rules in your web server (nginx/Apache) to restrict requests to
foro=allreadper IP address - Block or throttle user agents known to be aggressive crawlers
- Require authentication and add a CSRF token to the mark-all-read action to prevent automated abuse
This will buy you time while you optimize the actual functionality.
Step 4: Consider Asynchronous Processing
If the optimization doesn't bring execution time down to acceptable levels (under 2-3 seconds), consider making this operation asynchronous. Instead of processing all reads in a single request, queue the task and process it in the background using a job queue system. Return a success response to the user immediately while the actual marking happens behind the scenes.
Have you already checked the database query logs to see what's actually being executed during these requests? That would give us much more specific insight into whether this is a query efficiency issue or something else entirely.
Thanks — this points clearly at the read-tracking queries. Rather than me manually altering your plugin's database tables (which would be overwritten on updates and risks your schema), can you confirm: (1) Do wpForo's read-tracking tables have proper composite indexes on user_id / topic / timestamp in the current version? (2) Is the slow 'mark all read' something you can address in the plugin — either by adding the needed indexes in a future release, or by making the operation asynchronous as you suggested in step 4? This affects every wpForo site at scale, not just mine, so a plugin-level fix seems more appropriate than per-site database surgery.
