Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!hobbes!ben
From: ben@hobbes.sybase.com (ben ullrich)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Message-ID: <7220@sybase.sybase.com>
Date: 27 Nov 89 20:13:59 GMT
References: <2184@kodak.UUCP> <6895@sybase.sybase.com> <122@tacitus.tfic.bc.ca> <7037@sybase.sybase.com> <125@tacitus.tfic.bc.ca> <7139@sybase.sybase.com> <127@tacitus.tfic.bc.ca> <7167@sybase.sybase.com> <128@tacitus.tfic.bc.ca>
Sender: news@sybase.sybase.com
Organization: sybase, inc., emeryville, ca
Lines: 22

In article <128@tacitus.tfic.bc.ca> clh@tacitus.UUCP (Chris Hermansen) writes:
>What about the extra overhead incurred by your (non-kernel) time slicer
>operating beneath the UN*X time slicer?  Are you sure that you don't pay
>some kind of performance penalty by having one large user process operating,
>rather than a bunch of small ones, when paging is an issue?

i'm not sure which side of the fence you're on here -- i would think that the
context switching and process & memory overhead would be more significant for
numerous small processes than for one large one.  Paging is more of an issue
when there are more processes around, each wanting pieces of their own
executable and data, at unpredictable times.  Operating under the UNIX time
slicer is unavoidable as long as there is an OS, but living with this is
simpler with one process.  I'm not saying that multiple servers are not a good
idea per se, but wrt time slicing, they are worse off than a single-process 
architecture.

..ben
----
ben ullrich	       consider my words disclaimed,if you consider them at all
sybase, inc., emeryville, ca	"When you deal with human beings, a certain
+1 (415) 596 - 3500	        amount of nonsense is inevitable." - mike trout
ben@sybase.com			       {pyramid,pacbell,sun,lll-tis}!sybase!ben


Brought to you by Super Global Mega Corp .com