David
Sat Feb 14 03:25:44 CST 2004
I really can't think of anything else other than to get a NetMon capture of
one of the unfortunately clients accessing a page slowly.
You're saying that there's no errors in HTTPERR log files during all this,
so data is being sent, connections are not being dropped... but causing
clients to be slow... so I can only think of using a network trace to
capture one of those sequences and see what's going on.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
<anonymous@discussions.microsoft.com> wrote in message
news:ecd401c3f1a6$609ccda0$a101280a@phx.gbl...
When buffering is enabled ALL clients perform well. When
it is disabled, we see the inconsistent results on W2K
clients.
This is an intranet web application, so page size is not
really an issue. All of the clients are running at
10/100. In addition, all clients use IE only. Network
is not the issue.
Regardless of what the page is doing, the bottleneck is
occurring when it is downloading the page results to the
client, not processing the page. We have an include file
in the page that has javascript code. This is a very
large include file and the majority of the time is taken
while downloading this portion of the page.
>-----Original Message-----
>So, you are saying that for the EXACT SAME PAGE and
result-set, SOME W2K
>clients would access it very slowly but not other W2K
clients, and XP
>clients do not have a problem?
>
>If that is the case, the Response.Flush() issue that
you've been reading
>about isn't the cause -- that issue would affect all
clients that encounter
>the same code sequence.
>
>Are you also saying that when you enable Buffering that
all clients perform
>well or not well? What code sequence is requiring you
to have Buffering =
>false?
>
>Without more investigation and info on the
characteristics of your pages
>(such as what it's doing), I wouldn't know what's going
on in your
>situation, much less why.
>
>BTW, 80K page is HUGE. Dialup users wait >15 seconds
just for the page
>itself.
>
>--
>//David
>IIS
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>//
>"Chris" <anonymous@discussions.microsoft.com> wrote in
message
>news:ee5401c3f0d2$3ca9df70$a601280a@phx.gbl...
>David,
>
> We have an ASP app that runs perfectly accross all
>clients when hosted under IIS 5. We moved the same code
>to IIS 6 and *some* windows 2000 clients are loading
>pages painfully slow. The pages are not exceptionally
>large...only 80-100k. All code has Response.Buffer =
>false. However, when we enable buffering, all clients
>perform the same. Why would it be slow on a per client
>basis when switching hosting from IIS 5 to IIS 6 and only
>on some W2K clients but not on any XP clients?
>
>btw...we looked at the log file and there are no errors.
>
>>-----Original Message-----
>>Your issue does not sound like the buffering issue since
>that will happen
>>uniformly for all clients.
>>
>>You want to look in %SYSTEMROOT%\System32
>\LogFiles\HTTPERR\*.log to see if
>>there is anything unusual in there.
>>
>>As for the "real issue" in your case, we'll just have to
>try to
>>systematically troubleshoot and figure it out -- that's
>what a
>>server/webmaster is responsible for.
>>
>>--
>>//David
>>IIS
>>This posting is provided "AS IS" with no warranties, and
>confers no rights.
>>//
>>"Chris" <anonymous@discussions.microsoft.com> wrote in
>message
>>news:dafd01c3f026$389b6f40$a301280a@phx.gbl...
>>I am having trouble with our custom web application. We
>>just upgraded to window 2003 and have seen a decrease in
>>performance running the web off of this server. It is
>>not consistent though, because XP users and some W2K
>>users have not seen a decrease in performance. All W2K
>>users are running SP3 and have the latest version of IE.
>>I have seen in some instances where adding the Qos
Packet
>>Scheduler service to the local area connection did bring
>>the slow clients up to speed, but for others it did
>>nothing. I also looked into the buffering issue, and
>>when buffering was turned on it did help, but due to our
>>code this is not an option. I would really like to know
>>what the real issue is here, because if it is buffering,
>>why are there still mixed OS clients still running the
>>App at normal speed. I would appreciate any info or
>>tips....thanks
>>
>>
>>.
>>
>
>
>.
>