How to debug a slow Wordpress?
-
Hi everyone,
I have a wordpress (managed) running here on my Cloudron that is setup with the default Cloudron user management. And some of its parts are working rather slowly.
Example:
Logging into the admin backend with my Cloudron user I see in my browsers network console that the request towp-login.phpspends 1.2 minutes in "waiting ttfb". After logging in its about as fast as you would expect from a php application.Similarly there is a woocommerce shop with stripe payments on this site. The last step of the checkout (which for new users would afaik also create a user account in wordpress) the "submit" takes about 2.5 minutes in "waiting (ttfb)".
I have found https://wordpress.org/support/article/debugging-in-wordpress/ and added it to my
/app/data/wp-config.php, but nothing is added towp-content/debug.log(file permissions allow read/write forwww-data).No exceptions in the log output of the app itself, it had 512mb of ram assigned. no memory messages in dmesg, the load average is at most at 0.3 (four cpus) and nothing is even causing double digit cpu load.
Does somebody here have an idea where to look?
-
Hi everyone,
I have a wordpress (managed) running here on my Cloudron that is setup with the default Cloudron user management. And some of its parts are working rather slowly.
Example:
Logging into the admin backend with my Cloudron user I see in my browsers network console that the request towp-login.phpspends 1.2 minutes in "waiting ttfb". After logging in its about as fast as you would expect from a php application.Similarly there is a woocommerce shop with stripe payments on this site. The last step of the checkout (which for new users would afaik also create a user account in wordpress) the "submit" takes about 2.5 minutes in "waiting (ttfb)".
I have found https://wordpress.org/support/article/debugging-in-wordpress/ and added it to my
/app/data/wp-config.php, but nothing is added towp-content/debug.log(file permissions allow read/write forwww-data).No exceptions in the log output of the app itself, it had 512mb of ram assigned. no memory messages in dmesg, the load average is at most at 0.3 (four cpus) and nothing is even causing double digit cpu load.
Does somebody here have an idea where to look?
@fbartels this isn't any real help at all (sorry) but I think the moral of the story is it's always better to just use WordPress Developer to ensure you get a more standard WordPress environment to work with (otherwise it seems you hit all sorts of issues, causing more issues for everyone. IMHO there should be no WordPress Managed app)
-
Hi everyone,
I have a wordpress (managed) running here on my Cloudron that is setup with the default Cloudron user management. And some of its parts are working rather slowly.
Example:
Logging into the admin backend with my Cloudron user I see in my browsers network console that the request towp-login.phpspends 1.2 minutes in "waiting ttfb". After logging in its about as fast as you would expect from a php application.Similarly there is a woocommerce shop with stripe payments on this site. The last step of the checkout (which for new users would afaik also create a user account in wordpress) the "submit" takes about 2.5 minutes in "waiting (ttfb)".
I have found https://wordpress.org/support/article/debugging-in-wordpress/ and added it to my
/app/data/wp-config.php, but nothing is added towp-content/debug.log(file permissions allow read/write forwww-data).No exceptions in the log output of the app itself, it had 512mb of ram assigned. no memory messages in dmesg, the load average is at most at 0.3 (four cpus) and nothing is even causing double digit cpu load.
Does somebody here have an idea where to look?
-
I've also used this plugin to find troublesome or slow plugins before https://wordpress.org/plugins/p3-profiler/ but I wouldn't do so now as it's not been updated for years (so that's no help either, sorry)
But, some alternatives here:
https://asphaltthemes.com/alternative-to-p3-plugin-performance-profiler/
-
Hi everyone,
thanks for your suggestions. I did not really have the time to dig further into this, but also found another recommendations for debugging in a wordpress extension called "Query Monitor".
Will still need to dig deeper, but can at least say that through enabling debug logging in the ldap auth extension that this seems to be long handled when
wp-login.phpfinally responds. -
Hi everyone,
thanks for your suggestions. I did not really have the time to dig further into this, but also found another recommendations for debugging in a wordpress extension called "Query Monitor".
Will still need to dig deeper, but can at least say that through enabling debug logging in the ldap auth extension that this seems to be long handled when
wp-login.phpfinally responds.@fbartels Just to throw some obvious ideas:
- Does it hang in other browsers? And also check with another device and another network.
- I would then try to see if
curl http://container_ip:xxxx/wp-login.phpis hanging on the server. The actual container_ip:port, you have to take from the nginx file in /etc/nginx/applications/appid.conf (there will be aproxy_pass).
If all the above still hang, I guess we can then assume it's something inside WordPress.
For inside WordPress:
- Disable LDAP plugin and others one by one and see if it has any effect. I suspect some plugin is slowing things down, it's the most common issue.
-
I'm using WP (dev) and I also experience a slow load on the initial dashboard log in. I have since installed an admin theme and it logs in much faster now. Some things that come to mind that usually cause WP speeds to suffer are Automattic's bloatware. If you have Jetpack installed do the following:
-
Go to Jetpack in the left menu and click on "Debug" in the footer then "Access the full list of Jetpack modules available on your site".
-
Disable all unnecessary modules - I only have "JSON API" active.
HTH.
-
-
Small update. The long wait time when logging in seems to be related to LDAP users. At least when logging in with a user that has been created manually the login immediately succeeds.
But this seems unrelated to the long wait time for the request when submitting the shopping cart, as this also happens when the ldap plugin is deactivated.
