Why requests come sequentually, not in parallel?

**=?Utf-8?B?YnJ1Y2UgYmFya2Vy?=** · Nov 10 '08, 05:15 PM

RE: Why requests come sequentually, not in parallel?

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 (IRequiresSessi onState or
IReadOnlySessio nState) 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.

**=?Utf-8?B?Vkg=?=** · Nov 10 '08, 06:05 PM

RE: Why requests come sequentually, not in parallel?

Huh! Yes, my handler has to use session where some expensive-to-fetch
access-control info is cached. Is this behavior, where requests are
serialized, common to all ASP.NET requests (ASPX, ASMX), or is it
IHttpHandler-specific? One would think it would be enough to serialize access
to sessions themselves. Why block for entire time of request execution?
Also, would using of IAsyncHttpHandl er help? If not, could you please
suggest any workarounds?

Thank you,
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 (IRequiresSessi onState or
IReadOnlySessio nState) 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.

**=?Utf-8?B?Vkg=?=** · Nov 10 '08, 06:45 PM

RE: Why requests come sequentually, not in parallel?

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 (IRequiresSessi onState or
IReadOnlySessio nState) 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.

**=?Utf-8?B?YnJ1Y2UgYmFya2Vy?=** · Nov 10 '08, 08:05 PM

RE: Why requests come sequentually, not in parallel?

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 (IRequiresSessi onState or
IReadOnlySessio nState) 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.

**=?Utf-8?B?Vkg=?=** · Nov 10 '08, 08:25 PM

RE: Why requests come sequentually, not in parallel?

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 (IRequiresSessi onState or
IReadOnlySessio nState) 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.

**George** · Nov 10 '08, 09:05 PM

Re: Why requests come sequentually, not in parallel?

I belive that is what EnableSession=R eadOnly does on aspx pages.
Not sure how to do it on a Handler level

George

"VH" <VH@discussions .microsoft.comw rote in message
news:4CBD741B-E125-4EC1-9220-D1435BC838E5@mi crosoft.com...

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 (IRequiresSessi onState or
>IReadOnlySessi onState) 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.

**George** · Nov 10 '08, 09:05 PM

Re: Why requests come sequentually, not in parallel?

Forgot to add
You can easily write your own custom Session object..
Google it, I recall it was a KB on Microsoft.com with full implementation

George.

"VH" <VH@discussions .microsoft.comw rote in message
news:4CBD741B-E125-4EC1-9220-D1435BC838E5@mi crosoft.com...

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 (IRequiresSessi onState or
>IReadOnlySessi onState) 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.

Why requests come sequentually, not in parallel?

Why requests come sequentually, not in parallel?

Comment

Comment

Comment

Comment

Comment

Comment

Comment