Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Upper limits on number concurrent processes on an NT system

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
I'm adapting a pretty old program to run in a session oriented Client-Server mode over the Internet. A typical Client-Server session may last an hour or so.&nbsp;&nbsp;At the beginning of a session, the Client logs on and the server uses ShellExecute to start an instance of our backend process for that session, assigning it a unique session ID. The backend process stays alive for the duration of the session. The assigned session ID is included in every subsequent request from the client, and the server uses the ID to connect with the associated instance of the backend process.<br><br>The server will reside on an NT 4.0 machine.&nbsp;&nbsp;Assume we can get a state of the art machine with as much disk and RAM as we need. <br><br>So does anyone have any clues as to how many concurrent copies of the backend process we'll be able to start and run, before the system starts thrashing itself to death or NT runs into some internal limitation?&nbsp;&nbsp;The actual processing done by the backend is minuscule and requests are generated in response to user actions at the screen with a lot of think-time between them.&nbsp;&nbsp;Thus, the real processing load is going to be in the overhead of managing hundreds (thousands? more?) of concurrent instances of the backend process.<br><br>Because this is an older program with 350,000 lines of code, a rewrite to use a more state of the art approach is probably not in the cards. <br><br>Thanks.<br><br>&nbsp;&nbsp;
 
What version of NT would you be installing on, workstation or server? When you say number of concurrent copies in the background, do you mean that each time a client connects to the machine, that a new instance of the program fires up?<br><br>If you are dealing with NT workstation I know that it has a limit of 10 concurrent connections (In order to prevent it from being used as a webserver and paying less money then server). As far as the server goes I don't believe there is any such theoretical limits placed on it, but I am sure there are practical limits of which I don't know.<br><br>Hope this helps... <p>Troy Williams B.Eng.<br><a href=mailto:fenris@hotmail.com>fenris@hotmail.com</a><br><a href= > </a><br>
 
Thanks. I guess it would be NT Server; and yes, a new instance of the backend process springs up for each user logon request.&nbsp;&nbsp;But even though the instance persists until the user finally requests a logoff (or maybe times out for inactivity), the actual socket connections only last for the duration of a single request/response transaction, just like normal HTTP.&nbsp;&nbsp;<br><br>I'm sure that someone at MS has reams of statistics on just this question, but I've never seen anything published and haven't got a clue whom to ask. It's those &quot;practical&quot; limits I'm worried about.
 
How many users do you intended to have on at the same time? Your bottleneck might not be NT if you are expecting a large number you might need some really fancy hardware. Where I work, we have old 16-bit software that is a pain in the butt. It causes our server, with only 10 concurrent users to really have problems and it is a dual p3 750 with 256 Mb of ram! <br><br>You could try and see what happens with one server. I am wondering if you could have a number of servers that handle the application, so as to spread the workload out. I am not sure if this would work, but it is a thought.<br><br>Good luck... <p>Troy Williams B.Eng.<br><a href=mailto:fenris@hotmail.com>fenris@hotmail.com</a><br><a href= > </a><br>
 
I'm thinking possibly hundreds or maybe a thousand or two,&nbsp;&nbsp;though not right away. We're already planning to allow for dedicated multiple server hardware, just not sure when/if we'll have to roll it in. I'm going to try some stress tests just to get a rough idea. I'll post results here whenever I get around to doing it.&nbsp;&nbsp;<br><br>I used to know a Troy Williams at TRW Systems Group in Washington DC in the late 60's. Not you, I trust?
 
A little before my time :) <p>Troy Williams B.Eng.<br><a href=mailto:fenris@hotmail.com>fenris@hotmail.com</a><br><a href= > </a><br>
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top