Multisite or Not to Multisite, That is the Question

So when is Multisite (WPMU) Used?

1. When all the hosted sites are similar. Like WordPress.com for example, they are all supposed to be “blogs”. They are all forced to live with the same features, not much for options.

2. They are all managed by the same company or business. Like a set of landing page websites for a marketing firm that’s generating leads.

3. For a SAAS (Software as a Service) model. For example, you are selling the ability for people to register there own Multisite and use your premium themes and plugins as there own for a “Wedding Website” where all the peices are provided for them as they register and create there own site (usually for a fee).

Limitations with WPMU:

1. PERFORMANCE: All sites must take the extra time to load the entire plugin directory. For 30+ sites, there is going to be a ton of crap in that directory, increasing load times and decreasing performance. WPMU in general eats more RAM and processing power as it has to sort through more records and files.

2. DB PERFORMANCE: You DB is gonna get hammered, on shared hosting this will slow all your sites down. Creating new records and updating records locks the records for re-indexing, so an influx of registrations or form fills on 1 site could slow down all other sites.

3. SECURITY: The more plugins you have, the more security issues you potentially open up. If 1 plugin from 1 site lets in hackers, they take over the entire set of sites you have installed. Then, secondly, you run into security issues that may be less common, but can happen when a person registers on 1 site and is able to cross over to another site with admin based security holes. If the core directory gets hacked, all websites hosted together will contain the hacked files, likely phising sites, making a hackers job 30x more powerful and easy (if you had 30 sites).

4. CLIENT LIMITATIONS: Clients cannot have FTP access over there sites, except to there sites “blog” directory for uploads. How do you plan on providing client website backups? You would have to do something fancy and figure out which plugins and themes they are using and not back up the others. Along with backups, how would they migrate away from you? Maybe your plan is to “force them to stay”, but thats not ethical business. Clients cannot have admin access to install there own plugins / themes (only super admins can do that).

5. INCOMPATIBILITY: Most plugins on the WP.ORG repo are not built and tested for WPMU. So tons of plugins will be broken when installed on multisite.

6. CONFIGURATION: Only 1 configuration can be made, without doing some pretty complex programming. That means only 1 wp-config file, only 1 htaccess file, etc. What if 1 client needs 128mb of ram per page load while another should stick to the default? No way easy way of separating the configs.

7. SPAM: You will naturally get more spam registrations because meta data will inform bots that you have multiple sites and they will register on all of them. Comment on all of them, etc.

2 thoughts on “Multisite or Not to Multisite, That is the Question”

Seth, Thanks for this. I’ve recently been doing some time trials using a plugin called P3 and have discovered that WP Jetpack is a slug. So I don’t use it anymore. (although I understand there is a lite version/or beta). It makes sense then that loading all plugins needed for a variety of sites will possibly have some overlapping. I didn’t know but hoped the folk at WordPress would engineer around this but from what you are saying that is not the case.

I have had a play with multisites and really liked it from an Admin point of view. ie: one place to go when updating themes and plugins. But InfiniteWP handles that task quite well for me and I also like the fact that if I have to migrate one of my sites to another host its easier to do whereas it would be harder if it was part of a larger multisite.

Your article has settled it for me. A good hosting service and an individual WP install for each client.

Cheers,

John.

Performance and DB Performance:

Company A with 30 sites, on WP x 30. Company B with identical 30 sites, on WPMultiSite.
Each has 29 sites load once and 1 site load 500 times.
Cost to the hosting account for Company A: 529 page loads.
Cost to the hosting account for Company B: 529 page loads.
MySQL use for each company: almost identical, see below.
WordPress core file requests for each company: identical.
WordPress theme file requests for each company, if use the Company Theme: identical.
WordPress theme file requests for each company, if each site uses a different theme: identical.
WordPress plugin file requests for each company: almost identical, see below.

It doesn’t matter at all whether using WP or WPMultiSite, it is the same core code, the same theme code, the same plugin code, the same database use. Each page is different, each site is different, but the account use is the same.

