ASP / ADO Recordset field binding

[Lluis O]

We have an externally developed application, that runs on a W2K IIS 5 (
sp4 ) Server, and are very unhappy with the performance, as our users are
getting very very bad response times from the IIS Server, not being a
conceptually complicated / big application at all.

I'm very new in the IIS / ASP world, but I'm begining to suspect that the
whole application has a faulty design, and a worst implementation.

When the server is at 100% cpu load - one or two connected users are
enough -, we observe that all cpu waste come from two DLLHOST.exe. We traced
that one of those DLLHOST.exe comes from the IIS ASP application itself,
being the other the wrapper of the COM+ objects that go to the SQL / Server
2000 DataBase - in another Server.

Basically, both DLLHOST.exe processes seems to split 50% of cpu each ... at
the end of the day, the total cpu used is about the same for both ... that
was the first weird thing that I realized.

So, in my first guess, I thougt in some kind of performance problem, caused
by an excessive inter-communication / marshalling between ASP - in one
DLLHOST, and the COM+ objects in the other DLLHOST. So basically, most of
the cpu was being wasted going from one to the other, and from the other to
the one ... not really doing very useful stuff in between.

So, I looked at the ASP scripting code, in some of the worst response-time
pages, and ... bingo ... I found something like this :

<%
WHILE NOT RS.EOF
%>
<TD><%=RS("field1") & ", " & RS("field2")%></TD>

<-- ABOUT 50 more <%=RS("field..")%> -->

<%
RS.MoveNext
WEND
RS = Nothing
%>

RS is a recordset returned by a COM+ object, which is instanciated in the
ASP page itself. So, I remembered my old days with Visual Basic, and quickly
replaced the inefficient code with ...

<%
FIRSTREC = 0

WHILE NOT RS.EOF %>

IF FIRSTREC = 0 Then
FIRSTREC = 1

SET RS_Field1 = RS("Field1")
SET RS_Field2 = RS("Field2")
SET ...
END IF

FIELD1 = RS_FIELD1
FIELD2 = RS_FIELD2
...
<TD><%=FIELD1 & ", " & FIELD2%></TD>

<-- ABOUT 50 more <%=FIELDnn%> -->

<%
RS.MoveNext
WEND
RS = Nothing
%>

My first impression - before testing - was that the cpu time would decreasse
to something like 1/2 or 1/3 of the original ... but I got shocked and
astonished: The cpu time went to 1/25 of the original ... in plain text: 25
times FASTER (twenty five). No body could belive it , we had to check
several times ... after all, the application was not slow at all - the
developers were a really crap.

So may question is : What is happening here ? Is so, so, so BAD to reference
a ADO recordset field as RS("field") , instead of binding the fields, and
using local variables in the ASP code ? The communication between ASP and
COM+ layer is so terrible slow and inefficient as it seems ?

Can some of you comment an enlight us on this ?

Thanks very much

[Bob Barrows [MVP]]

Lluis O wrote:
<snip>

> RS is a recordset returned by a COM+ object, which is instanciated in
> the ASP page itself. So, I remembered my old days with Visual Basic,
> and quickly replaced the inefficient code with ...
>
> <%
> FIRSTREC = 0
>
> WHILE NOT RS.EOF %>
>
> IF FIRSTREC = 0 Then
> FIRSTREC = 1
>
> SET RS_Field1 = RS("Field1")
> SET RS_Field2 = RS("Field2")
> SET ...
> END IF

I would have done this part outside of the loop. Why make it process this If
statement for every record?

>
> FIELD1 = RS_FIELD1
> FIELD2 = RS_FIELD2
> ...
> <TD><%=FIELD1 & ", " & FIELD2%></TD>
>
> <-- ABOUT 50 more <%=FIELDnn%> -->
>
> <%
> RS.MoveNext
> WEND
> RS = Nothing
> %>
>
> My first impression - before testing - was that the cpu time would
> decreasse to something like 1/2 or 1/3 of the original ... but I got
> shocked and astonished: The cpu time went to 1/25 of the original ...
> in plain text: 25 times FASTER (twenty five). No body could belive it
> , we had to check several times ... after all, the application was
> not slow at all - the developers were a really crap.
>
> So may question is : What is happening here ? Is so, so, so BAD to
> reference a ADO recordset field as RS("field") , instead of binding
> the fields, and using local variables in the ASP code ?

