Earlier this month I made the move from Esosoft to Dreamhost. There were many reasons for this, among them:
-
Esosoft didn’t give me control over my DNS registry. This leads to an amount of frustration after a certain point.
-
Esosoft didn’t give me a shell account; I would have had to run a full private server to get one.
-
Esosoft didn’t have the latest version of ruby; any app development I did was highly curtailed by this.
-
Esosoft didn’t have basic ssh/sftp access, only FTP access.
-
When there were outages, Esosoft did not issue any status updates.
-
When there was scheduled maintenance, Esosoft did not issue any warnings.
After a MySQL database outage with no status updates, I decided to switch to Dreamhost. Maybe they aren’t the most ideal solution—back on Esosoft I could run without caching if I so desired—but they definitely are a step up in many practical features.
However, I soon discovered that WordPress is not very efficient when it comes to database queries. This was problematic on Dreamhost in ways that it was not on Esosoft, often causing “error making database connection” messages for WordPress and my various web stats installs.
Even with the page caching of W3 Total Cache on, I still saw problems.
That was when I remembered that (a) the worst DB query offender in WordPress is the widget bar, and (b) WP Widget Cache exists.
Why have a widget cache on top of another caching plugin? Apart from offering very fine control over when a widget is refreshed (different widgets can have different refresh times and triggers), WP Widget Cache also does what plugins like W3 Total Cache don’t: cut down on the queries that widgets generate.
Every time W3 Total Cache creates a page cache without WP Widget Cache, it runs every single widget query. But with WP Widget Cache on, W3 Total Cache may not even run those queries for hours on end (in my case, some of my widgets go for 24 hours cached). Suddenly a page that used to generate 15 extra queries for the widgets is cut down to no extra queries.
All my database connection errors went away after activating WP Widget Cache and tweaking each widget’s cache setting.
End result: I’m pretty happy on Dreamhost. Until, I assume, the next level of readership, in which case I’m going to need to shell out for a virtual private server—but that’s not likely to come for some time, if ever.