On a single server, we have a number of single-site WordPress installations (which have been around for many years and have worked fine ’til now) and one newer multi-site installation that has been working fine for a few months. They are all connected to separate databases on a separate MySQL server in the same data center.
In the last week or so, the dashboards on ALL of these installations will intermittently load extremely slowly or timeout altogether (depending on the browser — Chrome seems to give up sooner than Firefox), to the point of being unusable. When one of the dashboards is showing the problem, all of the other dashboards on the same server do the same. When one is working, all are working. This will happen at any point during the login or dashboard-using process.
The actual reader-facing blog pages work fine at these times, and the other non-WordPress pages on the server all work fine. A WordPress installation on a separate server but connected to the same MySQL server also works fine during these times. It’s only the dashboards on this one server.
I’ve tried disabling nearly all of our plugins (the ones not needed to keep the blogs minimally functional, like Akismet and Google Analyticator). I’ve tried upping the PHP memory limit. No luck with any of this. Our host has been trying to help me but is also at a loss.
Any ideas would be greatly appreciated!
Have you taken a look at the error logs? Who is your host? Do you have Process Manager or anything similar to be able to tell what processes are running? A way to tell where most of your bandwidth is being used? Just some ideas on where you might be hitting resource limits.
How large are the databases? Can they be cleaned up at all?
Might be time to switch hosts. I’d start with error logs to see if anything is broken.
Turns out this problem was due to something wrong with SSL/HTTPS. Once I turned off ‘FORCE_SSL_ADMIN’ on our WP installations and tried loading the dashboards via just HTTP, they loaded up just fine. So the problem is not with WordPress but with our SSL configuration.
This makes perfect sense in hindsight: the reason only the dashboards were seeing the problem is because they were the only pages using SSL.