STA bottleneck in COM+ 
Author Message
 STA bottleneck in COM+



Quote:
> for the code that you attached, I would say STA is not bad at all because
it
> does not create asynchronous calls or wait states (assumed that SQL server
> can handle the load).

Yes, but it looks like some small fast queries sometimes have to wait for
other heavier queries. That's also what the MSKB article suggest (and MSDN
magazine oct 2000).

Quote:
> Michael D. Long did a test once on VB vs delphi and C++ to COM+ loads. C++
> was the winner on a multiple CPU engine, then delpi and VB was the last.
> It's just that VB is not as efficient as the rest.

But does it scale as well as a thread neutral version would? I am afraid of
one STA component blocking another.

Quote:
> But... The VB code that you showed can be optimized.
> 1) do not implement object control because VB 6 components cannot be
pooled
> anyway!

My sample was a bit simplified, but we use objectcontrol for some
initialization.

Quote:
> 2) do not turn/switch on JIT (why do you need it?)

??

Quote:
> 3) switch off synchronized access to the component

??

Quote:
> 4) switch off transaction support because your code does a 'read action'
> only... put transactions in another COM dll and switch transaction support
> on there.

Transaction support is off (transactionmode = uses transaction, in other
words it will be enlisted in the callers transaction if there is any,
otherwise no transaction). Same thing here, the sample was a bit simplified
so sometimes transactions are needed, sometimes not.


Mon, 07 Jun 2004 18:23:49 GMT  
 STA bottleneck in COM+
I can answer that. While I expected to see some significant
performance improvements from changing the threading
model to TNA. The difference was minimal over the original
setting of Both.

As to the STA components blocking, with objects that
interact with a database the threading model is not the
most significant factor. If serialization results at the database
engine, then it doesn't matter if you have 10 objects in call
or 1000 - the users still can't get results.

Also, for what its worth - if you build Web apps you might
as well stick with VB. The performance differences reported
in my article do not reflect a Web environment. When the
same objects were called via ASP, Delphi performed worse
than VB, and the VC++ objects were only about 15% faster.

Michael D. Long


Quote:

> But does it scale as well as a thread neutral version would? I am afraid
of
> one STA component blocking another.



Mon, 07 Jun 2004 22:47:25 GMT  
 STA bottleneck in COM+
Hmmm - if you want to prevent the problems described in the article, then I
think it's a mistake setting the threading model
of the component to neutral - or event both?

The case the article describes is the case where an STA component blocks the
thread. The article suggests the STA component
calls a MTA component that executes the blocking call.

But if you create a neutral threaded or both-threaded component, the
component would run in the context of the client. And if
the client is a STA component, you would still have a blocking call in an
STA.

Thus , as I see it, you need to explicityly set the component's threading
model to "free" to make 100% sure that the blocking call is
performed from an MTA.

I'd like to hear any comments on this?

Regards,
Peter Str?iman


Quote:
> I would like to test the performance difference between using a VB
component
> running under COM+ and using a thread neutral (TNA) ATL component running
> under COM+ to connect to a SQL server database, execute a query and return
> the resulting recordset.

> The reason why I want to do this is explained by this KB article:
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q291837

> Does anyone have ATL sample code that do this? Preferrably a piece that
> implement IObjectControl with support for object pooling. If it use OLEDB
> instead of ADO but return a RS that can be used by ADO that would also be
> good.

> The attached file contain VB sample code that show what I want to do (but
I
> want to do it in a thread neutral ATL component and don't know enough C to
> write one). Maybe someone can help me to convert the sample file to ATL?

> Thank's in advance,
> Kristofer





Mon, 07 Jun 2004 23:25:39 GMT  
 STA bottleneck in COM+

Quote:

> But does it scale as well as a thread neutral version would? I am afraid
of
> one STA component blocking another.

