Any given object type will have a collection of running instances in one or more pools. Each object type will need to provide information for a pool manager to create and manage the right number of objects. Table 2-1 lists some properties you can use to set up a pool manager.
Table 2-1
Things a Pool Manager Might Like to Know
| Characteristic | Notes |
| Threshold Minimum | The minimum number of objects of that type the pool manager must maintain. |
| Threshold Maximum | The maximum number of objects of that type the pool manager can start and have running at a given time whether free or servicing a request. This property can be set or derived from other properties, such as the capability of the server machine. |
| Frequency | The frequency of requests per minute expected for the server. This can be derived by logging requests over a period of time and creating and monitoring an average. |
| Potential Number of Clients | The maximum number of concurrent running client applications (although this might equate to users) that could potentially use this object type. If two different kinds of client application were in use, we could decide that client type A could have up to three instances of itself running on the same machine at any given time and would be available on 50 machines; client type B could have only one instance running at a time on any machine and would be installed on 70 machines. In this case, the potential number of clients is 3*50 (for client A) + 1*70 (for client B) = 220. |
| Average Duration of Server Task | The average length of time a server task is expected to run, based on the number of tasks that ran during a period and how long each ran from start to finish. This can be set or derived. For additional information, see the comments on mixed-duration tasks inVisual Basic 5 Books Online. |
| Logging Enabled | Enables/disables logging of statistics for the object type to derive some of the values above. |
| Garbage Collection | Enables/disables garbage checking for that object type or object instance. (See the �Garbage collection: Take out the trash� section on page 67.) You can extend this to have different methods of garbage collection if you want to be really flashy. |
Bean counting for developers The Threshold Maximum number can be derived by using the Frequency of client requests, the Potential Number Of Clients, and the Average Duration Of Server Task to derive a linear allocation plan:
| Characteristic | Values |
| Frequency of requests per client | 5 requests per minute |
| Potential number of clients | 100 |
| Average duration of server task | 3 seconds |
At this point, you might want to put in a reality factor�an admission that not all your clients will be needing objects all the time. This step involves some risk, however, since if you wanted to truly scale to the maximum number of clients, you would be relying on probability to bail you out of any peaks. Although you can be aware of the maximum number you might ever need, you still have to consider this figure in the context of all server objects that might be running on your object server machine. After adding in the overhead of any other processes running there and comparing this figure to the capability of the machine, you�ll have a fairly good idea of whether the memory will be adequate. Consider this scenario:
Perhaps in this case 256 MB of RAM looks viable on your machine. Nevertheless, you�d probably go for a more dynamic strategy of precreating perhaps 50 of the 150 object instances you could need as your pool and monitoring usage to see if they are being used. You would create more of a type (up to the maximum of that type you are currently allowing) only when you are approaching your threshold minimum of free objects, in effect stocking up for expected demand.