MTS : Capacity Planning

[Guest_imported]

Current setup:
We have 4 objects (DLLs) in a single MTS package that are being called by our VB application in a 3-tier environment.

Question:
What is the maximum no. of concurrent users that MTS can handle?

Server configuration:
CPU : Pentium III 550MHz x 2
Memory : 1GB
Disk : 4 x 18GB

Appreciate any advise. Thank you.

 

[dannyh]

It is not quite as simple as that (things never are with MTS). There is not a limit on how many users you can have connected to MTS, but after a point you will notice that performance will start to degrade.

The point where performance drops off is also not a set point, but depends on what your objects are doing, and how many will be instantiated at once. For example if you have an object that handles a complex task it may use more resource than an object that just performs a simple task. The ammount of processor usage and memory usage that your objects use up, along with how intensively they are used is what will determine how many users you can have before performance starts to degrade.

Unfortunately the best method is trial and error !

Hope this helps (but probobally not quite the hoped for answer),

Dan.

 

[vishnuprasad]

MTS will dynamically allocate 100 threads/processor(or process) so it basically is a question of what is the hardware configuration.

In u'r case it will allocate a max of 200 threads(at peak load) to various activities created.Once it goes beyond this level it will go for co-operative thread switching.

But just b'cas u'r system is powerful the performance is not correspondingly high since u will have to code as per MTS coding specs and practices.

Hope this was OK.

 

[chiph]

I'm assuming that your components are compiled with VB6, and not VB.NET or VC++. In which case you aren't going to get the performance you might expect.

VB6 does what's known as apartment-model threading. Unfortunately, apartment-threaded components in COM+ and MTS get degraded to single-threaded behavior. This is because MTS can't be sure of the isolation between instances of apartment-threaded objects. As a result callers to your objects have to wait in line to use them.

To get the most out of MTS and COM+ your components need to be free-threaded, which at the present requires you to write them in the beta .NET or in C++. Once you have free-threaded components you can tell MTS/COM+ to create a pool of them, with 5, 10, 20, or more instances waiting for callers, and your performance then becomes limited by your hardware and database lock contention.

Chip H.