Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!sunybcs!canisius!elgie
From: elgie@canisius.UUCP (Bill Elgie)
Newsgroups: comp.databases
Subject: Re: Single Server Bottlenecks (was RE:ORACLE REL 6, INGRES REL 6)
Message-ID: <2359@canisius.UUCP>
Date: 14 May 89 01:35:30 GMT
References: <3176@tank.uchicago.edu> <518@daitc.daitc.mil>
Distribution: usa
Organization: Canisius College, Buffalo N.Y. 14208
Lines: 34

In article <518@daitc.daitc.mil>, jkrueger@daitc.daitc.mil (Jonathan Krueger) writes:
> [ re argument that a single database backend (INGRES, in this case) suffers
    because it is treated as a single process by the operating system ]
> Not that simple.  Each user has his own front end, too. 

  Most of the work (INGRES, again) is done by the back end.  INGRES front
  ends typically do less than 20% of the work (as measured in cpu time).
  User applications may consume more; we have one extreme that results in
  close to a 50/50 split.  But it still does very little i/o.
 
> And database applications are biased toward interactive workloads,
> where each user cycles think time==>input=>wait for the system
> output==>look at output (think time again).  This means that 10
> database users may be added before they "compete" for CPU in any real
> sense.

  "Interactive workloads" do not equate to low cpu utilization.  It's a
  function of the application.

  
  My own sense is that the direction that database developers are pushing
  us (consciously or implicitly) is towards dedicated back end servers and,
  in the not-too-distant future, workstation-based front end processors, con-
  centrating on managing the user interface.  While the latter are still ex-
  pensive to provide for large-volume use, a mix of the former with small
  multi-user systems, windowing terminals, and some workstations for those
  who do need the computing power may be a cheaper and more capable altern-
  ative to large-scale multi-user systems (including multi-processor boxes).

  I know that I am not saying anything new.  But I do believe that in
  the not-too-distant future, this will make the question of single-threaded
  versus multi-threaded back ends somewhat moot.
  
  greg pavlov (under borrowed account), fstrf, amherst, ny