Performance Value of Object Pooling with MTS

   

If you ask for an object to be created through COM, the server has to create a process space and instantiate the object. This requires large amounts of memory on the server and it adds a thread to the allocated resources. The process thread not only consumes memory by itself but also has to be checked and scheduled by the operating system, requiring additional administrative overhead. Left unchecked, this direct instantiation of objects can consume a server computer's resources.

Wouldn't it be nice if you could create a pool of objects and then efficiently reuse them over and over again? That's what Microsoft Transaction Server (MTS) does. Basically, it creates the needed objects and then recycles them fast — much faster than the time required for instantiation.

MTS provides a run-time infrastructure that:

The easiest way to think about this is that MTS provides object pooling. The object might be a business service, a database connection, or some other application service. Object pooling is an important design concept required for high-performance applications.

Don't confuse fast object recycling with queuing. Although MTS effectively pools object instances and recycles them quickly, that isn't the same thing as queuing. As a general rule, your application design should use both queuing with MSMQ and object pooling with MTS. The combination of queuing with pooling assures maximum throughput during peak computer workloads and prevents overloading the server with too many objects.

For More Information   For more information on using Microsoft Transaction Server, search online for "Getting Started with Microsoft Transaction Server" in MSDN Library Visual Studio 6.0. For more information on using Microsoft Message Queue Server, see Performance Value of Service Queuing with MSMQ in this chapter.