What methodologies should be applied in determining correct actor size for an azure service fabric stateful actor system?
Taken to the extremes I could have theoretically have exactly 1 actor that has all the state or the converse use an actor to store exactly 1 string. Obviously both of these are wrong.
For a single actor, if measuring the serialized size of the data what amounts of kilobytes would be considered small and how many megabytes would be considered large? For example, is 10KB small and 10MB large?
Building from the above answer, assuming an actor network compromised of "small" actors. What constitutes a small network vs a large network? For example again, is 1 million small and 1 billion large?
I'd strongly prefer some kind of citation applied to these measurements. However I have not been able to source anything specific from the Azure docs. Should no specific information be published yet, I would accept sources that deal with different actor network implementations than specifically the ASF.
In general, the raw size of the actor's state is less interesting than its scope and patterns of access. If you're using your actor as a "manager" of a large amount of state that other components need to access various pieces of, you are very likely to get tripped up by the single-threaded nature of the actor model as multiple callers attempt to make requests in parallel. On the other hand, if you have a naturally encapsulated actor that needs to harness a large amount of state to perform its tasks, it can be beneficial to have all of that state stored locally, rather than making a set of network requests.
If you're looking for a very coarse rule of thumb, I would expect most actor state to be measured in kilobytes. If you're crossing the megabyte threshold, it's worth re-examining your design and making sure your actors aren't playing the manager or mini-database role, which would be much better served with a reliable service/reliable dictionary.