Re: Confused about ASP, "sessions", and queuing of multiple requests

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Ohaya (Ohaya_at_NO_SPAM.cox.net)
Date: 02/24/04 

Date: Mon, 23 Feb 2004 23:29:40 -0500

Sylvain,

BTW, I forgot to mention:

If I run my Waitfor test with 2 different instances of IE (on same machine,
but 2nd IE started from Start, not using Ctrl-N) simultaneously, I see
Requests Executing in Perfmon as 2, i.e., in this situation, IIS *IS*
apparently processing both requests simultaneously/in parallel.

Like I said, I'm confused about what is different (specifically) between the
above test, and generating multiple HTTP requests from a single IE
instance...

"Ohaya" <Ohaya@NO_SPAM.cox.net> wrote in message
news:OiJzRkp%23DHA.2520@TK2MSFTNGP11.phx.gbl...
> Sylvain,
>
> Thanks for responding...
>
> Re. Waitfor, I just installed it for the test I described.
>
> Sorry if I'm being obtuse. I think I understand that one IE instance can
> generate multiple HTTP requests into IIS, e.g., in the instances that you
> described. In our case, I think your example of setting an IMG SRC to an
> ASP is exactly what we have, with multiple of these IMGs on one page.
>
> But, I guess I'm still unclear about when IIS/ASP will or will not handle
> these multiple requests in a "queuing" fashion vs. not in a queuing
fashion.
>
> What exactly determines this? As I mentioned, the posts I've seen vaguely
> mention "in the same session", without clearly defining what they mean by
a
> "session".
>
> Actually, the reason that I'm chasing all of this around is that we are
> running IIS on a multiprocessor server. With the IE client firing
multiple
> requests to IIS, we thought that the multiple requests from IE would be
> spread across the multiple processors.
>
> But on our production server, instead, for a given user operation at the
> IE/client end, which, again, creates several HTTP requests to IIS, we're
> seeing CPU activity on 1 CPU, then the next CPU, then the next CPU, etc.,
> until the user operation is complete.
>
> The conclusion we're coming to is that for some reason ASP on the
production
> server is not handling the multiple requests "in parallel", but rather
> queuing the requests (we see the parallel processing on a different
> multiprocessor server that we use for testing, but not on the production
> machine).
>
> We just cannot figure out what is different between these 2 machines that
> would cause queuing the requests in one case, but not in the other.
>
> Thanks,
> Jim
>
> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
> wrote in message news:O7nX9Np%23DHA.688@tk2msftngp13.phx.gbl...
> > That's true since IIS 3.0 and there are occasions when you don't need to
> > make quick refresh to see it in action.
> >
> > For example, this is necessary when the IE is making simultaneous
requests
> > to the IIS. Exemple of this are when you are dividing your page using
> > Frameset: each frame contains one HTML page as its source. Refreshing a
> > frameset then require to ask the server for more than one HTML page.
> >
> > Another example is when the source of an objet is an ASP page, like
this:
> >
> > <img src="get_the_image.asp">
> >
> > The use of Javascript and of other advanced facilities for requesting
data
> > from one or more ASP pages also rise the possibilities of having
multiple
> > simultaneous requests to the web server. It is clear from those example
> > that the server cannot run these requests in parallele because of the
> > possibility that the codes inside theses pages can make contradictory
> > changes to Session variables, global variables and/or other objects,
like
> > backend requests to a SQL-Server. This should clear any confusion into
> your
> > mind.
> >
> > By the way, using things like WaitFor and others objets for timing in
ASP
> > can result in a severe degradation of performance from the IIS and their
> > usages must be reserved to the cases when they are strictly necessary.
> >
> > S. L.
> >
> > "Ohaya" <Ohaya@NO_SPAM.cox.net> wrote in message
> > news:u0nrjZo%23DHA.552@TK2MSFTNGP11.phx.gbl...
> > > Hi,
> > >
> > > I'm trying to understand a situation where ASP seems to be "blocking"
of
> > > "queuing" requests. This is on a Win2K Advanced Server, with IIS5.
> > >
> > > I've seen some posts (e.g.,
> > >
> >
>
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=Tidy7IDbDHA.2108%40cpmsftngxa06.phx.gbl)
> > > that indicate that ASP will queue up requests when they come in with
the
> > > same "session".
> > >
> > > My first question is "Can someone confirm that this is true?" (see
> below).
> > >
> > > My second is regarding what "same session" means in this context?
> > >
> > > Several of the posts that I've seen with respect to this queuing just
> say
> > > "session", but I've also seen some posts that say "ASP session", and
> which
> > > specifically mention "the ASP Session object". This latter reference
> > ("ASP
> > > Session object") is more precise, but my testing (again, see below)
> seems
> > to
> > > indicate that this interpretation of "session" is not "ASP Session
> > object".
> > >
> > > Here's the test that tried:
> > >
> > > 1) I installed the Waitfor from ServerObjects
> > > (http://www.serverobjects.com/products.htm), and created a small
> > "text.txt"
> > > file in c:\.
> > >
> > > 2) I put Waitfor.asp in my website.
> > >
> > > 3) I ran Performance Monitor and added the "Requests Queued" counter
> > >
> > > 4) Using IE, I went to http://myserver/waitfor.asp
> > >
> > > 5) Once it connected, I started clicking the IE Refresh button
> > >
> > >
> > > As I clicked the IE Refresh button, I could see the "Requests Queued"
> > > counter climb in Performance Monitor.
> > >
> > > The above test SEEM to at least indicate that ASP will *INDEED* only
> > process
> > > a single request from IE, i.e., that ASP *IS* queuing, but I'm still
> > > confused about under what circumstances this queuing will happen (what
> > does
> > > "session" mean in this context?).
> > >
> > > Can someone clarify this?
> > >
> > > Thanks, and apologies for both the cross-post and somewhat long
post...
> > >
> > >
> >
> >
>
>

Quantcast