Server usage: The WPMultiSite files are identical (1 installation), the WP files are copies (30 installations). Server caching is slightly more likely to serve cached files for WPMultiSite.

If the company uses the same theme for all its sites, on WPMultiSite the theme files are more likely to be cached; if different theme for each site, cache use is identical. Ditto for the collection of plugins.

Database use: Database usage is identical, except that on WPMultiSite, each site has a unique ID, which takes one extra database query per page load. (Each WordPress page takes dozens to hundreds of database queries.)

WordPress uses record locking (changes tie up one record, not the entire table), and each site has its own set of database tables. MySQL has virtually identical performance whether using 30 databases or 1 database with 30 times as many tables.

Plugin use: Identical except that on WPMultiSite, mapping of somedomain.com to site ID 27, would be done using the Domain Mapping plugin. Only plugins that are Network Enabled are loaded for every site on the network.

Conclusion: Negligible difference in page load time, database use, memory use, disk use. Disk storage for MultiSite is lower, since only one copy of WordPress core files (about 70MB per installation, also negligible for most hosting accounts).

Note: WPMU is an obsolete product, discontinued with the release of WordPress 3.0. Now there is only WordPress, configured in single-site mode or multi-site mode.

John Anderson on March 25, 2014 at 2:27 am said:

Seth, Thanks for this. I’ve recently been doing some time trials using a plugin called P3 and have discovered that WP Jetpack is a slug. So I don’t use it anymore. (although I understand there is a lite version/or beta). It makes sense then that loading all plugins needed for a variety of sites will possibly have some overlapping. I didn’t know but hoped the folk at WordPress would engineer around this but from what you are saying that is not the case.

I have had a play with multisites and really liked it from an Admin point of view. ie: one place to go when updating themes and plugins. But InfiniteWP handles that task quite well for me and I also like the fact that if I have to migrate one of my sites to another host its easier to do whereas it would be harder if it was part of a larger multisite.

Your article has settled it for me. A good hosting service and an individual WP install for each client.

Cheers,

John.
George Lerner on July 6, 2014 at 12:25 pm said:

Performance and DB Performance:

Company A with 30 sites, on WP x 30. Company B with identical 30 sites, on WPMultiSite.
Each has 29 sites load once and 1 site load 500 times.
Cost to the hosting account for Company A: 529 page loads.
Cost to the hosting account for Company B: 529 page loads.
MySQL use for each company: almost identical, see below.
WordPress core file requests for each company: identical.
WordPress theme file requests for each company, if use the Company Theme: identical.
WordPress theme file requests for each company, if each site uses a different theme: identical.
WordPress plugin file requests for each company: almost identical, see below.

It doesn’t matter at all whether using WP or WPMultiSite, it is the same core code, the same theme code, the same plugin code, the same database use. Each page is different, each site is different, but the account use is the same.

Server usage: The WPMultiSite files are identical (1 installation), the WP files are copies (30 installations). Server caching is slightly more likely to serve cached files for WPMultiSite.

If the company uses the same theme for all its sites, on WPMultiSite the theme files are more likely to be cached; if different theme for each site, cache use is identical. Ditto for the collection of plugins.

Database use: Database usage is identical, except that on WPMultiSite, each site has a unique ID, which takes one extra database query per page load. (Each WordPress page takes dozens to hundreds of database queries.)

WordPress uses record locking (changes tie up one record, not the entire table), and each site has its own set of database tables. MySQL has virtually identical performance whether using 30 databases or 1 database with 30 times as many tables.

Plugin use: Identical except that on WPMultiSite, mapping of somedomain.com to site ID 27, would be done using the Domain Mapping plugin. Only plugins that are Network Enabled are loaded for every site on the network.

Conclusion: Negligible difference in page load time, database use, memory use, disk use. Disk storage for MultiSite is lower, since only one copy of WordPress core files (about 70MB per installation, also negligible for most hosting accounts).

Note: WPMU is an obsolete product, discontinued with the release of WordPress 3.0. Now there is only WordPress, configured in single-site mode or multi-site mode.