Re: IIS Slow with little load problem
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 10/18/04
- Next message: Steve Schofield: "Re: 2003 FTP with IIS"
- Previous message: Brad: "Re: 2003 FTP with IIS"
- In reply to: bill page: "Re: IIS Slow with little load problem"
- Next in thread: swabbie: "Re: IIS Slow with little load problem"
- Reply: swabbie: "Re: IIS Slow with little load problem"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 18 Oct 2004 14:39:02 -0700
If you are interested in getting to the bottom of this, please start looking
at:
1. Network Monitor, Ethereal, or some Network packet sniffing tool and
capture network traffice for those two minutes.
2. CPU/Disk/Network perf counters on the web server
3. Tracing on the SQL Server
If you want other independent opinions, feel free to share the information.
Otherwise, we are all just second-hand speculating based on your
observations.
Regarding testing applets -- why do you need to browse through IIS/Browser
to load the Applet? Can't you load up a local test HTML page to get the
Applet running -- in which case, you are dealing with a local filesystem
that is much faster? You're already developing differently than end-user
usage (with a cabinet), so might as well do it in the most efficient way
possible. When you want to "perf test" the end-to-end-scenario as well as
applet performance, you can go through this exercise -- it doesn't have to
be during code development.
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "bill page" <bill-insert-at-digitalgarden.com> wrote in message news:%23q9McMusEHA.376@TK2MSFTNGP09.phx.gbl... Not sure that you understand. The best example is bringing up the applet. I'm not sure how many classes are needed for the initial load, but I just did it and it took almost 2 minutes from the click on the asp page until the applet actually showed. I also just did what I talked about before and started 2 browsers and clicked on both as simultaneously as I could. They were both up in under 20 seconds (obviously this isn't 2 orders of magnitude). In both cases there are probably a dozen sql server calls before the applet actually is up (probably 1/2 in asp and 1/2 in jdbc). I would expect that bringing up an applet would be all 'hot' as you call it given that IE is trying to load say 150 classes immediately. Again, up until recently, the load time was more like the 2 load scenario. The users don't see this behavior because they get the cabinet files and that loads in seconds. In the development environment where I/we change a piece of code, test, change again etc waiting 2 minutes each time (rather than 20 seconds) to bring up the application is fairly annoying. thanks for you input bill "David Wang [Msft]" <someone@online.microsoft.com> wrote in message news:uYO9HcMsEHA.2192@TK2MSFTNGP14.phx.gbl... > Based on your description, the server's behavior sounds normal. I honestly > haven't had anyone ask me for switches to make the server behave > abnormally... > > IIS will likely cache access to those class files such that subsequent > access is fast and never goes to disk. But the first hits that do NOT come > from the memory cache will obviously not perform as well -- especially if it > is for hundreds of class files with hundreds of individual seeks to the disk > for possibly fragmented files. > > This behavior would of course be completely by-design -- for the single > user, you are seeing cold-set behavior, and that's why we have caches. As > soon as you have multiple users, you are seeing hot-set behavior, and the > fact that the cache can have a 2 orders magnitude difference is a *good* > thing. Sounds about right given10ms HDD access speed vs 10ns RAM access > speed. > > I don't know of the registry keys, but you may be able to tweak how long IIS > keeps items in cache memory -- but you'd then have to balance against > possible increased memory pressure and cache eviction changes -- remember, > as soon as you start tuning and tweaking registry keys, we assume you fully > know what you are doing. Honestly, I'm not certain this extra layer of > complexity/optimization is worthwhile for gains of less than a second on a > development server and settings that you will likely not apply on the > production server. > > I suggest that if things aren't broken, don't go "fixing" it... >
- Next message: Steve Schofield: "Re: 2003 FTP with IIS"
- Previous message: Brad: "Re: 2003 FTP with IIS"
- In reply to: bill page: "Re: IIS Slow with little load problem"
- Next in thread: swabbie: "Re: IIS Slow with little load problem"
- Reply: swabbie: "Re: IIS Slow with little load problem"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|