Design Question. C/S Threads & AppDomains

  • Thread starter Thread starter quortex
  • Start date Start date
Q

quortex

Hi all,

I am developing a client/server application which has to potentially
handle a very large number of concurrent users.

Each connection is associated with a session object much like ASP.NET.

My first wish is to be able to process the sessions in parallel.
Obviously I can run each session in a separate thread however I gather
that once there is a large number of users the number of threads will
be too much of a drain on system resources. So I am thinking I should
use a thread pool with a set number of threads and then each thread
would be assigned multiple sessions. Is this the correct way of
thinking?

My second wish is to be able to to somehow secure each session within
its own execution boundary. Basically so that if something causes a
session to crash it does not take all the other sessions down with it.
Is the solution to this to run each session in its own application
domain? If so how would this combine with the thread approach?

If say I had 50,000 users connected to a server that would potentially
be a hell of a lot of threads + application domains which I assume
isn't the right way to go about it.

Any ideas on this would be greatly appreciated.

Kind Regards,
Mark
 
Hi all,

I am developing a client/server application which has to potentially
handle a very large number of concurrent users.

Each connection is associated with a session object much like ASP.NET.

My first wish is to be able to process the sessions in parallel.
Obviously I can run each session in a separate thread however I gather
that once there is a large number of users the number of threads will
be too much of a drain on system resources. So I am thinking I should
use a thread pool with a set number of threads and then each thread
would be assigned multiple sessions. Is this the correct way of
thinking?

My second wish is to be able to to somehow secure each session within
its own execution boundary. Basically so that if something causes a
session to crash it does not take all the other sessions down with it.
Is the solution to this to run each session in its own application
domain? If so how would this combine with the thread approach?

If say I had 50,000 users connected to a server that would potentially
be a hell of a lot of threads + application domains which I assume
isn't the right way to go about it.

Any ideas on this would be greatly appreciated.
Click to expand...

Mark,

this sounds an awful lot like your trying to (re)build a complete
application server infrastructure, which surely isn't impossible, but a
*huge* task.

Applications of that size (50000 users) also have enormous requirements
regarding memory if they're stateful, and almost certainly require
clustering for scalability or fail-over.

I'd rather think again about this approach and evaluate possible
existing solution components from the .NET stack before delving into
implementation specifics like AppDomains.

Cheers,
 
Back
Top