BuddyPress.org

What do you consider ‘really large’ ?

It is scalable.
A lot depends on your ability as a sysadmin.

If you have over 100,000 users you’ll need a very good server setup. Lots of RAM and ideally an SSD as BuddyPress writes to the server a lot. You can’t just cache BP pages for logged in users as they will see old content, so you need to be able to handle a lot of database queries all at once. Also set up a CDN and put all assets (images, CSS, JS, etc) there to reduce the load on your server. And minify them all too.

I suspect you’ll need to set up some custom caching for certain parts of the site so they don’t bog down, particularly search. If you do a search of 100,000+ users, especially a search with multiple terms, it will take a while to run through all of those database entries. You can set up a cached index of all search results and just update it at intervals with a cron job, and then your search results will be much faster. Same with group search if necessary. This would have to be custom. What I’m describing is exactly how we set up search here: http://easyoutsource.com/workers. It will search through over 25,000 users with multiple parameters pretty fast. Prior to caching search results it was almost too slow to use.

Sorry I didn’t explain this as well as I could have. You shouldn’t need a lot of servers, just one very good server. So if you’re using cheap shared hosting at $5-10/mo, that’s not going to cut it once your site scales up large. In that scenario you’re sharing bandwidth and resources with many other sites, and the server itself (which is just a computer really) is likely not all that fast if you’re not paying much. You can rent your own server, or a virtual private server, and it can have very high specs all dedicated to your site. Like 24 cores, 2-4gb RAM, etc. That will be fast. You can get that for $50-$100/mo depending on what you choose/need. And you can always migrate a site from one server setup to another. A developer experienced in moving sites can usually do this within a day.

A HUGE site does need multiple servers. Facebook for example probably has thousands of servers all around the world. But keep in mind how much raw data they must serve. A BP site at 100,000 users can probably be delivered from one database, from one server. The guiding strategy is to take as much load off of that server as possible, and then make sure the server is good enough to handle what is left without crashing or stalling with not enough RAM. “caching” at the server level is a method to take load off of the server. Using a CDN takes load off of the server. etc.

I’m sure speed is an issue that the BP team thinks a lot about, but it’s a hard one to tackle as people are all customizing everything and it’s not really best practice to include caching within plugins. Although best practice isn’t everything, because in reality a solid caching system for BP would solve a lot of speed issues. It would need to cache individual components and break them live with AJAX, or something like that – not my expertise. I can imagine this interfering with many custom setups and plugins however, so like I said, probably not a simple fix.

1GB RAM is a minimum, 2GB RAM is ideal. As you scale up you may need more. On a good server setup you can actually see live (via SSH) how much of your RAM is being used up and how much is free. If you’re bottlenecking, you can contact the hosting company to add more RAM or bump you up to the next server. That is not the same as migrating to a new host… if it’s within the same company they should handle it for you seamlessly in the background.

Another option is to use Amazon (AWS) instead of a private server and it just scales up automatically as needed – they mostly charge by data rather than by server. They will be more expensive for most sites and will be slightly harder to set up, but they are also incredibly scalable.

A CDN isn’t really a “cache” in the way you imagine W3 working. It’s only caching resources (stylesheets, images, javascript files, etc) but not caching “content”. Your resources usually don’t go stale because they are not updated often. And if you do it properly, the cache can be broken any time you update a resource (by adding a version number to the enqueue in your theme). The version number gets appended to the URL of the resource, so if it changes the CDN thinks it’s a different file and immediately serves up a new file.

Content does go stale. By content I mean the data that is outputting for everyone to see right on the website. Like a profile, activity page, member directory, etc. This is the stuff that plugins like W3 are primarily used to cache (among other things as well).

You can integrate a CDN very easily using WP Super Cache. You can just turn off the content caching stuff and use it only for pushing your resources into a CDN. It’s a set it and forget it kind of setup for the most part.

If you happen to be in the Miami area on May 9, I’ll be speaking about scaling BuddyPress at the BuddyCamp (1st day of WordCamp Miami). http://2014.miami.wordcamp.org/
Should be a fun event.

Happy to help.

WordCamps are fun. I went to my first one in Chicago and met a lot of great people and learned quite a bit. I recommend going if one ever comes up near where you live.

For capacity, start another thread. You can @ mention me if you want. Btw I’m not a forum moderator so I’m not really an authority haha. But best to always start a new thread for a new topic.