I think that STA confuses many developers
IIS for instance runs as  a process right?
IIS is a well written service so it creates a thread pool. Each HTTP request
is launched in one of the Threads from the pool and after the request, the
thread is given back to the main thread.
The main thread is the only (and first) thread that manages all other
threads from the thread pool...

Well, got the idea of STA and MTA? The MTA is the main thread and the STA is
a very short living request. Your VB components are instanced in the MTA.
There's no issue of one thread blocking another within the thread pool.

Luck



Mon, 07 Jun 2004 23:43:04 GMT  
 STA bottleneck in COM+

At the Windows 2000 DNA Readiness Conference this
topic was discussed at length, though sad to say I have
forgotten the speakers name. I still have the binder with
my notes and session materials, so I can look this up.

At any rate, it was stressed that you should *not* mix
threading models among different components in an app.
If the bulk of your code is STA, ideally all of it would be.
TNA is a means to avoid most of the overhead associated
with context switching, and is the best overall compromise.

I've seen the recent comments from support personnel
and the MSKB articles that have been referenced. These
seem to contradict the presentation and post-session
discussions (following multiple sessions). No offense
intended, but I am inclined to believe the senior level
guys who presented on Microsoft's behalf rather than
the more recent material.

The article in question would lead one to believe that VB
is totally unsuited to middle-tier development, and nothing
could be further from the truth. There are certainly cases
where you could argue the point that VB is unsuitable,
and I would agree. This is not one of them.

This article does not begin to address the root cause of
scalability issues related to database interaction. It shoots
from the hip at the side of a barn - sure it hits something,
but the target was a knot-hole and half the barb is riddled
with pellets.

Michael D. Long


Quote:
> Hmmm - if you want to prevent the problems described in the article, then
I
> think it's a mistake setting the threading model
> of the component to neutral - or event both?

> The case the article describes is the case where an STA component blocks
the
> thread. The article suggests the STA component
> calls a MTA component that executes the blocking call.

> But if you create a neutral threaded or both-threaded component, the
> component would run in the context of the client. And if
> the client is a STA component, you would still have a blocking call in an
> STA.

> Thus , as I see it, you need to explicityly set the component's threading
> model to "free" to make 100% sure that the blocking call is
> performed from an MTA.

> I'd like to hear any comments on this?



Tue, 08 Jun 2004 05:45:04 GMT  
 STA bottleneck in COM+


Quote:
> I can answer that. While I expected to see some significant
> performance improvements from changing the threading
> model to TNA. The difference was minimal over the original
> setting of Both.

> As to the STA components blocking, with objects that
> interact with a database the threading model is not the
> most significant factor. If serialization results at the database
> engine, then it doesn't matter if you have 10 objects in call
> or 1000 - the users still can't get results.

Ok...

Our system has a 1500+ table database and all db queries and updates etc go
through one central component that live in a separate COM+ app. Some queries
are small one table, use pk, runs in 10ms. Others are big ones that join
many (10-15) large tables and take 10000ms etc.

The clients are VB apps running on some 600 client PCs and they throw some
80-100 requests per second at us. Our performance stats show some "funny"
figures that are especially visible for small/quick queries. A query that
average at 40ms sometimes have spikes where it takes 5000ms to run it. In
some cases it can be explained by serialization in the db, in other cases it
can't.

That's why I'm gripping after the STA hay in the needlestack... :)

I'm hoping that either rewriting the database access component as TNA or
decentralizing it will remove those "slow spikes".

The reason for having a central database access component is to have one db
connection pool instead of 30.



Tue, 08 Jun 2004 12:33:24 GMT  
 STA bottleneck in COM+
I think you are confusing issues.

The MTA is short for Multi Thread Appartment. I think you are confusing it
with the MAIN STA - which is the first Single Threaded Apartment created in
a process.

Components without a threading model specified runs in the MAIN STA.
Components with the apartment threading model can exist in any STA.
Components with the free threading model exists in the MTA. Components with
threading model both or neutral can exist wither in the MTA or any STA.