In a word: yes.

Using the name of the field to reference it is the slowest method of getting
a reference to the Field object. This applies to all collections, not just
the ADO Fields collection. The fastest way to get a property value from a
Field object is to use a Field object variable as you did. This is because
the Field variable ALREADY HAS a reference to the Field object. When you use
rs(0) or rs("fieldname"), you are forcing the creation of a new temporary
variable for that field for EVERY pass through the loop. This will have a
significant impact on performance as you've discovered.

The next fastest method is to use the index of the Field object (rs(0),
rs(1), etc.).

Using the Field objects as you did is pretty good (in fact, if I MUST loop
through a recordset, I will always use Field objects), but you can do even
better than that:

Dim arData, i
If Not RS.EOF Then arData = RS.GetRows
RS.Close: Set RS = Nothing

If IsArray(arData) Then
For i = 0 to Ubound(arData,2)
%>
<TD><%=arData(0,i) & ", " & arData(1,i)%></TD>

Etc.
<%
Next
End If

See here for more information: [url]http://www.aspfaq.com/show.asp?id=2467[/url]

>The
> communication between ASP and COM+ layer is so terrible slow and
> inefficient as it seems ?
>

Marshalling objects across processes is expensive. However, some feel the
benefits (encapsulation, security, etc.) outweigh the loss of performance.
You could probably improve performance by changing the COM+ object to return
variant arrays instead of recordset objects. Based on the above, however, I
suspect this isn't the bottleneck in your application.

HTH,
Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Lluis O]

Bob, thank you very much for responding !

> Using the Field objects as you did is pretty good (in fact, if I MUST loop
> through a recordset, I will always use Field objects), but you can do even
> better than that:

I've no doubt now that best way to access recordset columns inside a Loop if
pre-binding the fields, and using local ASP variables - specialy if the same
recordset column is used several times inside the loop - as it's my case.

But I'm still worried about why is the cpu difference so big ? I didn't
remember such cpu gains from this "trick" when I worked with Visual Basic
.... We are talking that cpu time is 25 times less, which is a brutality.

I don't have the server accesible rigth now, but I suspect that the object
returning the recordset, which I know uses COM+ technology, is defined
inside a COM+ "Server Application", and not a "Library Application" ...
Could that explain why is so, and so expensive to access the field column
contents using RS("field") ... ?

And, if it's defined as a "Server Application" ... could I simply use the
COM+ manager, and change the property of the Application to be a "Library
Application ? I've no access to the sources or definitions of such objects,
and I don't know if you have to compile / assemble differently a COM+ object
if you intend to use it as a "Library" or as a "Server" ... What can happen
if I simply change the setting to be a "Library Application" ?

Thanks very much indeed.

[Bob Barrows [MVP]]

Lluis O wrote:

> Bob, thank you very much for responding !
>

>> Using the Field objects as you did is pretty good (in fact, if I
>> MUST loop through a recordset, I will always use Field objects), but
>> you can do even better than that:

>
> I've no doubt now that best way to access recordset columns inside a
> Loop if pre-binding the fields, and using local ASP variables -
> specialy if the same recordset column is used several times inside
> the loop - as it's my case.
>
> But I'm still worried about why is the cpu difference so big ? I
> didn't remember such cpu gains from this "trick" when I worked with
> Visual Basic ... We are talking that cpu time is 25 times less, which
> is a brutality.

There are threading issues that do not impact a client application as much
as a server application.

