Optimizing cache for Open Atrium

For now just pointing to this issue: Optimizing cache for Open Atrium, ongoing discussion about the subject. Excerpt from that thread:

mpotter

Caching is a very complex subject. People reading this thread should not see it as a "cure all" solution. Multiple cache layers can be very tricky to configure and can be very site specific.

Typically when I build Enterprise-level sites the most important caching layer I use is Memcache (or Redis, your choice, but I typically use Memcache). Some sort of memory cache like this is *critical* for ANY Drupal site where you have lots of logged-in users (e.g. Open Atrium).

Second caching layer is Varnish for anonymous users. I prefer Varnish over stuff like Boost.

Definitely disable any "PoormansCron" task in the Drupal cron system and also disable DBLog. Those are standard procedures for any Drupal prod site.

Open Atrium isn't any different from any other production-level Drupal 7 site. So there are a lot of resources available on the net for improving performance. With just the above items I mentioned we have a production site with 16,000 spaces, hundreds of users, with page load times around 2 seconds for both logged-in and anonymous users.

Obviously there are related topics on tuning your MySQL database, etc.

I rarely get deep into content-level caching, such as Views or Panels caching. That kind of caching can easily cause more trouble than it's worth if you are not careful with it. And those should definitely only be done once you have the basics listed above.

Be careful with *any* module that you add that isn't already part of Open Atrium. Those additional modules can cause obscure problems, and potentially expose content to the wrong users if they cache in the wrong way.

If you *do* end up with performance issues, it's very important to use proper debugging and profiling tools such as xhprof to determine the exact cause of the performance issue. We spend a lot of time with our clients on this and have learned that without REAL DATA about exactly what is causing the performance issue you can easily waste a lot of time and resources on the wrong problem. Just throwing more caching layers at the site is not usually the solution.

Real data can be obtained from tests, e.g. using jmeter, or it's Cloud implementation Blazemeter. For Open Atrium one of the problems you face are the authenticated private pages in Spaces. The Blazemeter module will allow you to test using virtual authenticated users, but I found it doesn't work with Open Atrium (probably because OA's uses OG for access control). Create a 'test' Public Space for testing purposes and adjust your testing scenario.