Groups | Blog | Home
all groups > dotnet performance > september 2006 >

dotnet performance : Concurrency and scalability issue


Phase 3 team
9/14/2006 7:24:01 AM
Hi again

Does anyone have any ideas on this?

Further R&D in the performance monitor has told us that the requests are
being queued in the .net request queue. (asp.net\requests queued)
No Queue is seen in the application request queue (asp.net\requests in
application queue)

Consequently, when we test with 30 concurrent users, the queue sits around
20 while the 'asp.et\requests executing' sits on about 6.

Throughput, which we measure with the "asp.net\requests /sec" comes out at
about 4.

How can that be? Surely .net can process more than 6 request at a time??

As i said before, this test page is very simple, no more than 2 inner loops.

Any ideas anyone, getting desperate.

Phase 3 team
9/14/2006 7:37:02 AM
Sorry i posted new, not replied. Here is the topic:

Hi

We have a major rollout of an asp.net application which will replace the
current static web page site. This site averages about 30/requests sec (2.5
million hits a day)

During our stress testing phase, we have noticed that the application cannot
handle any more than about 4/requests a sec. Reducing the application into
its component parts to find the problem has not given us any success. Even
stripping out all .net controls and replacing them with HTML controls has had
little impact.

When this stripped out page is run outside of a asp.net worker process (a
htm file), its throughput is as expected extremly fast, (+100 rec/s, TTFB
<10ms) but as soon as this now simple page (which now resembles a hello world
app!) goes through the asp.net worker process, it again reduces to a crawl.
(5 rec/s, TTFB +5s)

We use Microsofts WAS tool, and have tried various concurrent settings and
delay times, all to no avail. We are not 100% sure what this setting should
be, but anything above 1 to 10 concurrent threads produces 100% cpu, horrible
TTFB (>10s) and the application queues monitor exceeds 100. Thats not normal
is it? One concurrent thread on the WAS tool is fast, nearly the same as a
htm file. So what is the concurrency issue here?

The Applications queue goes up considerably, which is why the pages are
slow, but why, as this is just effectvely a page with a dozen html controls
on it now, no database, no nothing!!? help, please.

The server is a a dual xeon with 3gb ram, but similar results are found on a
simpler develpment machine.

Are we going wrong somewhere? Are we testing correctly?

Thanks

Phase 3 Team


[quoted text, click to view]
Chris Mullins
9/14/2006 6:29:17 PM
I wish I had a good answer for you. I can say I've had web servers way
higher than this on a number of occasions without any troubles.

If you're getting desperate, and it sounds like you are, there are really
two effective solutions:

1 - Open an MSDN trouble ticket (will cost about $100 to $200 USD). These
guys have been fantastic in the past when I've worked with them. I'm not
sure if they help with problems of your nature, but if you can, I would do
this immediatly.

2 - Wintellect offers a "Consulting and Debugging" service which would
probably get the job done for you very quickly and effectivly as well. You
can find details on this at:
http://www.wintellect.com/ConsultingandDebugging.aspx?show=1


--
Chris Mullins, MCSD.Net, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins



[quoted text, click to view]

AddThis Social Bookmark Button