MTS performance questions

[Luus]

Hi everyone,

I'm new to this forum so please bear with me ...

We are currently working on a new application using
DHTML, VB6, MTS ans SQLServer/Oracle. The design is
partially based on MS DNA, but differs on some points.

The general architecture is as follows:

* DHTML page - creates (local) COM Application object,
which instantiates further local 'facade' components,
depending on what is needed for the current page.
* Facade Objects - local components, keep state in
disconnected ADO recordsets and communicate with
MTS business logic.
* Business Components - MTS components, stateless, call
Data Acess components to get/save data and implement
business logic.
* Data Access Components - Further MTS componentents,
stateless, performing build the actual SQL query and
connect to the DB server.

Testing this architecture revealed the following:

Peforming a typical call from the client to the remote MTS
server to get a single record (select * from Table where id
= x) takes about 150ms. About 25 ms is consumed by
creating and releasing the MTS object. Testing under local
MTS still gives 20 ms per create/destroy.

Q1: Are these typical performance figures or is our
network ill-configured?
Q2: Most examples i've seen create/destroy the MTS object
immediately after each method call. These figures
suggest that 'keeping the object alive' (at least
the local reference) is a better idea. Is this true?
Q3: Accuiring the data needed for a page could take data
from more than 10 tables in seperate recordsets. Is
marshalling the individual recordsets (either via
separate calls or through GetAll(RS1,RS2,RS3,...) the
best solution to do this? (I've tried converting data
to XML and passing As String, but this made matters
even worse ...)

Any thoughts on the subject would be more than welcome ...

Tnx for your time,

-- Luus

 

[chiph]

VB is not the ideal language for writing high-performance MTS objects. Because VB (v.6) can't do free-threading, MTS is unable to create pools of VB objects. So if you have several requests come in at the same time, they stack up waiting for the single instance of your VB object to handle them one at a time.

But it sounds like you're concerned about the initial "hit" taken when you create your MTS object. This can be helped by setting the instancing to something greater than 0 (well, 1 is your only other choice because of the threading limitation). This would cause an object to be pre-instantiated, and so your latency will be reduced.

If you're expecting super-high traffic on your system, your COM+/MTS objects ought to be written in C++, or wait a while for .NET (VB in .NET will be free-threaded). Be sure to read up on calling the Dispose method.

The practice of creating objects and destroying them as soon as possible is still valid -- don't change that.

I'm not sure about passing multiple recordsets back to your Facade layer will help or not. My first guess is yes (fewer network round-trips), but I haven't done it myself so I don't feel comfortable saying "yes".

Chip H.

 

[Nic0demus]

Hi all,

Luus, as a matter of interest, what was your reasoning for creating objects locally (facade objects) to call your business components? Was it purely to maintain state? Are you implementing object collections? I'd really like to know more.

Thanks,
Nic0demus.

 

[Luus]

Chip,

It's indeed the initial performance hit my second
question was about.

I wonder what you mean by 'setting the instancing to
greater than 0'. You mean setting instancing in VB
to global multi-use? That would be the same as keeping
the object 'alive' by explicitly instantiating it as
a private object during object_init of the facade on
the client, right?

I've done some tests with this, and using deactivation
(objCtx.Setcomplete) without explicitly releasing the
client objectreference does take away the 20ms 'penalty'.

On the subject of passing XML instead of recordsets:
some additional tests did show a significant improvement,
at least when using a custom function to build the XML
string. (First tests were done with the ADO Stream
object creating default ADO XML, which is rather verbose.)

Network traffic went down with 40%, performance increase
was even better (probably because of easier marshalling?)

This gives the additional advantage that passing more
recordsets can be done in one string variable, without
the need for extra parameters (and thus extra marshalling
overhead).

Still, redesigning the code would mean some serious rework,
so I'm still looking for improvements with the disconnected
recordset option

Cheers,

-- Luus

 

[Luus]

NicOdemus,

Reason to create local facade objects: main
reason was indeed to maintain state, as well as
the demand for client side validations of data.

Of course these could have been implemented in
script, but the facade objects keep the DHTML
code a lot cleaner.

The objects are actually a thin wrapper around
the disconnected recordset. Collections are also
implemented around a single recordset and can
locate the record referenced by the individual
objects through bookmarks.

An advantage of using a recordset to maintain the
state is also the fact that ADO keeps track of
pending changes for you.

-- Luus

 

[chiph]

Luus -

I wonder what you mean by 'setting the instancing to
greater than 0'. You mean setting instancing in VB
to global multi-use?

No, it's a property of the Component. I actually used the wrong term for it -- using Component Services (or MTS Explorer) open the properties of one of the components inside your COM+/MTS application. If it's a Server Application you'll see on the Activation tab a section for object Pooling. If you set the minimum size greater than 0, then a copy of your component is always ready for callers. Library applications have this section disabled.

Chip H.