>
- We are handling some pretty big concurrent user load and it is not
rare to have 200-300 threads running within our server
process.
Don’t. Having one thread per client does not scale well. Think I/O
completion ports instead.
I think
we are pushing the envelope a little bit here.
- Virtual Addressing space limitation. Because we deal with large
databases, we have to constantly map/unmap file sections within a 2
gigabytes space. Having each process own its entire 2 Gig space would
help and use 8 gig RAM machines a little better. I know 4.0 has some
extensions to access by hand an additional 4Gig space, but
this looks a
little clunky to me.
I don’t know about additional 4GB in NT4.0 (but perhaps there is). The only
thing I’ve heard of is the /3GB switch which only works (sorry, is legal) in
NT Server 4.0 / EE -> which reserves 3GBs of mem to user-mode processes.
If you need more memory -> W2K AS, DataCenter.
- Fragility. I confess we do have bugs that we have not nailed yet.
When we encounter a problem, the whole server process goes
down. Having
multiple processes would limit the damage to one user instead of 200.
True - but how about finding the bug(s) instead 
Having 200 processes
running is not a good idea.
Does anybody has a feeling/experience with Win2K and multi-processes:
o Named semaphores vs. critical sections for synchronization
(that must
hurt!). I guess we can mitigate this a little bit with
InterlockedIncrement() kind of things, but, still…
o Shared memory accesses
o Process scheduling overhead (is it less painful than 4.0?)
o Large number of handles (1,000 files opened by 100 users becomes
100,000 handles on a multi-process app, as opposed to 1,000 for a
multi-threaded one)
I don’t think you will find much of a difference for these issues between
NT4.0 and W2K, even though I know that W2K has many scalability
improvements. Did you consider moving the app to COM+ and leave more of the
scaling business to the operating system and its services?
// Johan
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com