ExamGuru IT/.Net Guru : COM object performance on ASPFriends.com 'aspngescalate' list

.NETGURU

COM object performance

Messages

Related Types

This message was discovered on ASPFriends.com 'aspngescalate' list.

Johnson, Peter

(I first asked this 7 hours ago on [aspngmigrate], resent w/ "NOT ANSWERED
BEFORE" 5 hours ago, and received one response, which is detailed at the end
of this message.)

I have a reporting DLL written in Visual Basic (STA threading) that uses
Data Dynamics' ActiveReports component. Here's how I'm using it in my
ASP.NET app, from lowest layer to highest:

ActiveReports DLL
My VB COM DLL that instantiates ActiveReports
.NET wrapper around the COM object made using tlbimp
Another .NET component that sets needed properties on the .NET wrapper
ASP.NET codebehind that instantiates the .NET component
ASP.NET page (.aspx) that inherits from the codebehind

In the .aspx, I have aspcompat="true" set since it's using an STA object.
Yet, I still see strange performance. Sometimes it takes 2-3 seconds.
Sometimes it takes 30. Sometimes it takes 60. And one time, I think it may
have locked up the ASP.NET worker process (though I'm not sure the app is to
blame on that).

Sounds like threading issues from what I've read in the docs. Any
suggestions? Anything to check? What's going wrong?

As I said, I've received one response to my message. He thought my VB COM
object was single-threaded, which it is not--it's apartment-threaded (STA).
One thing he suggested is running the COM object outside of the IIS process.
I don't have much experience with COM+, but I know that would be outside of
the IIS process. Is this a good idea? And if it would solve my problem, why?

Thanks,
Peter

----------------------------------------------------------------------------

This e-mail and any attachments may be confidential or legally privileged.
If you received this message in error or are not the intended recipient, you
should destroy the e-mail message and any attachments or copies, and you are
prohibited from retaining, distributing, disclosing or using any information
contained herein. Please inform us of the erroneous delivery by return
e-mail.

Thank you for your cooperation.

----------------------------------------------------------------------------

Reply to this message...

Peter Brunone

Peter,

One thing I can think of is that you should be sure to declare
Single-Threaded Apartment (STA) objects in a sub rather than the global,
"constructor" area. Of course you're probably already doing this, so...
Is the component doing a lot of talking back and forth to the DB and/or
other objects? Chatty COM assemblies are a problem now as well as then. I
seem to remember that using a lot of string properties will be expensive for
COM interop as well. Also -- probably a silly question -- is your .NET
wrapper early-bound? The use of tblimp may make this a no-brainer, but I've
never done it before, so take it or leave it :)

Just my fuzzy, muttering $0.02...

Peter B

|-----Original Message-----
|From: Johnson, Peter [mailto:Click here to reveal e-mail address]
|Sent: Thursday, April 04, 2002 7:35 PM
|To: aspngescalate
|Subject: [aspngescalate] COM object performance
|
|(I first asked this 7 hours ago on [aspngmigrate], resent w/ "NOT ANSWERED
|BEFORE" 5 hours ago, and received one response, which is detailed
|at the end
|of this message.)
|
|I have a reporting DLL written in Visual Basic (STA threading) that uses
|Data Dynamics' ActiveReports component. Here's how I'm using it in my
|ASP.NET app, from lowest layer to highest:
|
|ActiveReports DLL
|My VB COM DLL that instantiates ActiveReports
|.NET wrapper around the COM object made using tlbimp
|Another .NET component that sets needed properties on the .NET wrapper
|ASP.NET codebehind that instantiates the .NET component
|ASP.NET page (.aspx) that inherits from the codebehind
|
|In the .aspx, I have aspcompat="true" set since it's using an STA object.
|Yet, I still see strange performance. Sometimes it takes 2-3 seconds.
|Sometimes it takes 30. Sometimes it takes 60. And one time, I think it may
|have locked up the ASP.NET worker process (though I'm not sure the
|app is to
|blame on that).
|
|Sounds like threading issues from what I've read in the docs. Any
|suggestions? Anything to check? What's going wrong?
|
|As I said, I've received one response to my message. He thought my VB COM
|object was single-threaded, which it is not--it's apartment-threaded (STA).
|One thing he suggested is running the COM object outside of the
|IIS process.
|I don't have much experience with COM+, but I know that would be outside of
|the IIS process. Is this a good idea? And if it would solve my
|problem, why?
|
|Thanks,
|Peter

