In repsonse to Berin Loritsch: Fast startup is primarily a benefit for developers and less of an issue in production environments. Production configs need scalability and stability, and will typically use all the services they ultimately need from the outset.
I think a reasonable balance between the two is to aggressively load just what is needed for any deployment at deployment time. This handles the development case, where only the necessary services get loaded on startup, and the service mix stays constant as applications are redeployed by the developer. It also handles the production case, in that all services needed are loaded together giving a deterministic failure point, but only the ones needed by the apps are actually loaded conserving system resources. The loading pricipals you described would work well, its just that "first-use" becomes deployment time rather than run time. The caveat I would throw in is that if the system is online, I like have the option of either dedicating one thread to loading a new application (leaving the other threads to service requests) or of dedicating all threads to redeploying an existing application (to reduce outage time). -- Jeremy
