Huge magazine site. Multi DB ?

Hi guys !

I need an advice.

I am about to create a buddypress magazine site and transfert thousands of posts from joomla, and create a magazine style portal under buddypress.

There wont be much sub site (less than 10) but there will be about 15.000 up to 35.000 registered users.

Do that type of config require a multi DB ?

Thanks for clarification.

  • Tom Eagles

    Hi there @Aphrodite

    I personally would think about it seriously also how busy do you expect the site to be based on the original ones traffic. The volume of accounts isn't that high but depending on the amount of traffic you might get from them you could definitely benefit from it.

    As @Gabe pointed out it would do any harm and would allow for future scaling. One of the best server config guys i know here is @aecnu (from our team) could probably give you a more definitive answer as to when he would consider it necessary and he is our server guru also my host so I know 100% he knows what he's on about.



  • aecnu

    Greetings Aphrodite,

    Gabe and Tom are spot on that it will help because the posts are divided up between several sites so instituting a 16 Multi DB is definitely a great idea since it will break those posts into smaller chunks relative to allocating them to each different site with a different database.

    I have used Hyper DB in the past though I admit that was over a year ago and it did not operate in the sense of breaking the main database into several smaller ones that Multi DB does.

    The key to Multi DB is that because it indeed breaks the WordPress MultiSite installation database sub sites into several parts, it therefore makes searching and retrieving data from smaller databases much faster versus one large database.

    So for example if there are 16000 posts, and for the sake of example they are divided evenly, then the retrieval is searching though 1000 posts at a time versus 16000 posts at a time with a standard installation.

    This is irrelevant to the amount of users since the users are all part of the main network in any event.

    Cheers, Joe

  • aecnu

    Greetings Aphrodite,

    Personally and professionally I do not believe in any of those gimmicks preferring the brawn of power over what I consider BS for the most part.

    But the actual needs of these gimmicks are also dependent on your host/hosting platform and their configuration.

    For a quick example, Blue Host throttles bandwidth, so I definitely see where compression and CDN's would help with dealing with their hosting bringing the graphics from elsewhere which bypasses their throttle and compression of course makes things smaller giving the appearance of speed and in reality there is more speed because less bandwidth is indeed required in this case.

    But as the many of found out even many form here on WPMU DEV, when the servers are configured correctly, these gimmicks (excluding compression) including caching are not necessary to have screaming fast sites.

    Compression is a whole different ball game and incorporates the end users computer into the equation of site delivery and adding the end users computer into the power of the network instead of draining the power form the network.

    But careful server configuration is necessary and most hosting companies configure for maximum profits instead of maximum performance as we do.

    35,000 posts not a problem though Database optimization will be a big bonus, or it should not be a problem if the host is configured properly.

    Cheers, Joe

  • Tom Eagles


    That's what i love about @aecnu 's responses no BS just tells it as it is. I recently had a very intense attack on my dedicated server (hosted by joe) and it stayed up, nothing beats a well optimised server and whilst other sites may have fallen down i sent a message to joe and within minutes je was on the case and had made even more adjustments and there was zero impact.



Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.