The best way to determine whether you have an adequate size for the client side cache is to observe the "Client Cache Read Hits" SOSS performance counter under the “ScaleOut StateServer Service” category in perfmon. It shows a number of read hits in the client cache during the sampling interval.
By increasing the size of your client side cache you want to see the upward trend for the "Client Cache Read Hits" parameters until it stops growing for a given load test. If you reach this point it means that the resulting cache’s size is enough to store all of the requested objects in an application’s memory. It would be better to disable the web gardening feature while you are running these discovery tests. When web gardening is enabled, each IIS worker process has its own copy of a client side cache.
If the size of the client cache is larger than it’s needed, SOSS will be using its memory on an as-needed basis, it does not preallocate the entire memory block upfront. If that size is not enough to keep all requested objects, the LRU mechanism will start removing the Least Recently Used objects from a cache, allowing the most recently used ones to be stored there. By the way, you can control the size of the client cache programmatically in each individual instance of your app using the static DataAccessor.MaxCacheKB property. If you reduce this value then the effect will be immediate: the cache will be trimmed to that estimated size right away.
