RE: Why requests come sequentually, not in parallel?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Thank you, Bruce. That explains it: if session items cannot always be shared
between parallel requests even if access to Session collection was required
to be thread-safe, then you're right, requests need to be serialized. I will
need to rewrite my handler to save session-specific items in a in-process,
thread-safe structure outside of the Session collection.

Vlad Hrybok.
http://UltiDev.com/Products/HttpVPN/

"bruce barker" wrote:

session sharing is more complex than just threadsafe. inproc is pretty
simple, you could require all access to session to threadsafe, but out of
proc sessions are more complex. as session is loaded at start of request, and
saved at end of request, the session manager would still need to serialize
on load, and hold off on save via some reference counting.

you should still look at rewriting your image handler to be sessionless and
use the url parameters to access the session data (which would need to be
stored outside session)

-- bruce (sqlwork.com)


"VH" wrote:

Never mind my previous post. Of course, all requests accessing Session should
be serialized, unless they were required to be written in a thread-safe
manner. I wish there were a way to declare a page or a handler as thread-safe
to avoid perf penalty due to request serialization.

Thanks again,
Vlad.

"bruce barker" wrote:

you probably have session enabled for your handler. two requests to the same
session are serialized due to the design of session management. your image
handlers should not use session (IRequiresSessionState or
IReadOnlySessionState) as this will cause performance issues.

-- bruce (sqlwork.com)


"VH" wrote:

Hi, all.

Need help with what seems to be either connection, or threading problem in
my ASP.NET 2.0 application.

The gist of the problem is this: IHttpHandler in my application serves an
HTML page that has two images (image A and image B) in it. Once the HTML page
is served, expected behavior is this:
1) receive request for image A,
2) receive request for image B almost at the same time as for A,
3) serve image A response,
4) serve image B response.
Actual behavior is instead:
1) receive request for image A
2) serve image A response
3) receive request for image B
4) serve image B response
The application acts as if it allows only ONE connection from the browser
instead of two. This decreases the performance (as experienced by users)
quite a bit.

Additional details.
My ASP.NET application has ASPX pages, ASMX web services and IHttpHandler
that serves resources described before. I suspected that the problem may be
caused by the running out of inbound connections on my (Vista/IIS7 with
classic pipeline) dev box, but the same behavior is observed on IIS6 on
Windows Server 2003.
The strangest thing is that when tracing HTTP sessions using Fiddler, I see
that *browser sends both image requests requests virtually at the same time*
but second request reaches my IHttpHandler only after first one was served! I
played with ASP.NET threading settings to no avail. Requests served by
IHttpHandler have somewhat longer latency by design: from milliseconds to up
to 9 seconds. Also, when I launch multiple browsers pointing to the html page
with images, I get requests from different browsers coming in parallel. It
looks like for some reason only requests from the same browser come in
sequentially. Tried turning keep-alive on and off on the application and it
made no difference.

Why would two requests sent by browser at the same time arrive in a manner
implying only one connection to the browser instead of two?

Thank you,
Vlad.
.

Relevant Pages