>
> I don't have the server accesible rigth now, but I suspect that the
> object returning the recordset, which I know uses COM+ technology, is
> defined inside a COM+ "Server Application", and not a "Library
> Application" ... Could that explain why is so, and so expensive to
> access the field column contents using RS("field") ... ?

No. an ADO recordset is an ADO recordset, regardless of its source. The fact
is: an ADO recordset is not the most efficient mechanism for looping through
data sets.

>
> And, if it's defined as a "Server Application" ... could I simply use
> the COM+ manager, and change the property of the Application to be a
> "Library Application ?

I doubt this will have much of an impact.

Bob Barrows

--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Mendel]

I was curious and decided to try a test.

I have a page which loops through aprox 4,500 records,
with aprox 10 fields per record.

this is running on a 2003 Server.

this page takes aprox .25 seconds to generate with using rs
("Field1").value.

I changed it to use field object variables and the time of
execution went down to .17 seconds. That's a nice
improvement but hardly a 25 time improvement.

Mendel Nemanov

>-----Original Message-----
>We have an externally developed application, that runs on

a W2K IIS 5 (

>sp4 ) Server, and are very unhappy with the performance,

as our users are

>getting very very bad response times from the IIS Server,

not being a

>conceptually complicated / big application at all.
>
>I'm very new in the IIS / ASP world, but I'm begining to

suspect that the

>whole application has a faulty design, and a worst

implementation.

>
>When the server is at 100% cpu load - one or two

connected users are

>enough -, we observe that all cpu waste come from two

DLLHOST.exe. We traced

>that one of those DLLHOST.exe comes from the IIS ASP

application itself,

>being the other the wrapper of the COM+ objects that go

to the SQL / Server

>2000 DataBase - in another Server.
>
>Basically, both DLLHOST.exe processes seems to split 50%

of cpu each ... at

>the end of the day, the total cpu used is about the same

for both ... that

>was the first weird thing that I realized.
>
>So, in my first guess, I thougt in some kind of

performance problem, caused

>by an excessive inter-communication / marshalling between

ASP - in one

>DLLHOST, and the COM+ objects in the other DLLHOST. So

basically, most of

>the cpu was being wasted going from one to the other, and

from the other to

>the one ... not really doing very useful stuff in between.
>
>So, I looked at the ASP scripting code, in some of the

worst response-time

>pages, and ... bingo ... I found something like this :
>
><%
>WHILE NOT RS.EOF
>%>
> <TD><%=RS("field1") & ", " & RS("field2")%></TD>
>
><-- ABOUT 50 more <%=RS("field..")%> -->
>
><%
>RS.MoveNext
> WEND
> RS = Nothing
>%>
>
>RS is a recordset returned by a COM+ object, which is

instanciated in the

>ASP page itself. So, I remembered my old days with Visual

Basic, and quickly

>replaced the inefficient code with ...
>
><%
>FIRSTREC = 0
>
>WHILE NOT RS.EOF %>
>
> IF FIRSTREC = 0 Then
> FIRSTREC = 1
>
> SET RS_Field1 = RS("Field1")
> SET RS_Field2 = RS("Field2")
> SET ...
> END IF
>
> FIELD1 = RS_FIELD1
> FIELD2 = RS_FIELD2
> ...
> <TD><%=FIELD1 & ", " & FIELD2%></TD>
>
><-- ABOUT 50 more <%=FIELDnn%> -->
>
><%
>RS.MoveNext
> WEND
> RS = Nothing
>%>
>
>My first impression - before testing - was that the cpu

time would decreasse

>to something like 1/2 or 1/3 of the original ... but I

got shocked and

>astonished: The cpu time went to 1/25 of the original ...

in plain text: 25

>times FASTER (twenty five). No body could belive it , we

had to check

>several times ... after all, the application was not slow

at all - the

>developers were a really crap.
>
>So may question is : What is happening here ? Is so, so,

so BAD to reference

>a ADO recordset field as RS("field") , instead of binding

the fields, and

>using local variables in the ASP code ? The communication

