Slow website problems

This week I got a question from a client who's struggling with performance issues on her Drupal/CiviCRM site.

The public-facing side runs fine, but for logged-in staff users, many of the admin pages are excruciatingly slow.

I had them reach out to their hosting service, who of course wants to be able to see it happening in order to diagnose it.

Unfortunately, things seem to be running fine now.

Yes, “unfortunately” — because it's pretty hard to debug a problem if you can't see it happening, and recreating a performance issue is a lot like trying to recreate a traffic jam: everybody knows what one looks like, but it's not so easy to make it happen on command..

So what to do? Well, she has a few options:

1. Record the problem happening.

She could wait until it's happening again, and record a screencast showing that the front end operates normally, and that certain admin pages are very slow.

She could at least show this to the hosting support team as evidence that the problem actually exists.

If she tells them exactly when it was happening, and the IP address from which she was accessing the site, they may even be able to find something in the logs that will help identify the problem.

2. Just be persistent.

Even without such a video, she can continue describing the problem to the hosting support team and hope that persistence persuades them to at least propose some solution.

3. Experiment with other hosting.

She could try hosting the site somewhere else: a larger server with the current hosting provider, or a server at a different provider. This might even be a temporary experiment, in which she could decide to go back to the original hosting service.

If the problem never appears there, she could assume it must have been something with the current hosting setup and then decide whether to go back to that or continue with the new service.

If it does appear under the new hosting, that's an indication that something is amiss in the site itself, and we could dig in further to identify what that is.

4. Quantify the problem in order to budget for a solution.

Any given problem has some quantifiable cost. It may not be easy to identify that quantity, but there's probably some way to put a number on it.

If she can do that, then she can make a rational decision about how much to invest in a solution, and when to just live with it because it's not worth the cost of fixing it.

Here's the thing:

Performance issues can be hard to debug. And any sporadic problem can be really hard to debug.

It's usually worth considering a few different options and then making a rational plan.

It definitely sucks, but deciding how much it sucks can help a lot to determine how hard you're willing to work to fix it.

All the best,
A.