Количество подключений к кэшу - это, как правило, количество DataCacheFactory экземпляров, которые у вас есть. По этой причине рекомендуется иметь как можно меньше таких экземпляров. Вы также должны быть уверены, что когда любой экземпляр Azure, который инициализировал DataCacheFactory, должен удалить экземпляр, когда он остановится, это поможет очистить соединения, которые он открыл для службы.
Однако вы сказали, что используете кеш в качестве поставщика сеансов. Это создает свой собственный DataCacheFactory для каждого экземпляра роли. Так что в основном одно соединение на роль. Сказав, что поставщик сеансов выглядит немного неаккуратно с тем, как он очищает соединения, которые он не использует, так что лучше предоставить слишком много соединений.
Другая вещь, которую вам нужно посмотреть, это ограничение "Транзакций в час" для кэша. Если для каждого запроса к странице требуется доступ к информации о сеансе, это количество запросов страницы, которые вы можете обработать за час.
Изменение размера кэша на самом деле довольно быстро, обычно это занимает минуту или около того. Но вы можете изменить только один раз каждые 24 часа. Таким образом, если вы увеличили нагрузку, вы можете увеличить кеш, но если нагрузка слишком велика для даже увеличенного кеша, вам нужно подождать 24 часа, чтобы снова его изменить. Так что, вероятно, вам лучше сделать кэш намного больше при первом изменении его размера и уменьшении на следующий день.
EDIT:
Хотя эта информация была верной на момент написания, в обновлении SDK от ноября 2011 г. (1.6) был представлен пул подключений к кешу, который включен по умолчанию, если вы не настраиваете кеш с помощью кода. Это делает менее важным иметь только один статический DataCacheFactory и означает, что если вы хотите использовать одну и ту же информацию о соединении как для данных сеанса, так и для данных приложения, все это может быть одно соединение. Больше подробностей можно найти на MSDN .