Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!infmx!aland
From: aland@infmx.UUCP (Dr. Scump)
Newsgroups: comp.databases
Subject: Re: Client/Server processes and implementations
Summary: what's that old saying about lies, damn lies, and statistics?
Keywords: Client Server Processes
Message-ID: <2762@infmx.UUCP>
Date: 4 Dec 89 23:45:39 GMT
References: <7114@sybase.sybase.com> <6895@sybase.sybase.com> <2184@kodak.UUCP> <375@xyzzy.UUCP> <510@xyzzy.UUCP> <936@anasaz.UUCP>
Reply-To: aland@infmx.UUCP (alan denney)
Organization: INFORMIX Professional Services ("Peace thru Normalization")
Lines: 39

In article <936@anasaz.UUCP> john@anasaz.UUCP (John Moore) writes:
>...
>Anyhow,... the fact is that with proper cooperation from the OS
>scheduler and I/O system, architectures that allow requests from
>many processes to be served by one server can do a better job than
>process per server. We just benchmarked a realistic application
>mix where the Informix back-end memory usage alone exceed 350MBytes!

Um, I would be *really* interested to see how you computed this.
Did you take into account text sharing, memory usage by the kernel,
database front-end processes, and other unrelated processes?
I can't fathom 350 MB of *actual main memory consumption* by the engines
and server(s).  I think I know the benchmark to which you refer, and
it was not even close to being memory-bound.

>The advantage of one process per multiple users is that the
>"threads" can be cheap - low memory usage, low CPU usage because
>of precisely targetted scheduling algorithms. In addition, it
>is cheaper for them to cooperate for optimized scheduling. Finally,
>we have found that lock contention consumes lots of CPU when
>you have a large number of very active processes. The single
>server (or few servers) is a good way to reduce the lock overhead.
>John Moore (NJ7E)           mcdphx!anasaz!john asuvax!anasaz!john

This depends on in what way the processes are "active".  If they are
competing for update access to exactly the same pages, lock contention
can indeed make the database spend much of its time managing locks.
(For example, running multiple insert processes against the same table
with page mode locking in use is considered to be in poor taste :-]).
In a normal transaction mix, however, these lock contentions are
atypical.

--
    Alan S. Denney  @  Informix Software, Inc.    
         {pyramid|uunet}!infmx!aland                 "I want to live!
   --------------------------------------------       as an honest man,
    Disclaimer:  These opinions are mine alone.       to get all I deserve
    If I am caught or killed, the secretary           and to give all I can."
    will disavow any knowledge of my actions.             - S. Vega