Over the past few months the admin pages on my wordpress multisite site (around 80 sites) have been taking around 20 seconds to load. I am running the latest version of wordpress (version 4.1).

When I renamed the plugins folder to "plugins-deactivated" the admin area returned to a usual peppy speed of three seconds. However, when I renamed the folder back to "plugins" the site returned to it's usual 20 load times. I then deactivated all of the plugins and the admin area remained at it's usual slow speed, even though the plugins were deactivated.

I deleted all of the plugins and re-uploaded them one by one - the admin slowed with each additional plugin, no matter which plugin I uploaded. The obvious conclusion to draw is that Wordpress is loading each and every single plugin whether activated or not.

My question - how can I validate this assumption, and also, how can I further diagnose the problem?

Some other facts

  1. The site is a wordpress multisite with approx 80 sites
  2. It is running on Windows Azure
  3. The problem started in the past few months
  4. All plugins are activated
  5. I am running the query monitor plugin
  6. The installation is about eight years old

How can I find where the slowness originates?

Update 1: I have used the Chrome Dev Tools - and about 95% of the load speed is in the initial Get request - which would seem to suggest that the problem is happening on the server, not any of the ancillary load items

Update 2: The mere presence of the Gravity Forms plugin seems to add about 9 seconds to the load time of the site. It is happening when the plugin is deactivated.

Update 3: I have optimized the database to no effect.

  • It's very unlikely that each plugin is incrementally adding overhead, instead the culplit is most like a specific plugin(s). Look at your ram use per user. – Wyck Jan 26 '15 at 15:00
  • How would I find the ram use per user? Do plugins have there own user role? – Steve French Jan 26 '15 at 15:08
  • If you are using Firefox check out Firebug, or if you are using Chrome check out the Developer Tools, either of which can show you individual script load times, helping you to understand which is the culprit. Also, are you running your own server or is it a comercial server? – David Gard Jan 26 '15 at 15:50
  • the question as it is is impossible to answer, the reason might be your php configuration or your web server. You need to find the one plugin that creates the problem. as @Wyck said, it is bordering impossibility that all plugins are bad. – Mark Kaplun Jan 26 '15 at 15:50
  • I tried the dev tools - (I will be updating the question after this) and the initial get request is about 95% of the request time. – Steve French Jan 26 '15 at 15:53

I cannot speak to all plugins loading even when disabled, but gravity forms is not designed for heavy usage and could well be contributing significantly to the problem.


I used to work with a large client that used gravity forms and their admin panels ( and submitting forms ) became so slow that eventually they started timing out completely.

I no longer have the details lying around, but the problem with gravity forms at the time was that when a form is submitted, gravity forms does the following:

  • Loads every form that has ever been submitted
  • Cycles through each one of them until it hits the end
  • Uses that last submitted entry and adds one to generate the next unique id

At the time, I created a patch for the client, tested it, applied it, and submitted it to gravity forms ... and never heard back. The next few times the client upgraded gravity forms, it had the same problem and I had to re-apply the patch. I finally got them to switch services.


If you are using a lot of plugins that add extra columns to the wordpress admin panels ( e.g. list posts, list pages, etc. ), I'd expect that to be at least part of the problem is that most plugin authors use queries for each item in the system to modify the list rather than modifying the appropriate admin query to include what they seek in the post results.

BIG WARNINGS

  • If you are not completely comfortable with php, do not attempt this.
  • If at all possible, do this on a staging server first to ensure you don't break something
  • Absolutely be sure to back up any files you are going to edit before editing them ... so you can quickly put them back if needed

That being said, the only thing I can think of that could help would be to termporarily hack the wordpress core as follows:

(if running 4.1):

Enable the debug log and disable public display of errors( wp-config.php ):

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This will create a debug log file in your theme directory.

edit wp-settings.php and find the following in lines 213 to 216:

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
   wp_register_plugin_realpath( $plugin );
   include_once( $plugin );
}

change it to the following:

foreach ( wp_get_active_and_valid_plugins() as $plugin ) {
   wp_register_plugin_realpath( $plugin );
   $start_at = time();
   if ( WP_DEBUG_LOG ) {
      error_log("Loading plugin {$plugin}\r\n\t Start: {$start_at}");
   }
   include_once( $plugin );
   $end_at = time();
   if ( WP_DEBUG_LOG ) {
      error_log("\t Finished: {$end_at}");
      error_log("\t Total Time: " . $end_at - $start_at . '(s)' );
   }
}

That will only tell you if any plugin is doing something bad when first loaded.

You could temporarily do the same thing around the do_action('plugins_loaded') command found in the same file at line 237, but that would only tell you how long it took for all plugins to load.

To tell how long each one takes, you could hook into plugins_loaded at priority 1, read all plugins_loaded hooks, update them all to have different priorities, and then add your own plugins loaded action to log the time stamp between each interval.

e.g.

set up all plugins so the first using plugins loaded loads at 10, the second at 12, etc ... and then add your own plugins_loaded action between each one to log the time and maybe the time taken at each step:

9: started

11: 1 second (timestamp nnnnnnnnnn)

13: 0 seconds (timestamp nnnnnnn)

15: 8 seconds (timestamp nnnnnn)

I know this probably isn't a ton of help, but it might at least let you know what the culprit is.

By using the above debug commands, you can then carefully make some temporary edits to the core wordpress files to log how long things take without having faulty plugins crash the site by showing errors on the front end.

  • Also, if you haven't done so, you might check your wp-options table. If memory serves, gravity forms writes tons and tons of options and never cleans up after itself (transients I believe) – Privateer Feb 1 '15 at 4:22

In my experience if you are going to move your site from Windows to Apache Web Server you will get about 40% increase in speed as Apache is more efficient for Php Applications like WordPress.

But still if you have no choice to turn back you must try 10 Ways to Improve WordPress Performance on Windows.

Also I would suggest to use P3 (Plugin Performance Profiler) to analyse the the loading time for each plugin.

  • I tried the P3 plugin but all it did was tell me that 100 of my plugin time was being used by 100% of my plugins - it did not break it down by plugin. – Steve French Jan 26 '15 at 17:53
  • P3 plugin is suppose to display a pie chart containing run time for each of your plugin like in screenshot on this page. You might be missing some thing I guess. – Mohammad Mursaleen Jan 26 '15 at 18:09
  • I know! A Wordpress install over time develops it's own mysteries I guess – Steve French Jan 26 '15 at 18:36

Do you know debug bar? If you add it and you enable SAVEQUERIES you can see the time every query takes.

define( 'SAVEQUERIES', true );

Then you can add more debug bar plugins to profile some other stuff, like Debug Bar Remote Requests for remote requests and Debug Bar Slow Actions to profile WordPress hooks.

Most of the times you can easily find a single bottleneck, focus on the biggest one first. Try to isolate where it is coming from.

When you don't find the bottleneck using this method it's time to dive into PHP profiling but that is near impossible without PHP experience.

up vote 0 down vote accepted

The problem seems to be in the version of WordPress - specifically WordPress 4.1 while running MultiSite - I downgraded to 4.0.1 and all of the problems went away.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.