BuddyPress.org

I may be wrong but I think there’s two separate issues here.

1. Response time is slow which results in pages taking 10 – 20 seconds to load.

Why exactly are response times slow? Which resources are bogging things down? You mention that Varnish caching doesn’t work on a membership site but what is causing your site to be slow to begin with?

2. Users don’t benefit from the Varnish acceleration if they’re logged in.

To the best of my knowledge, you can cache content for logged-in users when using Varnish. I’ve never tried to, and am no expert when it comes to using Varnish, but take a look at this article

I’m aware you don’t want to cache stuff like the activity feed but perhaps you could cache content selectively.

@sbraiden – I had similar 24 second page load times, and tried to get advice for enqueing, dergistering, and compacting the multiple and overlapping java and css all these plugins attached to buddypress are mixing in on top of the themes stuff.

Y Slow gives my BP site with basic plugins an “F” – WP professionals shrug it off – meh.

(more one all that here: http://premium.wpmudev.org/forums/topic/deregister-enque-compact-css-and-java-jquery-buddypress-load-time )

I have a sneaky suspicion however that my load times were an issue for me when logged in, and perhaps being logged in as an admin, I THINK that the (stupid) wpmudev dashboard plugin was slowing down my page load speed dramatically more than anything else. It was strange that after I complained of my long page loads, that 2 days later wpmudev had an update for their dashboard thing, and then my page load time went to like 3 seconds. – Coincidence, maybe, nothing definitive. – Everyone else said the pages loaded fine – so maybe it was just an admin thing – or maybe my ghostery blocking gravatar loads or something.

ANYHOW – in regards to hosting, I have a small buddypress site running fine on a shared server with amerinoc. I have one that is fairly busy running fine on a dedicated server at certified hosting.

I personally think that most important thing for a WP based site to perform well is blocking all the bad bots.

I have found that blocking all the naver and badu spiders (And most others) with a robots/txt file has decreased the sql over load (at peak times) on my servers by more than 80%.

I found that hosting a few wp sites on a shared server or dedicated could cause problems not just with spiders crawling pages too much too fast for indexing, but also all the attempting account creations / account brute force logins – even if they are blocked with something like sucuri or limit login attempts – every time they tried to login – they were using up server resources to load the login page, then hit the database to check credentials.

I also suggest using a pwd auth like explained here: http://support.hostgator.com/articles/specialized-help/technical/wordpress/wordpress-login-brute-force-attack

locking down the login with a double thing like that is fine for most WP installs, and a private family / friends BP site should be fine – when the bots can’t login through the first thing there is no need for wordpress to load a bunch of php / css files and pull from SQL a bunch of times just to give a bot a failed login – It becomes a problem for general open to the public buddypress comms I guess.

Now I set all my non-BP sites to use the double auth, I block all search engine bots aside from the top three selectively with robots.txt – and now just about any server can run fine with wp / bp – especially if some attention is paid to plugin overhead, wp-cacheing tools.

I have my fingers crossed the new bp-mediapress (sp? and Beta!) plugin thing will decrease the plugin overhead of rtmedia and offer a better alternative for pics and stuff.

Same random thoughts – I’m not an expert so take my 2 cents with a grain of salt or two..