Visual Basic components always exists in an STA.

The issue with IIS is that it creates a series of STA appartments to handle
client request. But multiple request from the same client will always be
handled by the same STA unless you specifically disable session state (which
can be done per application or per ASP page).
Thus if you have a frameset of ASP pages, they will not load simultaneously,
because the execution of one ASP page is blocking the execution of another
for the same user.

Regards,
Peter Str?iman



Quote:

> > But does it scale as well as a thread neutral version would? I am afraid
> of
> > one STA component blocking another.

> I think that STA confuses many developers
> IIS for instance runs as  a process right?
> IIS is a well written service so it creates a thread pool. Each HTTP
request
> is launched in one of the Threads from the pool and after the request, the
> thread is given back to the main thread.
> The main thread is the only (and first) thread that manages all other
> threads from the thread pool...

> Well, got the idea of STA and MTA? The MTA is the main thread and the STA
is
> a very short living request. Your VB components are instanced in the MTA.
> There's no issue of one thread blocking another within the thread pool.

> Luck



Tue, 08 Jun 2004 18:11:31 GMT  
 STA bottleneck in COM+

Quote:
> I think you are confusing issues.

> The MTA is short for Multi Thread Appartment. I think you are confusing it
> because the execution of one ASP page is blocking the execution of another
> for the same user.

Thanks for the clarification but if 3 pages run in a frameset it is possible
to have 3 threads (apartments) but the Session object synchronizes execution
because just one session at a time can be updated, right?

Quote:
> Regards,
> Peter Str?iman



> > > But does it scale as well as a thread neutral version would? I am
afraid
> > of
> > > one STA component blocking another.



Wed, 09 Jun 2004 02:21:41 GMT  
 STA bottleneck in COM+
Quote:
> The reason for having a central database access component is to have one
db
> connection pool instead of 30.

That's it... You cannot have 'one' central db connection. If you do, ADO
will block access or the thread that 'hosts' the connection will block
access when another request tries to use the connection object at the same
time.
Why not just simply profit resource pooling (not connection pooling what
ODBC does)? Resource pooling was made to make your server scalable and use
resources when needed (JIT).

--- even if you would be able to have the single connection object to run
multithreaded or TNA, it still would block, not because of your threading
but because of the fact that SQL server simply does not allow to select
statements for instance to be run on the same thread.
What you are trying to accomplish looks like asking the harddisk to write
with 2 heads on the same sector.

--
Egbert Nierop

Session management for webfarms:
http://www.nieropwebconsult.nl/asp_session_manager.htm




Thu, 10 Jun 2004 03:20:03 GMT  
 STA bottleneck in COM+
component != object :-)

--

Enterprise Development: http://www.dev-purgatory.org/



Quote:
> > The reason for having a central database access component is to have one
> db
> > connection pool instead of 30.

> That's it... You cannot have 'one' central db connection. If you do, ADO
> will block access or the thread that 'hosts' the connection will block
> access when another request tries to use the connection object at the same
> time.
> Why not just simply profit resource pooling (not connection pooling what
> ODBC does)? Resource pooling was made to make your server scalable and use
> resources when needed (JIT).

> --- even if you would be able to have the single connection object to run
> multithreaded or TNA, it still would block, not because of your threading
> but because of the fact that SQL server simply does not allow to select
> statements for instance to be run on the same thread.
> What you are trying to accomplish looks like asking the harddisk to write
> with 2 heads on the same sector.

> --
> Egbert Nierop

> Session management for webfarms:
> http://www.nieropwebconsult.nl/asp_session_manager.htm







Thu, 10 Jun 2004 06:18:07 GMT  
 STA bottleneck in COM+
ok ignore my previous post...

--
Egbert Nierop



Thu, 10 Jun 2004 07:04:10 GMT  
 STA bottleneck in COM+
