[wp-hackers] Running several WordPress sites on the same server

[Simon Dunton - WP Sites]

For some time now I've wondered exactly how the APC opcode cache works and if it's possible to save RAM by making a number of separate WordPress installs share the same codebase. The alternative being assigning an additional 30MB+ of RAM for each virtual host (WordPress site) you add to Apache.

Over the last couple of days I've managed to do some load testing and other trials to see exactly how the APC opcode cache works and I can confirm that linking to a shared WordPress core using hard or soft links will save you lots of RAM (the more sites that share the codebase the bigger the benefits). This can be confirmed by looking at the system cache page of apc.php that comes with the APC distro.

So if you have 100 separate WordPress sites hosted on a single web server and each site maintains it's own WordPress core codebase you would need (at the very minimum) 30MB RAM per site, to fit all of your compiled PHP files in the cache (3GB total). If you don't have APC configured (in php.ini or apc.ini) with enough RAM for every PHP file processed by the server then you'll lose the performance gain because the cache will need to be completely expunged every time it fills.

It's much better to create a soft link to a single core codebase, so each of those 100 sites shares the same core WordPress files. Even though the core files are shared and only cached once for all of your sites you'll still need a bit of RAM for caching you're theme files and plugins but each site might only need to be allocated 10MB of RAM (1GB for all those sites). So that's a saving of 2GB RAM!

That above is just for the opcode cache, you might need another few GB if you want to use APC as an object cache for all those sites and if you're storing fully cached pages in the APC object cache you'll want even more.

So if you use the APC opcode cache and have multiple websites either use WordPress multisite or find a way to share the same code base with hard or soft links. Opcode caching makes a massive difference on page load speeds and the amount of resources the web server needs to process requests, especially if your PHP files are accessed over something like an NFS share. 

Simon



> ------------------------------
> 
> Date: Sun, 26 Aug 2012 12:58:31 +1000
> From: Jeff Waugh <jdub at bethesignal.org>
> Subject: Re: [wp-hackers] Running several WordPress sites on the same server
> 
> On Fri, Aug 24, 2012 at 5:48 AM, Ryan Hellyer <ryan at pixopoint.com> wrote:
> 
>> On Thu, Aug 23, 2012 at 5:57 PM, Ryan WP Mailing Lists
>> <ryan.wpmailinglists at gmail.com> wrote:
>>> The RAM benefit isn't something I had thought of. My assumption was its
>>> still 100 copies of WP running even it it was just from one source and so
>>> RAM footprint would be the same.
>> 
>> The RAM benefits Simon mentioned apply only to when you are using an
>> opcode cache. Opcodes store the compiled PHP in RAM. If you aren't
>> running opcode caching, then this will not provide any benefit.
>> There's usually no reason not be running opcode caching though.
>> 
> 
> They apply in both instances:
> 
> Without an opcode cache, your PHP runtime (mod-php, fpm, whatever) has to
> load, compile and execute completely different sets of files. They'll use
> RAM in the PHP runtime, waste system disk cache (which will help you a bit,
> but not much), etc. Plus, that's going to be a *lot* of work reading and
> compiling separate-but-identical WordPress codebases on every request!
> (Reminder: Always use an opcode cache.)
> 
> With an opcode cache, your PHP runtime won't have to load and compile all
> those files on every request, but it will maintain them separately in the
> opcode cache implemenation's shared memory (because they are different
> files, with different file names, it can't tell), which is a waste. You'd
> have to make your opcode cache N times the size it would normally need to
> be, just to get the benefit of using it at all.
> 
> In short: Try your very hardest not to run multiple WordPress instances...
> and hooray for multisite. :-)