* Re: Server - tasking and long lived connections
2001-12-15 2:06 ` Server - tasking and long lived connections Eric Merritt
@ 2001-12-15 3:10 ` James Rogers
2001-12-15 12:10 ` Florian Weimer
2001-12-15 14:38 ` Larry Kilgallen
` (3 subsequent siblings)
4 siblings, 1 reply; 18+ messages in thread
From: James Rogers @ 2001-12-15 3:10 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-15 3:10 ` James Rogers
@ 2001-12-15 12:10 ` Florian Weimer
0 siblings, 0 replies; 18+ messages in thread
From: Florian Weimer @ 2001-12-15 12:10 UTC (permalink / raw)
James Rogers <jimmaureenrogers@worldnet.att.net> writes:
> The tasking approach is somewhat more efficient than the traditional
> Unix approach of creating a separate process to handle each
> connection.
For long-living connections, this might not be the case. It depends
on several factors. For example, if there isn't much communication
required between the theads of control handling separate connections,
and each thread of control performs many memory allocations and
deallocations, the separate process implementation is probably faster.
> Context switching will be faster with tasks than with processes.
This depends on the OS and Ada implementation.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-15 2:06 ` Server - tasking and long lived connections Eric Merritt
2001-12-15 3:10 ` James Rogers
@ 2001-12-15 14:38 ` Larry Kilgallen
2001-12-15 16:51 ` Steve Doiel
` (2 subsequent siblings)
4 siblings, 0 replies; 18+ messages in thread
From: Larry Kilgallen @ 2001-12-15 14:38 UTC (permalink / raw)
In article <mailman.1008382022.25904.comp.lang.ada@ada.eu.org>, Eric Merritt <cyberlync@yahoo.com> writes:
> 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.
This must enter into your choice of operating system, but I don't
think of the term "file descriptors" as being an Ada phrase. If
you are limiting your choice to operating systems that use such
a construct, consider whether that is an artificial limit on the
available implementations.
The operating system with which I am most familiar had to increase
the number of simultaneous IO channels available, in recent years.
So not only the operating system but also the version may be important.
In that case, there are also multiple network implementations
available for each of two protocol sets. These also have different
limitations.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-15 2:06 ` Server - tasking and long lived connections Eric Merritt
2001-12-15 3:10 ` James Rogers
2001-12-15 14:38 ` Larry Kilgallen
@ 2001-12-15 16:51 ` Steve Doiel
2001-12-17 9:15 ` Thierry Lelegard
2001-12-19 18:20 ` Matthew Heaney
4 siblings, 0 replies; 18+ messages in thread
From: Steve Doiel @ 2001-12-15 16:51 UTC (permalink / raw)
I certainly wouldn't rule out a tasking arrangement using one task per N
file descriptors, where the number of file descriptors handled for each
task is target specific. I know that the "select" function on some targets
have a limit on the number of file descriptors, while other targets have a
limit on the number of tasks that may be used.
Our applications run on Winows NT 4.0. We use more than one task for each
connection (input, output and connection maintainence). We typically have a
few dozen connections. This implementation proves to be very simple and
easy to maintain. But you're talking about a lot more connections.
SteveD
"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:mailman.1008382022.25904.comp.lang.ada@ada.eu.org...
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-15 2:06 ` Server - tasking and long lived connections Eric Merritt
` (2 preceding siblings ...)
2001-12-15 16:51 ` Steve Doiel
@ 2001-12-17 9:15 ` Thierry Lelegard
2001-12-17 9:34 ` Jean-Pierre Rosen
2001-12-19 18:20 ` Matthew Heaney
4 siblings, 1 reply; 18+ messages in thread
From: Thierry Lelegard @ 2001-12-17 9:15 UTC (permalink / raw)
We have applications that we successfully tested with up to 6000 tasks.
That was on OpenVMS with the DEC Ada compiler. We now use GNAT on
VMS/UNIX/WNT. We haven't yet made such load testing but several hundredths
of tasks run fine.
On most operating systems, though, this requires some tuning (memory
management, I/O, etc).
I think that the trap in this kind of applications (servers with one
or more tasks per client connection) is the fate of the tasks when
the client disconnects. If you let the tasks die and recreate new
tasks for new client connections, you will most certainly face some
slow memory leak. We have seen that, although the stack itself is
deallocated when a task dies, there aer a few bytes which remain
allocated (some kind of TCB I suppose).
So, the trick is to never let the service tasks die. When a client
disconnects, just queue the service task for future usage by a new
client connection. When a new connection comes in, reuse an idle
service task. Create a new one only when there is no available
idle task.
Of course, if you connection are long lived (several hours) and your
application is relatively short lived (a few weeks), this may not
be an issue. But if you want your application to potentially run
forever, you should take care.
In the (long) past, I have seen a Minitel server (French ancestor
of the WWW) crashing every 3 months, due to virtual memory exhaustion,
just because the Ada tasks died when the clients disconnected.
-Thierry
____________________________________________________________________________
Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France
Tel: +33 1 71 71 54 30 Fax: +33 1 71 71 52 08 Mobile: +33 6 03 00 65 75
____________________________________________________________________________
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-17 9:15 ` Thierry Lelegard
@ 2001-12-17 9:34 ` Jean-Pierre Rosen
2001-12-17 10:16 ` Thierry Lelegard
2001-12-17 15:08 ` Larry Kilgallen
0 siblings, 2 replies; 18+ messages in thread
From: Jean-Pierre Rosen @ 2001-12-17 9:34 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
"Thierry Lelegard" <thierry.lelegard@canal-plus.fr> a �crit dans le message news: 3C1DB7B7.DF767F9@canal-plus.fr...
> I think that the trap in this kind of applications (servers with one
> or more tasks per client connection) is the fate of the tasks when
> the client disconnects. If you let the tasks die and recreate new
> tasks for new client connections, you will most certainly face some
> slow memory leak. We have seen that, although the stack itself is
> deallocated when a task dies, there aer a few bytes which remain
> allocated (some kind of TCB I suppose).
>
This was due to the (in)famous Rosen's pathology ;-)
It has been (fortunately) exterminated in in Ada 95, so the problem should not appear any more.
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-17 9:34 ` Jean-Pierre Rosen
@ 2001-12-17 10:16 ` Thierry Lelegard
2001-12-18 9:08 ` Jean-Pierre Rosen
2001-12-17 15:08 ` Larry Kilgallen
1 sibling, 1 reply; 18+ messages in thread
From: Thierry Lelegard @ 2001-12-17 10:16 UTC (permalink / raw)
Jean-Pierre Rosen wrote :
>
> "Thierry Lelegard" <thierry.lelegard@canal-plus.fr> a �crit dans le message news: 3C1DB7B7.DF767F9@canal-plus.fr...
> > I think that the trap in this kind of applications (servers with one
> > or more tasks per client connection) is the fate of the tasks when
> > the client disconnects. If you let the tasks die and recreate new
> > tasks for new client connections, you will most certainly face some
> > slow memory leak. We have seen that, although the stack itself is
> > deallocated when a task dies, there aer a few bytes which remain
> > allocated (some kind of TCB I suppose).
> >
> This was due to the (in)famous Rosen's pathology ;-)
> It has been (fortunately) exterminated in in Ada 95, so the problem should not appear any more.
Quite interesting. Could you elaborate on this? What kind of change was
introduced in Ada95 to eliminate this?
-Thierry
____________________________________________________________________________
Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr
CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France
Tel: +33 1 71 71 54 30 Fax: +33 1 71 71 52 08 Mobile: +33 6 03 00 65 75
____________________________________________________________________________
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-17 10:16 ` Thierry Lelegard
@ 2001-12-18 9:08 ` Jean-Pierre Rosen
0 siblings, 0 replies; 18+ messages in thread
From: Jean-Pierre Rosen @ 2001-12-18 9:08 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]
"Thierry Lelegard" <thierry.lelegard@canal-plus.fr> a �crit dans le message news: 3C1DC5ED.9E9F11F1@canal-plus.fr...
> Jean-Pierre Rosen wrote :
> >
> > "Thierry Lelegard" <thierry.lelegard@canal-plus.fr> a �crit dans le message news: 3C1DB7B7.DF767F9@canal-plus.fr...
> > > I think that the trap in this kind of applications (servers with one
> > > or more tasks per client connection) is the fate of the tasks when
> > > the client disconnects. If you let the tasks die and recreate new
> > > tasks for new client connections, you will most certainly face some
> > > slow memory leak. We have seen that, although the stack itself is
> > > deallocated when a task dies, there aer a few bytes which remain
> > > allocated (some kind of TCB I suppose).
> > >
> > This was due to the (in)famous Rosen's pathology ;-)
> > It has been (fortunately) exterminated in in Ada 95, so the problem should not appear any more.
>
> Quite interesting. Could you elaborate on this? What kind of change was
> introduced in Ada95 to eliminate this?
>
Here is (was) the problem:
task type TT is....
function F return TT is
Local : tt;
begin
return Local;
end F;
....
if F'Terminated then..... -- Allways true
The master of Local is function F; but since it is returned by the function, it is still possible to access the task object after
the scope of its master has been left (although the task will allways be terminated); hence the need to keep a minimum information,
and since the master is left, there is no logical place where that information can be reclaimed.
In Ada 95, a task type is a by-reference type (6.2(6)), and a function is not allowed to return a local object of a by-reference
type (6.5(18)). Therefore, the above program will raise Program_Error (6.5(20)).
--
---------------------------------------------------------
J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-17 9:34 ` Jean-Pierre Rosen
2001-12-17 10:16 ` Thierry Lelegard
@ 2001-12-17 15:08 ` Larry Kilgallen
2001-12-17 15:39 ` Pat Rogers
1 sibling, 1 reply; 18+ messages in thread
From: Larry Kilgallen @ 2001-12-17 15:08 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
In article <9vkecb$a6v$1@s1.read.news.oleane.net>, "Jean-Pierre Rosen" <rosen@adalog.fr> writes:
>
> "Thierry Lelegard" <thierry.lelegard@canal-plus.fr> a �crit dans le message news: 3C1DB7B7.DF767F9@canal-plus.fr...
>> I think that the trap in this kind of applications (servers with one
>> or more tasks per client connection) is the fate of the tasks when
>> the client disconnects. If you let the tasks die and recreate new
>> tasks for new client connections, you will most certainly face some
>> slow memory leak. We have seen that, although the stack itself is
>> deallocated when a task dies, there aer a few bytes which remain
>> allocated (some kind of TCB I suppose).
>>
> This was due to the (in)famous Rosen's pathology ;-)
> It has been (fortunately) exterminated in in Ada 95, so the problem should not appear any more.
Does the standard mandate that such a problem not happen,
or simply avoid mandating something that would force it to happen?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-17 15:08 ` Larry Kilgallen
@ 2001-12-17 15:39 ` Pat Rogers
0 siblings, 0 replies; 18+ messages in thread
From: Pat Rogers @ 2001-12-17 15:39 UTC (permalink / raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:YaH+t3eYcXsB@eisner.encompasserve.org...
> In article <9vkecb$a6v$1@s1.read.news.oleane.net>, "Jean-Pierre Rosen"
<rosen@adalog.fr> writes:
> >
> > "Thierry Lelegard" <thierry.lelegard@canal-plus.fr> a �crit dans le
message news: 3C1DB7B7.DF767F9@canal-plus.fr...
> >> I think that the trap in this kind of applications (servers with one
> >> or more tasks per client connection) is the fate of the tasks when
> >> the client disconnects. If you let the tasks die and recreate new
> >> tasks for new client connections, you will most certainly face some
> >> slow memory leak. We have seen that, although the stack itself is
> >> deallocated when a task dies, there aer a few bytes which remain
> >> allocated (some kind of TCB I suppose).
> >>
> > This was due to the (in)famous Rosen's pathology ;-)
> > It has been (fortunately) exterminated in in Ada 95, so the problem
should not appear any more.
>
> Does the standard mandate that such a problem not happen,
> or simply avoid mandating something that would force it to happen?
It is solved indirectly because functions can no longer return limited types
(eg task types) by-value. (A nice simple rule that solves a number of
issues.)
---
Patrick Rogers Consulting and Training in:
http://www.classwide.com Real-Time/OO Languages
progers@classwide.com Hard Deadline Schedulability Analysis
(281)648-3165 Software Fault Tolerance
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-15 2:06 ` Server - tasking and long lived connections Eric Merritt
` (3 preceding siblings ...)
2001-12-17 9:15 ` Thierry Lelegard
@ 2001-12-19 18:20 ` Matthew Heaney
2001-12-19 18:50 ` Eric Merritt
4 siblings, 1 reply; 18+ messages in thread
From: Matthew Heaney @ 2001-12-19 18:20 UTC (permalink / raw)
"Eric Merritt" <cyberlync@yahoo.com> wrote in message
news:mailman.1008382022.25904.comp.lang.ada@ada.eu.org...
> 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).
One thread per connection cannot possibly scale well. It is the *wrong* way
to implement a server.
Our RTSP video server uses WinNT I/O completion ports, so that a small
number of tasks (threads) can service hundreds (or even thousands) of client
connections.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Server - tasking and long lived connections
2001-12-19 18:20 ` Matthew Heaney
@ 2001-12-19 18:50 ` Eric Merritt
0 siblings, 0 replies; 18+ messages in thread
From: Eric Merritt @ 2001-12-19 18:50 UTC (permalink / raw)
To: comp.lang.ada
> One thread per connection cannot possibly scale
> well. It is the *wrong* way
> to implement a server.
>
> Our RTSP video server uses WinNT I/O completion
> ports, so that a small
> number of tasks (threads) can service hundreds (or
> even thousands) of client
> connections.
Actually after thinking about it I agree with you.
Though the connections are long lived (on the order of
several hours) that doesn't really remove the
usefulness of a thread pool, it just makes it less
valuable. It makes it less valuable because context
switching takes up a much smaller percentage of
overall run time. Even in this case a thread pool is
still a good idea.
__________________________________________________
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
^ permalink raw reply [flat|nested] 18+ messages in thread