[Closed] Severe performance drop after 4–5 hours with WPML enabled (staging site available)

Hi Bobby,

Thanks for the follow-up — you can log in now. If you still see a reload on the wp-admin form, use the “Login” button on the homepage and then visit /wp-admin/.

What’s done
Updated WPML core and all add-ons to 4.8.2.
Ran at WPML → Support → Troubleshooting:
Cleanup and optimize string tables
Clear invalid strings
Remove ghost entries from WPML tables
PHP time limit: 300. Stack: Nginx + PHP 8.3-FPM, MariaDB 10.11, timezone Europe/Athens (UTC+03:00).

Status
The issue persists on live after ~4–5 hours with WPML enabled (timeouts/504). Disabling WPML immediately restores normal performance.

On staging we haven’t reproduced it yet. Note: staging auto-clones from live daily at 06:00 Greece time (UTC+03:00).

Please proceed with your profiling and let me know if you need any specific logs enabled (e.g., WPML performance debug logs) or a particular MU/plugin to be added.

Thanks

Hi Bobby,

Thanks for the follow-up.

Access
The login issue is now resolved. You can access the staging backend normally. If /wp-admin/ ever reloads, you can also use the front-end “Login” button and then go to /wp-admin/.
(I’m not re-posting credentials here for security; they’re the same as the private message above.)

Scope of investigation
I’m providing the staging environment so you can check whether there is anything in WPML’s operation—on its own or in combination with other plugins and our custom code—that could lead to the degradation we see on live. The staging is on a different server than live and is auto-cloned daily at 06:00 (Europe/Athens, UTC+03:00).

Reproduction constraints
We haven’t been able to reproduce the slowdown on staging yet. On live, there isn’t a precise time when it starts; after some hours under real traffic the site deteriorates (504/timeouts), and very quickly the server becomes unreachable, so capturing data in the moment is hard.

Proposal to move forward

If you can simulate traffic/load on staging for a sustained period, we might be able to trigger the issue. I’m happy to keep staging running under that load window as long as you need.

I can enable WPML performance logging and any additional debug you recommend (MU plugin, Query Monitor, Debug Bar, DB query logging, etc.). Please let me know what exactly you want enabled and I’ll switch it on immediately.

Environment on staging: Nginx + PHP 8.3-FPM, MariaDB 10.11, WPML 4.8.2 (core & add-ons). We already ran the WPML → Support → Troubleshooting tools you suggested.

If there’s a specific profiling checklist or a small MU-plugin you prefer for capturing slow queries / cache misses related to WPML, feel free to install it on staging and I’ll keep an eye on it while you run tests.

Thanks again—happy to follow your lead on the next steps.

Best,

Hi Bobby,

Understood. Since we can’t reproduce this on staging, we’ll proceed on live exactly as you suggested.

Plan on LIVE (next slowdown window):

Install and briefly enable Query Monitor (only during the incident), then deactivate it right after.

Capture and share screenshots of:

Queries → Duplicates (with the Component column visible, to see if any are from WPML or its add-ons).
Queries sorted by time (slowest first).
HTTP API Calls (in case any remote calls are looping).

Provide the WP error log. We’ll enable logging (only during the test) with:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

We’ll then grab the relevant portion of /wp-content/debug.log (sanitized for sensitive paths) and share it.

Context we’ll include with the report:

Exact URLs profiled (homepage, taxonomy archives, product pages, etc.).

Timestamps (Europe/Athens, UTC+03:00) and a note on traffic levels when the issue occurred.

A brief server health snapshot (CPU/RAM/DB connections) to separate infra load from app-level symptoms.

If there’s any MU plugin or additional Query Monitor configuration you prefer to capture more signal (e.g., deeper duplicate-query breakdown), let me know and we’ll add it before the next window.

Thanks

Hi Bobby,

Thank you for your reply.

Yes — you can access the live environment using the same credentials previously shared privately for the staging site.
No configuration or data changes are needed; feel free to review and monitor performance as required.

We’ll also collect and share the data you requested (Query Monitor screenshots, error log, and server metrics) as soon as the next slowdown occurs.
Since we can’t keep WPML enabled continuously on production due to the performance impact, we’ll enable it during specific low-traffic periods to reproduce the issue safely.

Please let me know once you’ve been able to log in successfully.

Best,