Stress testing help

[cpnet]

I'm trying to stress-test some controls I've built in a sample web app using
ACT. I'm now using IIS on my SBS 2k3 machine as my webserver for the test,
and ACT is running on my XP Pro (sp1) machine. When I run through my test
without act, I get a server response for all requests in well under a
second. However, when I have ACT running to record a test, those same
requests can take 10-20 seconds! Similarly, when I run a test consisting of
12 or so page requests in ACT (1 browser connection, 1 iteration), the test
can take nearly 2 minutes to complete. When act isn't running, I can go
through the whole test myself manually in IE 6 in a few seconds.

It seems something in ACT is really slowing things down and skewing any test
results. I guess my questions are:

- How can I fix this problem?
- Is there a better stress-test tool than ACT (hopefully cheap or free)?
- Where's the best place to get ACT info? Postings to the MS ACT newsgroup
don't often get responses.

Thanks,
cpnet

 

[Guest]

Have you tried testing other pages on the server? Or even other pages off of
the server. Do you get the same results?

 

[cpnet]

Hmm... good catch. Other sites served by IIS on my SBS server are fine
recording and 'playing' in ACT (I even tried the remote desktop stuff that
uses some .aspx pages). It's just my WebForm that's causing problems - and
only when ACT is recording or 'playing' a test that uses my WebForm. When I
don't involve ACT, my WebForm runs just fine.

I added some tracing to my test script and confirmed that it's the
"oConnection.Send(oRequest)" call specifically that's taking the time (10-15
seconds). But the same request without ACT is really fast (it seems much
less than a second).

Is there some web.config setting I need to be messing with? I'm still
changing and debugging my app, so it's a debug build I put on my server (if
that makes any difference).

 

[Guest]

The other thing you can try to see if it is an ACT issue is to create a
simple console application that uses the WebClient class in the System.Net
namespace. This may only be a couple of lines of code and you can put it in a
loop to see what you come up with.

And personally I have not noticed a difference in web apps that I have set
to "Release" instead of "Debug".

 

[cpnet]

Thanks for your help. The problem turned out to be that I had set the
"buffer" property of the DOCUMENT for the WebForm to "false". I'm not sure
when/why I even changed this, and I'm not 100% sure what it does. The
dynamic content of my page seems to update regardless of this setting, and I
see the slow-down even during the initial request, which makes me wonder
what is getting buffered.

Anyway, I've set DOCUMENT.buffer back to "true" and all is well (for now).

 

[Steven Cheng[MSFT]]

Hi Cpnet,

Thanks for posting. Since you mentioned that the problem turn out to be the
DOCUMENT.buffer setting for the Webform page,yes? Do you mean the ASP.NET
page's Response.Buffer setting? As far as I know, there does exsit a known
issue of the IIS6 processing unbuffered ASP page.(ASP not asp.net) When
we set Response.Buffer = false, it will cause poor performance and even
large memory usage. Here is the description on the problem:
================================================================
ASP will
allocate the entire buffer 2k and sending it to HTTP.sys. While HTTP.sys
will send
out just the 12 or 14 bytes in the buffer (in some cases more) the process
is
accounting for the whole 2k for each small packet. Now Http also has to do
the
kernel/user mode transition for each small packet containing a few bytes.
So with
many small sends, you have 2k * number of mini sends in unbuffered mode.
Which will
account for our memory consumption.
================================================================

And you only encounter the problem when using the ACT and just focus on a
certain web application, so I'm also not sure whether the problem is the
same. Anyway, I'll make a consult to some other experts to see whether this
is a exist problem and let you know. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[cpnet]

Hi Steven,

In the property editor in VS.NET 2003, I see all the controls in my WebForm
(.aspx) listed - including the WebForm itself. In addition, I see something
named, "DOCUMENT" listed in the property editor. It is the buffer property
of this DOCUMENT object that seems to be the source of the problem. In my
..aspx file, it seems to change the buffer attribute in the line below from
True to False (depending on how it's set):

<%@ Page language="c#" Codebehind="WebForm2.aspx.cs" AutoEventWireup="false"
Inherits="MyProject.WebForm2" buffer="True"%>
or
<%@ Page language="c#" Codebehind="WebForm2.aspx.cs" AutoEventWireup="false"
Inherits="MyProject.WebForm2" buffer="False"%>


It doesn't seem to make any change in the rendered HTML output that my
browser gets. Since I am dealing with .aspx pages, and not .asp, it sounds
like it's a different issue that the one you mentioned. I am using IIS 6.0
on a SBS 2k3 server (fully patched). And, the problem is only noticable
when I'm recording or running an ACT test.

 

[Steven Cheng[MSFT]]

Hi Cpnet,

Thanks for the response. Well, the "DOCUMENT" just means the webform and
the "Buffer" setting in the
@Page directive is just the same with the Response.Buffer property. And
after some further consulting , there isn't a existing issue with ACT when
testing the asp.net web app. But they still highly recommend that
we use page buffering. It is likely that when buffer turn off, each time a
Response.Write() is made inside of our page a new HTTP packet will be sent
to the client. This is a huge overhead. You can sniff one page with and
without page buffering and you will see the problem. In addition, there is
another MS provided
web application stress tooL:

#MS Web Application Stress Tool
http://www.microsoft.com/technet/archive/itsolutions/intranet/downloads/webs
tres.mspx

You can also have a try on this one and compare the result with ACT's to
see whether the problem is really concerned to ACT. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)