Pretty much everyone knows the best way to ensure site performance is caching data when ever possible. Normally this is pretty much a no-brainer but if your dealing with a Multitenant site you need to make sure you always use a per site unique key for most data.

This gets even more problematic if you support third party developers/modules as they have to follow the same rules as well.

Head problems off at the pass by using the Solar_Cache prefix config. This bit of code would be placed as soon you "identify" the site in question and get some sort of unique id for that site.

// If you can figure out the $per_site_unique_id in the config
$config['Solar']['registry_set']['cache'] = array(
  'Solar_Cache',
  array(
    'prefix' => $per_site_unique_id,
  )
};

// Otherwise you can do this as soon as possible
$cache = Solar::factory('Solar_Cache', array('prefix' => $per_site_unique_id));
Solar_Registry::set('cache', $cache);

Now anytime someone pulls and uses the "cache" object you can be sure its safe to use.

Some Solar models have built in caching but you have to enable those caches by hand, for example Models.

// Again, if you can do it within the config
$config['Solar_Sql_Model']['cache'] = 'cache';
$config['App_Model_Members']['auto_create'] = true;

// Otherwise
$cache = array(
  'prefix' => $per_site_unique_id,
  'adapter' => 'Solar_Cache_Adapter_File',
);
// Set your caching adapter for all models
Solar_Config::set('Solar_Sql_Model', 'cache', $cache);
// Turn on caching for specific models
Solar_Config::set('App_Model_Members', 'auto_cache', TRUE);

Now the model caching will respect site tenancy.

The great thing about Solars model caching, its self maintaining.. As long as you only access the DB through Solar it handles clearing and updating the cache as values in the DB change.

The "auto_cache" bit can be put in the model itself using standard Solar config format but I prefer to have this in the main Solar.config.php or index.php so I can enable/disable caching as needed.