between ASP and

>COM+ layer is so terrible slow and inefficient as it

seems ?

>
>Can some of you comment an enlight us on this ?
>
>Thanks very much
>
>
>.
>

[Lluis O]

Hi

I'm also searching what else can be happening here. We didn't expect such
cpu gain ... but ...

As a curiosity ... your COM+ objects are being run as "Server application",
or as a "Library application" ? Ours are being run as "Server application"
.... don't know why, we didn't develop this application ! I'm investigating
about changing this setting.

Also, our servers had been "hit" by the MS04-011 security patch, and we're
experiencing very weirds behaviours on our W2K servers since then.

Thank you very much

"Mendel" <mendel@spotlightdesign.kom> escribió en el mensaje
news:1c51f01c45260$4d303700$a101280a@phx.gbl...

> I was curious and decided to try a test.
>
> I have a page which loops through aprox 4,500 records,
> with aprox 10 fields per record.
>
> this is running on a 2003 Server.
>
> this page takes aprox .25 seconds to generate with using rs
> ("Field1").value.
>
> I changed it to use field object variables and the time of
> execution went down to .17 seconds. That's a nice
> improvement but hardly a 25 time improvement.
>
> Mendel Nemanov
>

> >-----Original Message-----
> >We have an externally developed application, that runs on

> a W2K IIS 5 (

> >sp4 ) Server, and are very unhappy with the performance,

> as our users are

> >getting very very bad response times from the IIS Server,

> not being a

> >conceptually complicated / big application at all.
> >
> >I'm very new in the IIS / ASP world, but I'm begining to

> suspect that the

> >whole application has a faulty design, and a worst

> implementation.

> >
> >When the server is at 100% cpu load - one or two

> connected users are

> >enough -, we observe that all cpu waste come from two

> DLLHOST.exe. We traced

> >that one of those DLLHOST.exe comes from the IIS ASP

> application itself,

> >being the other the wrapper of the COM+ objects that go

> to the SQL / Server

> >2000 DataBase - in another Server.
> >
> >Basically, both DLLHOST.exe processes seems to split 50%

> of cpu each ... at

> >the end of the day, the total cpu used is about the same

> for both ... that

> >was the first weird thing that I realized.
> >
> >So, in my first guess, I thougt in some kind of

> performance problem, caused

> >by an excessive inter-communication / marshalling between

> ASP - in one

> >DLLHOST, and the COM+ objects in the other DLLHOST. So

> basically, most of

> >the cpu was being wasted going from one to the other, and

> from the other to

> >the one ... not really doing very useful stuff in between.
> >
> >So, I looked at the ASP scripting code, in some of the

> worst response-time

> >pages, and ... bingo ... I found something like this :
> >
> ><%
> >WHILE NOT RS.EOF
> >%>
> > <TD><%=RS("field1") & ", " & RS("field2")%></TD>
> >
> ><-- ABOUT 50 more <%=RS("field..")%> -->
> >
> ><%
> >RS.MoveNext
> > WEND
> > RS = Nothing
> >%>
> >
> >RS is a recordset returned by a COM+ object, which is

> instanciated in the

> >ASP page itself. So, I remembered my old days with Visual

> Basic, and quickly

> >replaced the inefficient code with ...
> >
> ><%
> >FIRSTREC = 0
> >
> >WHILE NOT RS.EOF %>
> >
> > IF FIRSTREC = 0 Then
> > FIRSTREC = 1
> >
> > SET RS_Field1 = RS("Field1")
> > SET RS_Field2 = RS("Field2")
> > SET ...
> > END IF
> >
> > FIELD1 = RS_FIELD1
> > FIELD2 = RS_FIELD2
> > ...
> > <TD><%=FIELD1 & ", " & FIELD2%></TD>
> >
> ><-- ABOUT 50 more <%=FIELDnn%> -->
> >
> ><%
> >RS.MoveNext
> > WEND
> > RS = Nothing
> >%>
> >
> >My first impression - before testing - was that the cpu

