Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I manage a server for a client who has several Wordpress blogs. They all precariously balance on PHP/FastCGI/nginx and it all works at the moment, just using a little more RAM than I'd normally be comfortable with.

Since setting this all up, Wordpress 3 came out and (with a plugin to maintain domain mapping) allows me to import all the blogs into one central blog. So I know I can achieve a desirable operating outcome... I'm just not sure if I want to sink hours into doing it.

The client now wants to add a couple more blogs to the server. We're clearly at a crossroads where it would make sense to act now if I'm going to go down the multisite road.

I don't really care about the clear administrative benefits rather the performance and the amount of free RAM.

Do you think I would be correct in assuming one codebase in RAM would cost less than having half-a-dozen single sites? Are there any other performance pros (or cons) that I'm missing?

share|improve this question
up vote 3 down vote accepted

The short answer is you are better off going with a single Wordpress 3 install rather than maintaining separate databases, servers, configs, etc. for the sites individually. The key piece of information to understand here is that Wordpress 3 contains most of the core code that runs the multi-million site/blog, minus some obvious mass-scaling optimizations.

The only challenge you may run into in the future is if one of your sites wants to branch off / go somewhere else - you will need to define a migration process (which ultimately should not be that difficult :) ).

share|improve this answer
that challenge is easy to fix: don't let them leave! j/k :) – warren Jul 29 '10 at 16:03

I'm not sure how you would save system resources assuming your databases are still separate ones for each site.

I would do it anyway being it only for improved usability and less maintenance windows.

share|improve this answer

1) Yes

2) Simply determine whether the benefit of saving some RAM is worth the man-hours of conversion you'll be doing. Potential downtime, data loss, etc. are all things to watch out for. Would it be cheaper to just add more RAM?

share|improve this answer

I doubt you'd be saving much on memory, if any. It's not as if there are three or five persistent wordpress processes constantly running on the server. Sure nginx and mysql are running, but the extra threads are only started once browser requests are made and scripts start calling functions and making database calls.

If you want to save resources you should be more concerned with the wordpress theme and plugins the client is running. Many free themes and plugins make a lot of unnecessary database calls. I personally am of the school of thought that it's best to 'hard code' as much as possible into the theme as it's not really hard coding at all, it's just PHP and easily editable. Also do look into cacheing (wp super cache), and a PHP accelerator.

I have several wordpress sites running on the same VPS and haven't bothered to combine them together. They don't all use the same plugins so I am able to save there (I think - I haven't checked to see if you can enable/disable plugins per site in 3.0), and I like to hope that if one gets hacked, the others are still somewhat isolated due to different DB credentials.

If the additional ease of management isn't a draw for you or your client, I don't see the benefits.

share|improve this answer

If you are using PHP in FastCGI, with a different cgi pool for security reason: yes, you will save a bunch of ram. If you are using PHP in FastCGI with a single pool, you will probably only benefits in performances if you are using some opcode cacher like APC.

Concerning security, most attacks are done regardless of DB credentials, so it's probably superfluous. If someone gives away his own password, the problem is elsewhere.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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