Re: Server - tasking and long lived connections

[James Rogers <jimmaureenrogers@worldnet.att.net>]

Hi Eric.

Which operating system are you targeting for this application?

WinNT easily handles about 2000 of tasks. I do not know the
limits on open file descriptors.

The tasking approach is somewhat more efficient than the traditional
Unix approach of creating a separate process to handle each 
connection. The tasking approach will require the same number
of file descriptors and data base connections. Context switching will
be faster with tasks than with processes.

Which other design approaches would you consider if your operating
system resources are too limited? Would you be able to expand the
system by creating a set of application servers all accessing
a central database through a network? Would you need a system that
performed automatic load balancing across a network?

One advantage of the tasking approach is that you will be able to
create the tasking code as a task type, then create as many 
instances of that task type as you need. From the Ada point of
view this solution is highly scalable.

Jim Rogers

Eric Merritt wrote:
> 
> Hello All,
> 
> I am in the process of designing a server that will
> need to accept long lived (up to several hours) client
> connections. The processes themselves will be fairly
> I/O bound (database accesses), and at most the number
> of processors will be in the range of 2 - 4. The
> obvious choice (in my mind) for this is to use a
> single task per connection. In this senario, context
> switching will not be a major issues due to the length
> of the connections. There will be little or no
> performance gains by using tasking, but it handles the
> long connection times well.
> 
> I do, however, have a few reservations about
> scalablity due to OS limitations on the number of
> threads per machine and the number of open file
> descriptors. Although at first the number of
> connections will not be high, it is possible that it
> could rapidly need to scale up to a fairly high
> number, several hundred or more. This may mean that I
> will just have to distribute the app across several
> boxs and do some type of mirroring on the databases,
> but I want to put that off as long as possible.
> 
> I have quit a bit of experience in code this type of
> application but usually with short lived connections
> or a low number of total connections.
> 
> Anyway, I am just looking for some one to either point
> me in a different direction or confirm my current
> approach (one thread per connection).
> 
> Thank you for your input.
> 
> __________________________________________________
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions for all of
> your unique holiday gifts! Buy at http://shopping.yahoo.com
> or bid at http://auctions.yahoo.com