Reply to this message...

Ries Vriend

Peter,

I did have the same experience when using a 'chatty' VB6 STA COM object
from ASP.NET (a lot of property let/get access on the VB object). With a
single user, performance was mostly OK, but under a little more stress
extremely long delays occurred, although I did not try aspcompat mode.

Instead I just registered the VB component as a COM+ out of process
application. No other settings required (e.g Transactions Not
Supported), just a user account for its identity.

This solved our scalability problems. As I understand it, .NET now
creates its wrappers around the out-of-proc objects; each of which is
assigned a private apartment by COM+, thus preventing any bottlenecks
between thread communication and synchronization.

One caveat still to explore: under extreme stress (tens of concurrent
instantiations of the object), our COM+ app once hung. ASP.NET recycled
its worker process automatically but to no avail, as COM+ in Windows
2000 does not have a comparable mechanism to restart the hung
application. So, now I am thinking of moving back to an in process DLL
once again, but now in aspcompat mode (assuming that it is going to work
acceptably fast, which I now doubt reading your message). If so, any
hang-ups can be resolved automatically as the DLL will be reloaded when
the ASP.NET workprocess is recycled.

Anyone out there who can tell if that would be good approach?

Regards,

Ries Vriend
www.devexp.com

-----Original Message-----
From: Peter Brunone [mailto:Click here to reveal e-mail address]
Sent: vrijdag 5 april 2002 5:08
To: aspngescalate
Subject: [aspngescalate] RE: COM object performance

Peter,

One thing I can think of is that you should be sure to declare
Single-Threaded Apartment (STA) objects in a sub rather than the global,
"constructor" area. Of course you're probably already doing this, so...
Is the component doing a lot of talking back and forth to the DB
and/or
other objects? Chatty COM assemblies are a problem now as well as then.
I
seem to remember that using a lot of string properties will be expensive
for
COM interop as well. Also -- probably a silly question -- is your .NET
wrapper early-bound? The use of tblimp may make this a no-brainer, but
I've
never done it before, so take it or leave it :)

Just my fuzzy, muttering $0.02...

Peter B

|-----Original Message-----
|From: Johnson, Peter [mailto:Click here to reveal e-mail address]
|Sent: Thursday, April 04, 2002 7:35 PM
|To: aspngescalate
|Subject: [aspngescalate] COM object performance
|
|(I first asked this 7 hours ago on [aspngmigrate], resent w/ "NOT
ANSWERED
|BEFORE" 5 hours ago, and received one response, which is detailed
|at the end
|of this message.)
|
|I have a reporting DLL written in Visual Basic (STA threading) that
uses
|Data Dynamics' ActiveReports component. Here's how I'm using it in my
|ASP.NET app, from lowest layer to highest:
|
|ActiveReports DLL
|My VB COM DLL that instantiates ActiveReports
|.NET wrapper around the COM object made using tlbimp
|Another .NET component that sets needed properties on the .NET wrapper
|ASP.NET codebehind that instantiates the .NET component
|ASP.NET page (.aspx) that inherits from the codebehind
|
|In the .aspx, I have aspcompat="true" set since it's using an STA
object.
|Yet, I still see strange performance. Sometimes it takes 2-3 seconds.
|Sometimes it takes 30. Sometimes it takes 60. And one time, I think it
may
|have locked up the ASP.NET worker process (though I'm not sure the
|app is to
|blame on that).
|
|Sounds like threading issues from what I've read in the docs. Any
|suggestions? Anything to check? What's going wrong?
|
|As I said, I've received one response to my message. He thought my VB
COM
|object was single-threaded, which it is not--it's apartment-threaded
(STA).
|One thing he suggested is running the COM object outside of the
|IIS process.
|I don't have much experience with COM+, but I know that would be
outside of
|the IIS process. Is this a good idea? And if it would solve my
|problem, why?
|
|Thanks,
|Peter

| [aspngescalate] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngescalate.asp = JOIN/QUIT

Reply to this message...

ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification

Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews

.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT

Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project

FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.

Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials

	Copyright © ExamGuru, Inc. 2001-2006
	Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification