BuddyPress hosting where everyone sees a different page.
A social site has no shared front page. Every member's feed is assembled for them, which means the busiest pages on the site are the ones a cache can never help with.
Nothing here is the same twice.
A social network's defining property, from a hosting point of view, is that no two visitors get the same page.
Feeds built per member, every time
An activity stream is filtered by who somebody follows, which group they are in and what they have muted. There is no version of that page to cache, so it has to be generated quickly instead.
One post, hundreds of notifications
A message in a busy group fans out to every member of it. That write amplification is the load nobody predicts, and capacity is allocated for it rather than for the single post that triggered it.
Activity tables that keep up
The activity table is the busiest in the install - written on every action and read on every page. It is indexed for the queries a stream actually makes rather than left to grow unattended.
Member uploads handled on arrival
Avatars, cover images and attachments arrive from hundreds of people at whatever size their phone produced. They are processed on upload rather than on display.
Recover a moderation mistake
Removing a member or a group cascades through activity, notifications and connections. Daily backups make that reversible.
Load that comes from members, not visitors.
Traffic graphs on a social site mislead. A hundred logged-in members generate far more work than a thousand anonymous readers, because none of it can be served twice.
- Feeds generated fast rather than cached
- Notification fan-out sized for busy groups
- Activity queries indexed for stream filters
- Member uploads processed on write
Every page load is original work.
Nothing here comes from a cache, so the only number that matters is how fast the site can build a personalised stream from scratch.
What we change for BuddyPress
Page caching is close to useless on a social site, so the entire budget moves to generating pages quickly and absorbing write amplification.
| Setting | What we do | Why |
|---|---|---|
| Page cache | Effectively bypassed throughout the member area | Every stream is filtered per member, so there is no shared version of the page for a cache to hold. |
| Activity table indexing | Indexed on member, group, type and date | Stream queries filter on exactly that combination, and the table is the most written and most read in the install. |
| Notification fan-out | Capacity allocated for the amplified write | One post to a large group becomes hundreds of notification rows, so the cost of an action is far higher than the action suggests. |
| Member uploads | Avatars and attachments processed on write | Uploads arrive from hundreds of people at whatever size their device produced, and resizing at display time makes every viewer pay. |
| Object cache | On by default | Member, group and connection lookups repeat many times within a single stream render. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Can any of a BuddyPress site be cached?
Why does one post to a big group slow everything down?
How many members can it support?
Does this apply to PeepSo and other community plugins?
Give the community a site that keeps up.
Move the network across. Migration is free, members and activity included.