Efficiently manage a huge number of blogs given server-side restrictions

I work in a company that is built around selling the customers WordPress blogs for a monthly fee plus some up-front money for design work. The boss envisions that we will have several thousand customers, each paying something to the tune of twenty EUR per month, all handled by a single IT person working normal hours and a few salespeople/designers.

We currently have about 500 active blogs in a single WordPress installation on a moderately powerful managed server. We’re running on SharDB because MySQL doesn’t like having 20.000 tables in the same database. Since the server’s admin interface (Plesk 11) doesn’t allow us to associate more than one database with a database user, SharDB has been modified so that each database uses its own separate connection with its own user credentials.

This creates problems when an admin user tries to do anything. The admin interface calls get_blogs_of_user() on every page load, which in turn connects to each database to get the blog options etc. This means that the active connection is repeatedly closed and replaced with a different one, which means that a single page call results in 1.600 database connections being opened (vs. 60 for a normal user). This degrades performance heavily.

One solution would be to split our WordPress installations. This would limit the number of database connections neccessary and thus speed things up a bit. Unfortunately it would also mean that we’d have to manage each WordPress installation separately. For instance, since we don’t have shell access to the server we’d have to make any changes to files via FTP, repeating the process for every WordPress installation.

Another solution would be to get a shell server and roll our own MySQL installation so we can avoid the one-DB-per-user issue but unfortunately we can’t have any non-managed servers due to legal concerns – ie. in case of downtime we need to be able to shift the blame to the hosting provider, which a shell server won’t allow us to do. (Blame shifting is important becaue the boss is afraid that our customers (mostly SMEs) would hit us with huge lawsuits over lost business if our server went down and we were responsible. This way we can deflect the blame to our provider and apparently that makes us safe.)

Are there any other options I have overlooked?

Here are the limits which they’d have to adhere to:

  1. Must be scalable. The boss envisions a final customer base of
    approximately 20.000, which should be reachable with the given
    solution (excluding additional hardware purchases etc).
  2. Can’t cost serious money. Let’s say that about 1 EUR per month per
    customer is okay.
  3. Can’t involve a self-administered server. Anything that requires
    even shell access is a no-no. We must still be able to blame the
    hosting provider if any downtimes occur.
  4. Must be able to be administered by a single person.
    The business plan apparently doesn’t work out if we have to pay more
    than one IT person full-time.
  5. Must still be based on WordPress. We can’t migrate our existing
    customers to something else; they’re confused enough as it is. (We
    don’t exactly market to the tech-savvy crowd.)

That’s about it.

Solutions Collecting From Web of "Efficiently manage a huge number of blogs given server-side restrictions"