> time would decreasse

> >to something like 1/2 or 1/3 of the original ... but I

> got shocked and

> >astonished: The cpu time went to 1/25 of the original ...

> in plain text: 25

> >times FASTER (twenty five). No body could belive it , we

> had to check

> >several times ... after all, the application was not slow

> at all - the

> >developers were a really crap.
> >
> >So may question is : What is happening here ? Is so, so,

> so BAD to reference

> >a ADO recordset field as RS("field") , instead of binding

> the fields, and

> >using local variables in the ASP code ? The communication

> between ASP and

> >COM+ layer is so terrible slow and inefficient as it

> seems ?

> >
> >Can some of you comment an enlight us on this ?
> >
> >Thanks very much
> >
> >
> >.
> >

[Lluis O]

... and I forgot to mention that the Recorset has about 10 fields, but those
are referenced several times in every loop ... one of the fields is
referenced 35 times ! The others are referenced two or three times per
iteration ... go figure !

If we someday find the original developers, wherever they are now ... grrr
:-(

Thanks

"Mendel" <mendel@spotlightdesign.kom> escribió en el mensaje
news:1c51f01c45260$4d303700$a101280a@phx.gbl...

> I was curious and decided to try a test.
>
> I have a page which loops through aprox 4,500 records,
> with aprox 10 fields per record.
>
> this is running on a 2003 Server.
>
> this page takes aprox .25 seconds to generate with using rs
> ("Field1").value.
>
> I changed it to use field object variables and the time of
> execution went down to .17 seconds. That's a nice
> improvement but hardly a 25 time improvement.
>
> Mendel Nemanov
>

> >-----Original Message-----
> >We have an externally developed application, that runs on

> a W2K IIS 5 (

> >sp4 ) Server, and are very unhappy with the performance,

> as our users are

> >getting very very bad response times from the IIS Server,

> not being a

> >conceptually complicated / big application at all.
> >
> >I'm very new in the IIS / ASP world, but I'm begining to

> suspect that the

> >whole application has a faulty design, and a worst

> implementation.

> >
> >When the server is at 100% cpu load - one or two

> connected users are

> >enough -, we observe that all cpu waste come from two

> DLLHOST.exe. We traced

> >that one of those DLLHOST.exe comes from the IIS ASP

> application itself,

> >being the other the wrapper of the COM+ objects that go

> to the SQL / Server

> >2000 DataBase - in another Server.
> >
> >Basically, both DLLHOST.exe processes seems to split 50%

> of cpu each ... at

> >the end of the day, the total cpu used is about the same

> for both ... that

> >was the first weird thing that I realized.
> >
> >So, in my first guess, I thougt in some kind of

> performance problem, caused

> >by an excessive inter-communication / marshalling between

> ASP - in one

> >DLLHOST, and the COM+ objects in the other DLLHOST. So

> basically, most of

> >the cpu was being wasted going from one to the other, and

> from the other to

> >the one ... not really doing very useful stuff in between.
> >
> >So, I looked at the ASP scripting code, in some of the

> worst response-time

> >pages, and ... bingo ... I found something like this :
> >
> ><%
> >WHILE NOT RS.EOF
> >%>
> > <TD><%=RS("field1") & ", " & RS("field2")%></TD>
> >
> ><-- ABOUT 50 more <%=RS("field..")%> -->
> >
> ><%
> >RS.MoveNext
> > WEND
> > RS = Nothing
> >%>
> >
> >RS is a recordset returned by a COM+ object, which is

> instanciated in the

> >ASP page itself. So, I remembered my old days with Visual

> Basic, and quickly

> >replaced the inefficient code with ...
> >
> ><%
> >FIRSTREC = 0
> >
> >WHILE NOT RS.EOF %>
> >
> > IF FIRSTREC = 0 Then
> > FIRSTREC = 1
> >
> > SET RS_Field1 = RS("Field1")
> > SET RS_Field2 = RS("Field2")
> > SET ...
> > END IF
> >
> > FIELD1 = RS_FIELD1
> > FIELD2 = RS_FIELD2
> > ...
> > <TD><%=FIELD1 & ", " & FIELD2%></TD>
> >
> ><-- ABOUT 50 more <%=FIELDnn%> -->
> >
> ><%
> >RS.MoveNext
> > WEND
> > RS = Nothing
> >%>
> >
> >My first impression - before testing - was that the cpu

> time would decreasse

> >to something like 1/2 or 1/3 of the original ... but I

> got shocked and

> >astonished: The cpu time went to 1/25 of the original ...

> in plain text: 25

> >times FASTER (twenty five). No body could belive it , we

> had to check

> >several times ... after all, the application was not slow

> at all - the

> >developers were a really crap.
> >
> >So may question is : What is happening here ? Is so, so,

> so BAD to reference

> >a ADO recordset field as RS("field") , instead of binding

> the fields, and

> >using local variables in the ASP code ? The communication

> between ASP and

> >COM+ layer is so terrible slow and inefficient as it

> seems ?

> >
> >Can some of you comment an enlight us on this ?
> >
> >Thanks very much
> >
> >
> >.
> >

[Mendel]

If a field is referenced multiple times in each loop I
usually assign the value of the field to a local variable
(e.g.
dim lID
do while not rs.eof
lID = rs("ID").value
'or if using field variables
lID = fID.value
'do stuff
rs.movenext
loop
) and then use the varialble within the loop.

that should be even faster than using the field object
variable 35 times within the loop.

Mendel

>-----Original Message-----
>... and I forgot to mention that the Recorset has about

10 fields, but those

>are referenced several times in every loop ... one of the

fields is

>referenced 35 times ! The others are referenced two or

three times per

>iteration ... go figure !
>
>If we someday find the original developers, wherever they

are now ... grrr

>:-(
>
>Thanks
>
>"Mendel" <mendel@spotlightdesign.kom> escribió en el

mensaje

>news:1c51f01c45260$4d303700$a101280a@phx.gbl...

>> I was curious and decided to try a test.
>>
>> I have a page which loops through aprox 4,500 records,
>> with aprox 10 fields per record.
>>
>> this is running on a 2003 Server.
>>
>> this page takes aprox .25 seconds to generate with

using rs

>> ("Field1").value.
>>
>> I changed it to use field object variables and the time

of

>> execution went down to .17 seconds. That's a nice
>> improvement but hardly a 25 time improvement.
>>
>> Mendel Nemanov
>>

>> >-----Original Message-----
>> >We have an externally developed application, that runs

on

>> a W2K IIS 5 (

>> >sp4 ) Server, and are very unhappy with the

performance,

>> as our users are

>> >getting very very bad response times from the IIS

Server,

>> not being a

>> >conceptually complicated / big application at all.
>> >
>> >I'm very new in the IIS / ASP world, but I'm begining

to

>> suspect that the

>> >whole application has a faulty design, and a worst

>> implementation.

>> >
>> >When the server is at 100% cpu load - one or two

>> connected users are

>> >enough -, we observe that all cpu waste come from two

>> DLLHOST.exe. We traced

>> >that one of those DLLHOST.exe comes from the IIS ASP

>> application itself,

>> >being the other the wrapper of the COM+ objects that go

>> to the SQL / Server

>> >2000 DataBase - in another Server.
>> >
>> >Basically, both DLLHOST.exe processes seems to split

50%

>> of cpu each ... at

>> >the end of the day, the total cpu used is about the

same

>> for both ... that

>> >was the first weird thing that I realized.
>> >
>> >So, in my first guess, I thougt in some kind of

>> performance problem, caused

>> >by an excessive inter-communication / marshalling

between

>> ASP - in one

>> >DLLHOST, and the COM+ objects in the other DLLHOST. So

>> basically, most of

>> >the cpu was being wasted going from one to the other,

and

>> from the other to

>> >the one ... not really doing very useful stuff in

between.

>> >
>> >So, I looked at the ASP scripting code, in some of the

>> worst response-time

>> >pages, and ... bingo ... I found something like this :
>> >
>> ><%
>> >WHILE NOT RS.EOF
>> >%>
>> > <TD><%=RS("field1") & ", " & RS("field2")%></TD>
>> >
>> ><-- ABOUT 50 more <%=RS("field..")%> -->
>> >
>> ><%
>> >RS.MoveNext
>> > WEND
>> > RS = Nothing
>> >%>
>> >
>> >RS is a recordset returned by a COM+ object, which is

>> instanciated in the

>> >ASP page itself. So, I remembered my old days with

Visual

>> Basic, and quickly

>> >replaced the inefficient code with ...
>> >
>> ><%
>> >FIRSTREC = 0
>> >
>> >WHILE NOT RS.EOF %>
>> >
>> > IF FIRSTREC = 0 Then
>> > FIRSTREC = 1
>> >
>> > SET RS_Field1 = RS("Field1")
>> > SET RS_Field2 = RS("Field2")
>> > SET ...
>> > END IF
>> >
>> > FIELD1 = RS_FIELD1
>> > FIELD2 = RS_FIELD2
>> > ...
>> > <TD><%=FIELD1 & ", " & FIELD2%></TD>
>> >
>> ><-- ABOUT 50 more <%=FIELDnn%> -->
>> >
>> ><%
>> >RS.MoveNext
>> > WEND
>> > RS = Nothing
>> >%>
>> >
>> >My first impression - before testing - was that the cpu

>> time would decreasse

>> >to something like 1/2 or 1/3 of the original ... but I

>> got shocked and

>> >astonished: The cpu time went to 1/25 of the

original ...

>> in plain text: 25

>> >times FASTER (twenty five). No body could belive it ,

we

>> had to check

>> >several times ... after all, the application was not

slow

>> at all - the

>> >developers were a really crap.
>> >
>> >So may question is : What is happening here ? Is so,

so,

>> so BAD to reference

>> >a ADO recordset field as RS("field") , instead of

binding

>> the fields, and

>> >using local variables in the ASP code ? The

communication

>> between ASP and

>> >COM+ layer is so terrible slow and inefficient as it

>> seems ?

>> >
>> >Can some of you comment an enlight us on this ?
>> >
>> >Thanks very much
>> >
>> >
>> >.
>> >

>
>
>.
>

[Mendel]

I'm using plain vanilla connection and recordset objects.
no custom COM objects. some recordsets come from stored
procedures, some from dynamicaly generated SQL statements.
(and the SQL server is on the same physical machine as the
IIS server, that certainly helps performance as long as
scalability is not an issue)

My server is Windows 2003, I have all the security patches
and I did not have any problems.

Mendel

>-----Original Message-----
>Hi
>
>I'm also searching what else can be happening here. We

didn't expect such

>cpu gain ... but ...
>
>As a curiosity ... your COM+ objects are being run

as "Server application",

>or as a "Library application" ? Ours are being run

as "Server application"

>.... don't know why, we didn't develop this application !

I'm investigating

>about changing this setting.
>
>Also, our servers had been "hit" by the MS04-011 security

patch, and we're

>experiencing very weirds behaviours on our W2K servers

since then.

>
>Thank you very much
>
>"Mendel" <mendel@spotlightdesign.kom> escribió en el

mensaje

>news:1c51f01c45260$4d303700$a101280a@phx.gbl...

>> I was curious and decided to try a test.
>>
>> I have a page which loops through aprox 4,500 records,
>> with aprox 10 fields per record.
>>
>> this is running on a 2003 Server.
>>
>> this page takes aprox .25 seconds to generate with

using rs

>> ("Field1").value.
>>
>> I changed it to use field object variables and the time

of

>> execution went down to .17 seconds. That's a nice
>> improvement but hardly a 25 time improvement.
>>
>> Mendel Nemanov
>>

>> >-----Original Message-----
>> >We have an externally developed application, that runs

on

>> a W2K IIS 5 (

>> >sp4 ) Server, and are very unhappy with the

performance,

>> as our users are

>> >getting very very bad response times from the IIS

Server,

>> not being a

>> >conceptually complicated / big application at all.
>> >
>> >I'm very new in the IIS / ASP world, but I'm begining

to

>> suspect that the

>> >whole application has a faulty design, and a worst

>> implementation.

>> >
>> >When the server is at 100% cpu load - one or two

>> connected users are

>> >enough -, we observe that all cpu waste come from two

>> DLLHOST.exe. We traced

>> >that one of those DLLHOST.exe comes from the IIS ASP

>> application itself,

>> >being the other the wrapper of the COM+ objects that go

>> to the SQL / Server

>> >2000 DataBase - in another Server.
>> >
>> >Basically, both DLLHOST.exe processes seems to split

50%

>> of cpu each ... at

>> >the end of the day, the total cpu used is about the

same

>> for both ... that

>> >was the first weird thing that I realized.
>> >
>> >So, in my first guess, I thougt in some kind of

>> performance problem, caused

>> >by an excessive inter-communication / marshalling

between

>> ASP - in one

>> >DLLHOST, and the COM+ objects in the other DLLHOST. So

>> basically, most of

>> >the cpu was being wasted going from one to the other,

and

>> from the other to

>> >the one ... not really doing very useful stuff in

between.

>> >
>> >So, I looked at the ASP scripting code, in some of the

>> worst response-time

>> >pages, and ... bingo ... I found something like this :
>> >
>> ><%
>> >WHILE NOT RS.EOF
>> >%>
>> > <TD><%=RS("field1") & ", " & RS("field2")%></TD>
>> >
>> ><-- ABOUT 50 more <%=RS("field..")%> -->
>> >
>> ><%
>> >RS.MoveNext
>> > WEND
>> > RS = Nothing
>> >%>
>> >
>> >RS is a recordset returned by a COM+ object, which is

>> instanciated in the

>> >ASP page itself. So, I remembered my old days with

Visual

>> Basic, and quickly

>> >replaced the inefficient code with ...
>> >
>> ><%
>> >FIRSTREC = 0
>> >
>> >WHILE NOT RS.EOF %>
>> >
>> > IF FIRSTREC = 0 Then
>> > FIRSTREC = 1
>> >
>> > SET RS_Field1 = RS("Field1")
>> > SET RS_Field2 = RS("Field2")
>> > SET ...
>> > END IF
>> >
>> > FIELD1 = RS_FIELD1
>> > FIELD2 = RS_FIELD2
>> > ...
>> > <TD><%=FIELD1 & ", " & FIELD2%></TD>
>> >
>> ><-- ABOUT 50 more <%=FIELDnn%> -->
>> >
>> ><%
>> >RS.MoveNext
>> > WEND
>> > RS = Nothing
>> >%>
>> >
>> >My first impression - before testing - was that the cpu

>> time would decreasse

>> >to something like 1/2 or 1/3 of the original ... but I

>> got shocked and

>> >astonished: The cpu time went to 1/25 of the

original ...

>> in plain text: 25

>> >times FASTER (twenty five). No body could belive it ,

we

>> had to check

>> >several times ... after all, the application was not

slow

>> at all - the

>> >developers were a really crap.
>> >
>> >So may question is : What is happening here ? Is so,

so,

>> so BAD to reference

>> >a ADO recordset field as RS("field") , instead of

binding

>> the fields, and

>> >using local variables in the ASP code ? The

communication

>> between ASP and

>> >COM+ layer is so terrible slow and inefficient as it

>> seems ?

>> >
>> >Can some of you comment an enlight us on this ?
>> >
>> >Thanks very much
>> >
>> >
>> >.
>> >

>
>
>.
>