There are some additional factores that you should take into
consideration - a connection cannot be reused if its credentials
are not identical, and this includes the transaction identifier. A
connection enlisted in a distributed transaction cannot be handed
out to any other object not participating in the same global
transaction (having the same GUID). This can result in having
multiple pools when you think you only have one (if you use an
ODBC driver you can actually monitor the number of pools).

Also, your usage scenario touches on one of the weaknesses
of the connection pooling algorithm. I have observed the exact
same characteristics and fully understand the issue. I've explained
the behavior to CPR guys in Microsoft Support, and provided
repro cases (which I am certain only Oracle actually ran, since
they made optimizations in their client based on the results) that
demonstrated the issue, but the problem persists.

Basically, the connection pooling algorithm is *very* simplistic.
It doesn't do time phased averaging on demand, nor does it
allow for explicit allocation by an administrator when periods
of high demand can be forecast. The problem is that at random
timing intervals there will be a need to open between 1-n *new*
connections to satisfy demand. In your specific scenario this
can be up to 100, though typically about 30% of the maximum
will remain active in the connection pool - because this is the
number that can satisfy 100 clients *most of the time*. If you
have to open 70 connections concurrently, you are going to
see high latency since this is one of the most expensive operations
you can perform against the DBMS (particularly with Oracle,
where I have observed that concurrent calls by 100 clients can
result in > 60 second latency - and cause some permanently
dead connections that Microsoft *never* releases).

I don't believe you have a threading problem, but rather you
are a victim of an algorithm designed by Johnny Newbie. It
is a cheap hack and looks better on paper than it will ever
perform in the real world.

FWIW, I disclosed to Microsoft Support a design for a greatly
improved connection pooling algorithm that allowed the pool to
dynamically adapt based on usage patterns over time, or for explicit
administrative control. They weren't that interested, since their very
simplistic one works for the majority of their customer base - those
who talk more about scalable systems than actually implement them.

Since I am now in an environment where I am not impacted, and
a solution would not help an active client, my inclination to work
with Microsoft in arriving at a better solution to the problem is
basically non-existent. I had considered building a commercial
version of components that could be pooled and would perform
well under peak loads, but rapidly came to the conclusion that
the market for such a product wasn't worth my time (unless I
sold it for several thousand per server or CPU, which I didn't
think would be readily accepted).

I would open a support case with Microsoft and put together
a repro that demonstrates the problem. Make sure to keep it
as simple as possible, or they definitely will not run it (and they
are likely not to run it anyway since this is a complex problem
that Microsoft has little incentive to fix). If you want it fixed
then be prepared to put in several man-months of effort on
your part.

Michael D. Long


Quote:


> > I can answer that. While I expected to see some significant
> > performance improvements from changing the threading
> > model to TNA. The difference was minimal over the original
> > setting of Both.

> > As to the STA components blocking, with objects that
> > interact with a database the threading model is not the
> > most significant factor. If serialization results at the database
> > engine, then it doesn't matter if you have 10 objects in call
> > or 1000 - the users still can't get results.

> Ok...

> Our system has a 1500+ table database and all db queries and updates etc
go
> through one central component that live in a separate COM+ app. Some
queries
> are small one table, use pk, runs in 10ms. Others are big ones that join
> many (10-15) large tables and take 10000ms etc.

> The clients are VB apps running on some 600 client PCs and they throw some
> 80-100 requests per second at us. Our performance stats show some "funny"
> figures that are especially visible for small/quick queries. A query that
> average at 40ms sometimes have spikes where it takes 5000ms to run it. In
> some cases it can be explained by serialization in the db, in other cases
it
> can't.

> That's why I'm gripping after the STA hay in the needlestack... :)

> I'm hoping that either rewriting the database access component as TNA or
> decentralizing it will remove those "slow spikes".

> The reason for having a central database access component is to have one
db
> connection pool instead of 30.



Mon, 14 Jun 2004 23:32:45 GMT  
 STA bottleneck in COM+



