Profiling HttpListener app

  • Thread starter Thread starter Mark
  • Start date Start date
M

Mark

Hi...

I've been profiling an HttpListener-based app that takes in POSTed xml of
~150 bytes and returns xml in roughly the 400-byte range.

One of the surprises in the profiling was that the line for reading the
request stream is listed by Quantify as taking about 28% of all the
processing time - the single biggest expense of the transaction, including
the parsing of the xml, processing and sending about 2-3x bytes back.

Here's the code we have for reading in the request:

// get the content of the message
HttpListenerRequest request = context.request;
string body;
using (StreamReader rdr = new StreamReader(request.InputStream,
request.ContentEncoding))
{
body = rdr.ReadToEnd();
}

Any idea why the read would be such a big expense?

Thanks
Mark
 
Hi Mark,

As for the performance result, did you get it under stress testing or just
for a single request?

Generally string reading/manipulation operations is expensive especially
when you frequently call such operations. Are the "reading request stream"
and "parsing xml" the only two places you deal with string data? I think
the "ReadToEnd" method's reading loop may take the most time here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).


This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------
 
Hi Steven...

"Steven Cheng" said:
As for the performance result, did you get it under stress testing or just
for a single request?
Click to expand...

It was a stress test of 100 concurrent users in 4 runs.
Generally string reading/manipulation operations is expensive especially
when you frequently call such operations. Are the "reading request stream"
and "parsing xml" the only two places you deal with string data? I think
the "ReadToEnd" method's reading loop may take the most time here.
Click to expand...

Actually this is part of my surprise. After we read the string, we parse it
into xml, do dom manipulation, some database calls, construct a string
response and then write it back as the response. The response string is
between 2 to 15 times as many bytes as the request. And with all that,
Purify says the single most expensive operation (~ 28% of the processing
time) was spent reading the request stream.

That's what prompted my question. If I/O was going to be the big limiting
factor, wouldn't the database calls rate higher? For that matter, wouldn't
writing out 2-15x more bytes than read in rate higher?

Thanks
Mark
 
Hi Steven...

I may have stumbled on something related here. I called
ThreadPool.GetMinThreads() and found that worker threads and iothreads were
set to 1.

My load tests were obviously pretty bursty, and between runs the app seems
to have killed off a lot of the threads. I changed the thread mins to 15 and
30 respectively, re-ran my tests as before, and the percentage time spent on
request.InputStream.ReadToEnd() dropped from ~28% of the overall time to ~3%.

Not sure what the optimal values should be, but clearly having more threads
hang around smooths out the processing of bursts of HttpListener traffic.

Thanks
Mark
 
Thanks for your reply Mark,

Yes, threading pool setting will affect the concurrent performance for
server-side application. I've omit this one since I normally only consider
it for ASP.NET web application. As for "what the optimal values should
be", there is no definite values. It depends on the following things:

1. How many concurrent ones you may need for your server-side application.
You can try measure how many concurrent requests will be processed
simultaneously and set the max thread pool value as large as that one.

2. How many ones can your server afford. Since more concurrent threads will
cause more CPU time(for context swtiching or other thread tasks..), you may
need to test to see the actual CPU performance and adjust the number based
on that.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
=
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
From: =?Utf-8?B?TWFyaw==?= <[email protected]>
References: <[email protected]>
Click to expand...
 
Back
Top