Quote:

> Since I am now in an environment where I am not impacted, and
> a solution would not help an active client, my inclination to work
> with Microsoft in arriving at a better solution to the problem is
> basically non-existent. I had considered building a commercial
> version of components that could be pooled and would perform
> well under peak loads, but rapidly came to the conclusion that
> the market for such a product wasn't worth my time (unless I
> sold it for several thousand per server or CPU, which I didn't
> think would be readily accepted).

hm, could u plz xplain the algorithm use by MS?
and: if it is so bad (as i think too) i think there is a market for a better
commercial product.. even an xpensive one!

--

Enterprise Development: http://www.dev-purgatory.org/



Tue, 15 Jun 2004 05:43:06 GMT  
 STA bottleneck in COM+


Quote:
> There are some additional factores that you should take into
> consideration - a connection cannot be reused if its credentials
> are not identical, and this includes the transaction identifier. A
> connection enlisted in a distributed transaction cannot be handed
> out to any other object not participating in the same global
> transaction (having the same GUID). This can result in having
> multiple pools when you think you only have one (if you use an
> ODBC driver you can actually monitor the number of pools).

But it can be reused when the transaction has been committed or rolled back,
can't it?

Quote:
> Basically, the connection pooling algorithm is *very* simplistic.
> It doesn't do time phased averaging on demand, nor does it
> allow for explicit allocation by an administrator when periods
> of high demand can be forecast. The problem is that at random
> timing intervals there will be a need to open between 1-n *new*
> connections to satisfy demand. In your specific scenario this
> can be up to 100, though typically about 30% of the maximum
> will remain active in the connection pool - because this is the
> number that can satisfy 100 clients *most of the time*. If you
> have to open 70 connections concurrently, you are going to
> see high latency since this is one of the most expensive operations
> you can perform against the DBMS (particularly with Oracle,
> where I have observed that concurrent calls by 100 clients can
> result in > 60 second latency - and cause some permanently
> dead connections that Microsoft *never* releases).

That's interesting. I'll keep an eye out for the dead connections.

Quote:
> I don't believe you have a threading problem, but rather you
> are a victim of an algorithm designed by Johnny Newbie. It
> is a cheap hack and looks better on paper than it will ever
> perform in the real world.

But the difference in execution time differs so much (sometimes 100x) -
could that really be accounted for by creating new connections?

Quote:
> FWIW, I disclosed to Microsoft Support a design for a greatly
> improved connection pooling algorithm that allowed the pool to
> dynamically adapt based on usage patterns over time, or for explicit
> administrative control. They weren't that interested, since their very
> simplistic one works for the majority of their customer base - those
> who talk more about scalable systems than actually implement them.

I think MS support are afraid of "disturbing" the programmers if they don't
understand the problem/scenario themselves, so many suggestions from
customers never get past them.

In a non-related problem, I tried about a year ago to explain to a MSFT
support technician that the world have more than four time zones, but he
just wouldn't listen... :)

Anyway, thank's for your input. It is much appreciated!

Kristofer



Tue, 15 Jun 2004 11:46:03 GMT  
 STA bottleneck in COM+
Micheal,

Talk to Gert E.R.Draper for this... He surely will listen as he is
interested in scalability.

--
Egbert Nierop



Wed, 16 Jun 2004 00:11:29 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. STA bottleneck in COM+

2. Using messagebox to display synchronisation in STA COM component

3. Outgoing COM calls in STA Worker Thread

4. Callback Handling mechanisms in STA client when fired from MTA atl com server

5. MTA COM with STA data member

6. Can a STA COM server used in multithread?

7. Inter-STA apartment COM call not working correctly

8. Execution time bottleneck: How

9. Execution time bottleneck: How to speed up execution?

10. CDao Performance bottlenecks

11. WaitHandle.WaitAll and STA?

12. WaitHandle.WaitAll and STA?

 

 
Powered by phpBB® Forum Software